Update MdePkg/Include/IndustryStandard/SmBios.h to avoid compilation
errors through safeguarding definitions with DISPLAY_FSP_VERSION_INFO_2
Kconfig.
BUG=b:153038236
BRANCH=None
TEST=Verify JSLRVP build with all the patches in relation chain
and verify the version output prints no junk data observed.
Couple of lines from logs are as below.
Display FSP Version Info HOB
Reference Code - CPU = 8.7.16.10
uCode Version = 0.0.0.1
Change-Id: I9698861be1f969ddca7f171767a54ac486502c74
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45906
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support for MP services2 PPIs, which is slight modification
over MP services 1 PPIs. A new API StartupAllCPUs have been added
to allow running a task on BSP and all APs. Also the EFI_PEI_SERVICES
parameter has been removed from all MP PPI APIs.
This implementation also selects the respective MP services PPI version
supported for SoCs
BUG=b:169196864
Change-Id: Id74baf17fb90147d229c78be90268fdc3ec1badc
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add new Kconfig symbols to mark FSP binary as x86_32.
Fix the FSP headers and replace void pointers by fixed sized integers
depending on the used mode to compile the FSP.
This issue has been reported here:
https://github.com/intel/FSP/issues/59
This is necessary to run on x86_64, as pointers have different size.
Add preprocessor error to warn that x86_64 FSP isn't supported by the
current code.
Tested on Intel Skylake. FSP-M no longer returns the error "Invalid
Parameter".
Change-Id: I6015005c4ee3fc2f361985cf8cff896bcefd04fb
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This patch includes (edk2/edk2-stable202005) all required headers
for edk2-stable202005 quarterly EDK2 tag from EDK2 github project
using below command:
>> git clone https://github.com/tianocore/edk2.git vedk2-stable202005
Only include necessary header files.
MdePkg/Include/Base.h was updated to avoid compilation errors through
safeguarding definitions for MIN, MAX, NULL, ABS, ARRAY_SIZE.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I3172505d9b829647ee1208c87623172f10b39310
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42239
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
I just got hit by a double-evaluation bug again, it's time to attempt
to fix this once more. Unfortunately there are several issues that don't
make this easy:
- bitfield variables don't support typeof()
- local macro variables that shadow others trigger -Werror=shadow
- sign warnings with integer literal and unsigned var in typeof-MIN()
- ({ statement expressions }) can not be used outside functions
- romcc doesn't support any of the fancy GCC/clang extensions
This patch tries to address all of them as far as possible with macro
magic. We don't have the technology to solve the bitfield and
non-function context issues yet (__builtin_choose_expr() still throws a
"no statement expression outside a function" error if it's only in the
branch that's not chosen, unfortunately), so we'll have to provide
alternative macros for use in those cases (and we'll avoid making
__ALIGN_MASK() double-evaluation safe for now, since it would be
annoying to do that there and having an alignment mask with side
effects seems very unlikely). romcc can continue using unsafe versions
since we're hopefully not writing a lot of new code for it. Sign
warnings can be avoided in literal/variable comparisons by always using
the type of the variable there. Shadowing is avoided by picking very
explicit local variable names and using a special __COUNTER__ solution
for MIN() and MAX() (the only ones of these you're likely to nest).
Also add DIV_ROUND_UP() to libpayload since it's a generally quite
useful thing to have.
Change-Id: Iea35156c9aa9f6f2c7b8f00991418b746f44315d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32027
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Since this code is pulled in through commonlib, it will break compilation
of cbfstool on OSX.
Change-Id: I342bfa7e755aa540c4563bb5cd8cccacee39d188
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13525
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
FSP has some unique attributes which makes integration
cumbersome:
1. FSP header files do not include the types they need. Like
EDKII development it's expected types are provided by the
build system. Therefore, one needs to include the proper
files to avoid compilation issues.
2. An implementation of FSP for a chipset may use different
versions of the UEFI PI spec implementation. EDKII is a
proxy for all of UEFI specifications. In order to provide
flexibility one needs to binding a set of types and
structures from an UEFI PI implementation.
3. Each chipset FSP 1.1 implementation has a FspUpdVpd.h
file which defines it's own types. Commonality between
FSP chipset implementations are only named typedef
structs. The fields within are not consistent. And
because of FSP's insistence on typedefs it makes it
near impossible to forward declare structs.
The above 3 means one needs to include the correct UEFI
type bindings when working with FSP. The current
implementation had the SoC picking include paths in the
edk2 directory and using a bare <uefi_types.h> include.
Also, with the prior fsp_util.h implementation the SoC's
FSP FspUpdVpd.h header file was required since for providing
all the types at once (Generic FSP 1.1 and SoC types).
The binding has been changed in the following manner:
1. CONFIG_UEFI_2_4_BINDING option added which FSP 1.1
selects. No other bindings are currently available,
but this provides the policy.
2. Based on CONFIG_UEFI_2_4_BINDING the proper include
paths are added to the CPPFLAGS_common.
3. SoC Makefile.inc does not bind UEFI types nor does
it adjust CPPFLAGS_common in any way.
4. Provide a include/fsp directory under fsp1_1 and
expose src/drivers/intel/fsp1_1/include in the
include path. This split can allow a version 2,
for example, FSP to provide its own include files.
Yes, that means there needs to be consistency in
APIs, however that's not this patch.
5. Provide a way for code to differentiate the FSP spec
types (fsp/api.h) from the chipset FSP types
(fsp/soc_binding.h). This allows for code re-use that
doesn't need the chipset types to be defined such as
the FSP relocation code.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted on glados.
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Change-Id: I894165942cfe36936e186af5221efa810be8bb29
Reviewed-on: http://review.coreboot.org/11606
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Tested-by: build bot (Jenkins)
Only define the ASSERT macro when it is not already defined. This
change allows the UEFI/FSP definitions to be included with most other
coreboot includes.
BRANCH=none
BUG=None
TEST=Build and run on sklrvp
Change-Id: Iccfeb83eb1e52623ae0a0fe2a96b587ce61f82d7
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10334
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
As the first step in adding support for FSP 1.1, add common header files
for EDK2. Internally FSP is based upon EDK2 and uses the defines and
data structures within these files for its interface.
These files come from revision 16227 of the open source EDK2 tree at
https://svn.code.sf.net/p/edk2/code/trunk/edk2. These files are
provided in an EDK2 style tree to allow direct comparison with the EDK2
tree.
Updates may be done manually to these files but only to support FSP 1.1
on UEFI 2.4. A uefi_2.5 tree should be added in the future as FSP
binaries migrate to UEFI 2.5.
Note: All the files were modified to use Linux line termination.
BRANCH=none
BUG=None
TEST=Build for Braswell or Skylake boards using FSP 1.1.
Change-Id: Ide5684b7eb6392e12f9f2f24215f5370c2d47c70
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/9943
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
