summaryrefslogtreecommitdiff
path: root/src/vendorcode
diff options
context:
space:
mode:
authorAaron Durbin <adurbin@chromium.org>2015-09-09 17:05:06 -0500
committerAaron Durbin <adurbin@chromium.org>2015-09-10 17:52:28 +0000
commit789f2b6c435c7f31591e2c5e969ba96df21a191d (patch)
tree065bb61fb3c35d9e6ee97ff676ce1b9bdfa6ea0d /src/vendorcode
parent95ba4c87f5f4802e2afaeae38003db5e7235864a (diff)
downloadcoreboot-789f2b6c435c7f31591e2c5e969ba96df21a191d.tar.xz
fsp1_1: provide binding to UEFI version
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)
Diffstat (limited to 'src/vendorcode')
-rw-r--r--src/vendorcode/intel/Kconfig3
-rw-r--r--src/vendorcode/intel/Makefile.inc10
-rw-r--r--src/vendorcode/intel/edk2/uefi_2.4/uefi_types.h18
3 files changed, 22 insertions, 9 deletions
diff --git a/src/vendorcode/intel/Kconfig b/src/vendorcode/intel/Kconfig
index 0da26f0fbd..754c48716c 100644
--- a/src/vendorcode/intel/Kconfig
+++ b/src/vendorcode/intel/Kconfig
@@ -22,3 +22,6 @@ config FSP_VENDORCODE_HEADER_PATH
default "fsp1_0/ivybridge_bd82x6x" if CPU_INTEL_FSP_MODEL_306AX && SOUTHBRIDGE_INTEL_FSP_BD82X6X
default "fsp1_0/baytrail" if SOC_INTEL_FSP_BAYTRAIL
default "fsp1_0/rangeley" if CPU_INTEL_FSP_MODEL_406DX
+
+config UEFI_2_4_BINDING
+ def_bool n
diff --git a/src/vendorcode/intel/Makefile.inc b/src/vendorcode/intel/Makefile.inc
index 2cb486b599..b95d4f9c76 100644
--- a/src/vendorcode/intel/Makefile.inc
+++ b/src/vendorcode/intel/Makefile.inc
@@ -25,3 +25,13 @@ ramstage-y += $(FSP_C_INPUTS)
CFLAGS_x86_32 += -Isrc/vendorcode/intel/$(FSP_PATH)/include
endif
+
+ifeq ($(CONFIG_UEFI_2_4_BINDING),y)
+# ProccessorBind.h provided in Ia32 directory. Types are derived from ia32.
+# It's possible to provide our own ProcessorBind.h using posix types. However,
+# ProcessorBind.h isn't just about types. There's compiler definitions as well
+# as ABI enforcement. Luckily long is not used in Ia32/ProcessorBind.h for
+# a fixed width type.
+CPPFLAGS_common += -I$(src)/vendorcode/intel/edk2/uefi_2.4/MdePkg/Include/Ia32
+CPPFLAGS_common += -I$(src)/vendorcode/intel/edk2/uefi_2.4/MdePkg/Include
+endif
diff --git a/src/vendorcode/intel/edk2/uefi_2.4/uefi_types.h b/src/vendorcode/intel/edk2/uefi_2.4/uefi_types.h
index e17361ed0c..e68f8c9fb0 100644
--- a/src/vendorcode/intel/edk2/uefi_2.4/uefi_types.h
+++ b/src/vendorcode/intel/edk2/uefi_2.4/uefi_types.h
@@ -37,15 +37,15 @@ are permitted provided that the following conditions are met:
#define __APPLE__ 0
#include <stdlib.h>
#include <Uefi/UefiBaseType.h>
-#include <MdePkg/Include/Pi/PiBootMode.h>
-#include <MdePkg/Include/Pi/PiFirmwareFile.h>
-#include <MdePkg/Include/Pi/PiFirmwareVolume.h>
-#include <MdePkg/Include/Uefi/UefiMultiPhase.h>
-#include <MdePkg/Include/Pi/PiHob.h>
-#include <MdePkg/Include/Protocol/GraphicsOutput.h>
-#include <MdePkg/Include/Library/HobLib.h>
-#include <MdePkg/Include/Guid/FirmwareFileSystem2.h>
-#include <MdePkg/Include/IndustryStandard/PeImage.h>
+#include <Pi/PiBootMode.h>
+#include <Pi/PiFirmwareFile.h>
+#include <Pi/PiFirmwareVolume.h>
+#include <Uefi/UefiMultiPhase.h>
+#include <Pi/PiHob.h>
+#include <Protocol/GraphicsOutput.h>
+#include <Library/HobLib.h>
+#include <Guid/FirmwareFileSystem2.h>
+#include <IndustryStandard/PeImage.h>
///
/// For GNU assembly code, .global or .globl can declare global symbols.