summaryrefslogtreecommitdiff
path: root/src/vendorcode/intel/edk2
AgeCommit message (Collapse)Author
2019-04-04Make common macros double-evaluation safeJulius Werner
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>
2019-01-17vendorcode/{amd,cavium,intel}: Remove trailing whitespacePeter Lemenkov
find src -type f "!" -regex ".*\.\(vbt\|bin\)" -exec sed -i -e "s,\s\+$,,g" {} \; Change-Id: Ic70cf8524dcd0a0f5700f91b704b3c545dd8a01a Signed-off-by: Peter Lemenkov <lemenkov@gmail.com> Reviewed-on: https://review.coreboot.org/c/30959 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-12-18Fix typos involving "the the"Jonathan Neuschäfer
Change-Id: I179264ee6681a7ba4488b9f1c6bce1a19b4e1772 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/c/30160 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2018-01-31vendorcode/intel: Add UDK2017 supportSubrata Banik
This patch includes (edk2/UDK2017) all required headers for UDK2017 from EDK2 github project using below command >> git clone https://github.com/tianocore/edk2.git vUDK2017 commit hash: 66833b2a87d98be8d81d1337c193bcbf0de47d47 Change-Id: If0d5a3fef016c67e9eed6aed9b698b3b13b930c4 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/23425 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-09-02vendorcode/intel: Add UDK 2015 BindingsRizwan Qureshi
Add UDK 2015 Bindings for FSP header compatibility. These bindings add the necessary code to read FSP Headers without any modifications from FSP Source. BUG=chrome-os-partner:54100 BRANCH=none TEST=built coreboot image and verified boot Change-Id: I2887f55b6e63cd0a2b2add9a521be9cfaf875e7d Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-on: https://review.coreboot.org/16307 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-13HobLib: Don't break GCC strict aliasingStefan Reinauer
Change-Id: I1bd33e423b0fcb69597e001b61c6ea916f5fe44a Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/14622 Tested-by: build bot (Jenkins) Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
2016-01-31vendorcode/intel: remove unused apple specific assembler macrosStefan Reinauer
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>
2015-09-10fsp1_1: provide binding to UEFI versionAaron Durbin
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)
2015-07-08vendorcode/intel/edk2: Fix EFI_PEI_GRAPHICS_INFO_HOB structureLee Leahy
Change the FrameBufferSize field from UINT64 to UINT32 to match the Platform Initialization 2.4 specification. BRANCH=none BUG=None TEST=Build and run on cyan Change-Id: I28dc0608675ed5840863ecd15bd2f57e6b2f4c1d Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: http://review.coreboot.org/10834 Tested-by: build bot (Jenkins) Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-06-24Intel vendorcode: Add FSP_SMBIOS_MEMORY_INFO_GUIDLee Leahy
Add new GUID for FSP. BRANCH=none BUG=None TEST=Build and run on strago Change-Id: I539a59b513f67535436f581e0a79ab53f05682ca Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: http://review.coreboot.org/10587 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-29UEFI: Conditionally define the ASSERT macroLee Leahy
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>
2015-04-30vendorcode/intel: Add EDK2 header filesLee Leahy
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>