[U-Boot] [PATCH 00/18] x86: efi: Fixes and enhancements to application and payload support

Unfortunately the EFI x86 application and payload support have been broken for quite a while. This series addresses various bug fixes, plus several enhancements like toolchain compatibility (eg: kernel.org i386-linux-gcc), introduction of generic EFI payload which can run on any x86 board, and a EFI framebuffer driver for the payload.
This series is available at u-boot-x86/efi-working for testing.
Bin Meng (16): x86: doc: Fix reference to EFI doc in U-Boot x86: Conditionally build the pinctrl_ich6 driver x86: efi: app: Fix broken EFI application x86: efi: payload: Enforce toolchain to generate 64-bit EFI payload stub codes efi: Fix efi_uintn_t for 64-bit EFI payload x86: efi: Refactor the directory of EFI app and payload support x86: efi: payload: Add arch_cpu_init() x86: efi: payload: Minor clean up on error message output x86: Add generic EFI payload support x86: Drop QEMU-specific EFI payload support x86: baytrail: Drop EFI-specific test logics efi: stub: Pass EFI GOP information to U-Boot payload dm: video: Add an EFI framebuffer driver x86: efi: payload: Add EFI framebuffer driver support x86: Rename efi-x86 target to efi-x86_app x86: efi: app: Display correct CPU info during boot
Christian Gmeiner (2): dm: pci: Make ranges dt property optional dm: pci: Use a 1:1 mapping for bus <-> phy addresses
arch/x86/Kconfig | 9 +- arch/x86/cpu/Makefile | 5 +- arch/x86/cpu/baytrail/Kconfig | 7 +- arch/x86/cpu/baytrail/valleyview.c | 3 - arch/x86/{lib => cpu}/efi/Kconfig | 0 arch/x86/cpu/efi/Makefile | 9 +- arch/x86/cpu/efi/{efi.c => app.c} | 2 +- arch/x86/{lib => cpu}/efi/car.S | 0 arch/x86/{lib/efi/efi.c => cpu/efi/payload.c} | 11 +- arch/x86/cpu/intel_common/Makefile | 2 +- arch/x86/cpu/ivybridge/Kconfig | 1 + arch/x86/cpu/qemu/Makefile | 2 - arch/x86/cpu/qemu/qemu.c | 4 - arch/x86/dts/Makefile | 3 +- arch/x86/dts/{efi.dts => efi-x86_app.dts} | 4 +- arch/x86/dts/efi-x86_payload.dts | 40 ++++++ arch/x86/lib/Makefile | 7 +- arch/x86/lib/efi/Makefile | 7 - board/advantech/som-db5800-som-6867/Kconfig | 5 +- board/congatec/conga-qeval20-qa3-e3845/Kconfig | 5 +- board/dfi/dfi-bt700/Kconfig | 5 +- board/efi/Kconfig | 15 ++- board/efi/{efi-x86 => efi-x86_app}/Kconfig | 6 +- board/efi/{efi-x86 => efi-x86_app}/MAINTAINERS | 0 board/efi/{efi-x86 => efi-x86_app}/Makefile | 2 +- board/efi/{efi-x86/efi.c => efi-x86_app/app.c} | 0 board/efi/efi-x86_payload/Kconfig | 39 ++++++ board/efi/efi-x86_payload/MAINTAINERS | 7 + board/efi/efi-x86_payload/Makefile | 5 + board/efi/efi-x86_payload/start.S | 8 ++ board/emulation/qemu-x86/Kconfig | 6 +- board/intel/minnowmax/Kconfig | 5 +- .../{efi-x86_defconfig => efi-x86_app_defconfig} | 12 +- ...oad32_defconfig => efi-x86_payload32_defconfig} | 24 +--- ...oad64_defconfig => efi-x86_payload64_defconfig} | 24 +--- doc/README.x86 | 2 +- drivers/pci/pci-uclass.c | 33 +++-- drivers/video/Kconfig | 9 ++ drivers/video/Makefile | 1 + drivers/video/efi.c | 146 +++++++++++++++++++++ include/configs/{efi-x86.h => efi-x86_app.h} | 0 include/configs/efi-x86_payload.h | 32 +++++ include/efi.h | 35 +++++ include/efi_api.h | 4 + lib/efi/Makefile | 6 +- lib/efi/efi_stub.c | 23 +++- 46 files changed, 454 insertions(+), 121 deletions(-) rename arch/x86/{lib => cpu}/efi/Kconfig (100%) rename arch/x86/cpu/efi/{efi.c => app.c} (92%) rename arch/x86/{lib => cpu}/efi/car.S (100%) rename arch/x86/{lib/efi/efi.c => cpu/efi/payload.c} (97%) rename arch/x86/dts/{efi.dts => efi-x86_app.dts} (82%) create mode 100644 arch/x86/dts/efi-x86_payload.dts delete mode 100644 arch/x86/lib/efi/Makefile rename board/efi/{efi-x86 => efi-x86_app}/Kconfig (64%) rename board/efi/{efi-x86 => efi-x86_app}/MAINTAINERS (100%) rename board/efi/{efi-x86 => efi-x86_app}/Makefile (82%) rename board/efi/{efi-x86/efi.c => efi-x86_app/app.c} (100%) create mode 100644 board/efi/efi-x86_payload/Kconfig create mode 100644 board/efi/efi-x86_payload/MAINTAINERS create mode 100644 board/efi/efi-x86_payload/Makefile create mode 100644 board/efi/efi-x86_payload/start.S rename configs/{efi-x86_defconfig => efi-x86_app_defconfig} (83%) rename configs/{qemu-x86_efi_payload32_defconfig => efi-x86_payload32_defconfig} (61%) rename configs/{qemu-x86_efi_payload64_defconfig => efi-x86_payload64_defconfig} (62%) create mode 100644 drivers/video/efi.c rename include/configs/{efi-x86.h => efi-x86_app.h} (100%) create mode 100644 include/configs/efi-x86_payload.h

Since commit f3b5056c4e72 ("efi_loader: split README.efi into two separate documents"), the original README.efi was renamed to README.u-boot_on_efi, but x86 doc still refers to the old one.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
doc/README.x86 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/README.x86 b/doc/README.x86 index 78664c3..865a965 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -1139,7 +1139,7 @@ application, with CONFIG_EFI_APP. The CONFIG_EFI_LOADER option, where U-Booot provides an EFI environment to the kernel (i.e. replaces UEFI completely but provides the same EFI run-time services) is not currently supported on x86.
-See README.efi for details of EFI support in U-Boot. +See README.u-boot_on_efi for details of EFI support in U-Boot.
64-bit Support --------------

On 06/10/2018 03:25 PM, Bin Meng wrote:
Since commit f3b5056c4e72 ("efi_loader: split README.efi into two separate documents"), the original README.efi was renamed to README.u-boot_on_efi, but x86 doc still refers to the old one.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
doc/README.x86 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/README.x86 b/doc/README.x86 index 78664c3..865a965 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -1139,7 +1139,7 @@ application, with CONFIG_EFI_APP. The CONFIG_EFI_LOADER option, where U-Booot provides an EFI environment to the kernel (i.e. replaces UEFI completely but provides the same EFI run-time services) is not currently supported on x86.
-See README.efi for details of EFI support in U-Boot. +See for details of EFI support in U-Boot.
Thanks for updating the references.
The chapter "EFI Support" refers both to running U-Boot as an EFI payload as well as using U-Boot as an EFI platform. So both doc/README.u-boot_on_efi and doc/README.uefi should be referenced.
But I would prefer if you could also move the sentences concerning EFI that has spilled over into "64-bit Support" into the "EFI Support" chapter.
Best regards
Heinrich
64-bit Support

Hi Heinrich,
On Sun, Jun 10, 2018 at 9:39 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/10/2018 03:25 PM, Bin Meng wrote:
Since commit f3b5056c4e72 ("efi_loader: split README.efi into two separate documents"), the original README.efi was renamed to README.u-boot_on_efi, but x86 doc still refers to the old one.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
doc/README.x86 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/README.x86 b/doc/README.x86 index 78664c3..865a965 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -1139,7 +1139,7 @@ application, with CONFIG_EFI_APP. The CONFIG_EFI_LOADER option, where U-Booot provides an EFI environment to the kernel (i.e. replaces UEFI completely but provides the same EFI run-time services) is not currently supported on x86.
-See README.efi for details of EFI support in U-Boot. +See for details of EFI support in U-Boot.
Thanks for updating the references.
The chapter "EFI Support" refers both to running U-Boot as an EFI payload as well as using U-Boot as an EFI platform. So both doc/README.u-boot_on_efi and doc/README.uefi should be referenced.
OK, will do in v2. One question: the doc says: CONFIG_EFI_LOADER option is not currently supported on x86. Is this still the case, or outdated? (I haven't tried the EFI loader on x86 or ARM yet)
But I would prefer if you could also move the sentences concerning EFI that has spilled over into "64-bit Support" into the "EFI Support" chapter.
Sure.
Regards, Bin

On 06/10/2018 04:01 PM, Bin Meng wrote:
Hi Heinrich,
On Sun, Jun 10, 2018 at 9:39 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/10/2018 03:25 PM, Bin Meng wrote:
Since commit f3b5056c4e72 ("efi_loader: split README.efi into two separate documents"), the original README.efi was renamed to README.u-boot_on_efi, but x86 doc still refers to the old one.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
doc/README.x86 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/README.x86 b/doc/README.x86 index 78664c3..865a965 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -1139,7 +1139,7 @@ application, with CONFIG_EFI_APP. The CONFIG_EFI_LOADER option, where U-Booot provides an EFI environment to the kernel (i.e. replaces UEFI completely but provides the same EFI run-time services) is not currently supported on x86.
-See README.efi for details of EFI support in U-Boot. +See for details of EFI support in U-Boot.
Thanks for updating the references.
The chapter "EFI Support" refers both to running U-Boot as an EFI payload as well as using U-Boot as an EFI platform. So both doc/README.u-boot_on_efi and doc/README.uefi should be referenced.
OK, will do in v2. One question: the doc says: CONFIG_EFI_LOADER option is not currently supported on x86. Is this still the case, or outdated? (I haven't tried the EFI loader on x86 or ARM yet)
qemu-x86_defconfig has CONFIG_EFI_LOADER enabled by default. bootefi selftest is successful.
But loading Linux fails by trying to use video memory as normal memory.
E.g. memory reservations according to e820 table are missing.
Patch https://patchwork.ozlabs.org/patch/860400/ is not sufficient to resolve the issue.
I lack the knowledge which memory regions have to be reserved on the platform.
Best regards
Heinrich
But I would prefer if you could also move the sentences concerning EFI that has spilled over into "64-bit Support" into the "EFI Support" chapter.
Sure.
Regards, Bin

The pinctrl_ich6 driver is currently unconditionally built for all x86 boards. Let's use a Kconfig option to control the build.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/Kconfig | 6 ++++++ arch/x86/cpu/baytrail/Kconfig | 1 + arch/x86/cpu/ivybridge/Kconfig | 1 + arch/x86/lib/Makefile | 2 +- 4 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index c145799..460aed6 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -744,6 +744,12 @@ config I8259_PIC slave) interrupt controllers. Include this to have U-Boot set up the interrupt correctly.
+config PINCTRL_ICH6 + bool + help + Intel ICH6 compatible chipset pinctrl driver. It needs to work + together with the ICH6 compatible gpio driver. + config I8254_TIMER bool default y diff --git a/arch/x86/cpu/baytrail/Kconfig b/arch/x86/cpu/baytrail/Kconfig index ac58b03..022a9f2 100644 --- a/arch/x86/cpu/baytrail/Kconfig +++ b/arch/x86/cpu/baytrail/Kconfig @@ -12,6 +12,7 @@ config INTEL_BAYTRAIL imply AHCI_PCI imply ICH_SPI imply INTEL_ICH6_GPIO + imply PINCTRL_ICH6 imply MMC imply MMC_PCI imply MMC_SDHCI diff --git a/arch/x86/cpu/ivybridge/Kconfig b/arch/x86/cpu/ivybridge/Kconfig index e31c33c..ea25ff3 100644 --- a/arch/x86/cpu/ivybridge/Kconfig +++ b/arch/x86/cpu/ivybridge/Kconfig @@ -13,6 +13,7 @@ config NORTHBRIDGE_INTEL_IVYBRIDGE imply AHCI_PCI imply ICH_SPI imply INTEL_ICH6_GPIO + imply PINCTRL_ICH6 imply SCSI imply SCSI_AHCI imply SPI_FLASH diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index 51d451f..2adb236 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -24,7 +24,7 @@ obj-$(CONFIG_ENABLE_MRC_CACHE) += mrccache.o obj-y += northbridge-uclass.o obj-$(CONFIG_I8259_PIC) += i8259.o obj-$(CONFIG_I8254_TIMER) += i8254.o -obj-y += pinctrl_ich6.o +obj-$(CONFIG_PINCTRL_ICH6) += pinctrl_ich6.o obj-y += pirq_routing.o obj-y += relocate.o obj-y += physmem.o

On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
The pinctrl_ich6 driver is currently unconditionally built for all x86 boards. Let's use a Kconfig option to control the build.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/Kconfig | 6 ++++++ arch/x86/cpu/baytrail/Kconfig | 1 + arch/x86/cpu/ivybridge/Kconfig | 1 + arch/x86/lib/Makefile | 2 +- 4 files changed, 9 insertions(+), 1 deletion(-)
Reviewed-by: Simon Glass sjg@chromium.org

On Mon, Jun 11, 2018 at 10:53 PM, Simon Glass sjg@chromium.org wrote:
On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
The pinctrl_ich6 driver is currently unconditionally built for all x86 boards. Let's use a Kconfig option to control the build.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/Kconfig | 6 ++++++ arch/x86/cpu/baytrail/Kconfig | 1 + arch/x86/cpu/ivybridge/Kconfig | 1 + arch/x86/lib/Makefile | 2 +- 4 files changed, 9 insertions(+), 1 deletion(-)
Reviewed-by: Simon Glass sjg@chromium.org
applied to u-boot-x86, thanks!

The EFI application does not boot currently. It's due to the call to syscon_get_by_driver_data() in cpu_init_r() maps to nowhere as CONFIG_SYSCON is not included in the configuration.
EFI application is built as a shared library, so GCC won't complain during the build process if some symbols are not found. GCC will simply put these symbols into the .plt section and expect dynamic loader to fix these up.
While we are here, remove some commands and drivers that are not needed at present.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
configs/efi-x86_defconfig | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/configs/efi-x86_defconfig b/configs/efi-x86_defconfig index 4cf5554..741a169 100644 --- a/configs/efi-x86_defconfig +++ b/configs/efi-x86_defconfig @@ -11,12 +11,8 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_LAST_STAGE_INIT=y CONFIG_HUSH_PARSER=y # CONFIG_CMD_BOOTM is not set -CONFIG_CMD_GPIO=y CONFIG_CMD_PART=y -CONFIG_CMD_SF=y # CONFIG_CMD_SF_TEST is not set -CONFIG_CMD_SPI=y -CONFIG_CMD_USB=y # CONFIG_CMD_NET is not set CONFIG_CMD_TIME=y CONFIG_CMD_EXT2=y @@ -28,12 +24,12 @@ CONFIG_MAC_PARTITION=y CONFIG_ISO_PARTITION=y CONFIG_EFI_PARTITION=y CONFIG_OF_EMBED=y +CONFIG_REGMAP=y +CONFIG_SYSCON=y # CONFIG_DM_ETH is not set CONFIG_DEBUG_EFI_CONSOLE=y CONFIG_DEBUG_UART_BASE=0 CONFIG_DEBUG_UART_CLOCK=0 -CONFIG_SPI=y -CONFIG_ICH_SPI=y # CONFIG_REGEX is not set CONFIG_EFI=y # CONFIG_EFI_LOADER is not set

On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
The EFI application does not boot currently. It's due to the call to syscon_get_by_driver_data() in cpu_init_r() maps to nowhere as CONFIG_SYSCON is not included in the configuration.
EFI application is built as a shared library, so GCC won't complain during the build process if some symbols are not found. GCC will simply put these symbols into the .plt section and expect dynamic loader to fix these up.
While we are here, remove some commands and drivers that are not needed at present.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
configs/efi-x86_defconfig | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org

On Mon, Jun 11, 2018 at 10:53 PM, Simon Glass sjg@chromium.org wrote:
On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
The EFI application does not boot currently. It's due to the call to syscon_get_by_driver_data() in cpu_init_r() maps to nowhere as CONFIG_SYSCON is not included in the configuration.
EFI application is built as a shared library, so GCC won't complain during the build process if some symbols are not found. GCC will simply put these symbols into the .plt section and expect dynamic loader to fix these up.
While we are here, remove some commands and drivers that are not needed at present.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
configs/efi-x86_defconfig | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
applied to u-boot-x86, thanks!

On 06/10/2018 03:25 PM, Bin Meng wrote:
The EFI application does not boot currently. It's due to the call to syscon_get_by_driver_data() in cpu_init_r() maps to nowhere as CONFIG_SYSCON is not included in the configuration.
EFI application is built as a shared library, so GCC won't complain during the build process if some symbols are not found. GCC will simply put these symbols into the .plt section and expect dynamic loader to fix these up.
While we are here, remove some commands and drivers that are not needed at present.
This patch is not applicable to master:
Applying: x86: efi: app: Fix broken EFI application error: patch failed: configs/efi-x86_defconfig:28 error: configs/efi-x86_defconfig: patch does not apply
Please, rebase.
Best regards
Heinrich
Signed-off-by: Bin Meng bmeng.cn@gmail.com
configs/efi-x86_defconfig | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/configs/efi-x86_defconfig b/configs/efi-x86_defconfig index 4cf5554..741a169 100644 --- a/configs/efi-x86_defconfig +++ b/configs/efi-x86_defconfig @@ -11,12 +11,8 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_LAST_STAGE_INIT=y CONFIG_HUSH_PARSER=y # CONFIG_CMD_BOOTM is not set -CONFIG_CMD_GPIO=y CONFIG_CMD_PART=y -CONFIG_CMD_SF=y # CONFIG_CMD_SF_TEST is not set -CONFIG_CMD_SPI=y -CONFIG_CMD_USB=y # CONFIG_CMD_NET is not set CONFIG_CMD_TIME=y CONFIG_CMD_EXT2=y @@ -28,12 +24,12 @@ CONFIG_MAC_PARTITION=y CONFIG_ISO_PARTITION=y CONFIG_EFI_PARTITION=y CONFIG_OF_EMBED=y +CONFIG_REGMAP=y +CONFIG_SYSCON=y # CONFIG_DM_ETH is not set CONFIG_DEBUG_EFI_CONSOLE=y CONFIG_DEBUG_UART_BASE=0 CONFIG_DEBUG_UART_CLOCK=0 -CONFIG_SPI=y -CONFIG_ICH_SPI=y # CONFIG_REGEX is not set CONFIG_EFI=y # CONFIG_EFI_LOADER is not set

Hi Heinrich,
On Tue, Jun 12, 2018 at 1:18 AM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/10/2018 03:25 PM, Bin Meng wrote:
The EFI application does not boot currently. It's due to the call to syscon_get_by_driver_data() in cpu_init_r() maps to nowhere as CONFIG_SYSCON is not included in the configuration.
EFI application is built as a shared library, so GCC won't complain during the build process if some symbols are not found. GCC will simply put these symbols into the .plt section and expect dynamic loader to fix these up.
While we are here, remove some commands and drivers that are not needed at present.
This patch is not applicable to master:
Applying: x86: efi: app: Fix broken EFI application error: patch failed: configs/efi-x86_defconfig:28 error: configs/efi-x86_defconfig: patch does not apply
Please, rebase.
Will do in v2. But if you want some testing, please use u-boot-x86/efi-working branch. Thanks!
Regards, Bin

Attempting to use a toolchain that is preconfigured to generate code for the 32-bit architecture (i386), for example, the i386-linux-gcc toolchain on kernel.org, to compile the 64-bit EFI payload does not build. This updates the makefile fragments to ensure '-m64' is passed to toolchain when building the 64-bit EFI payload stub codes.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/Makefile | 3 ++- arch/x86/lib/Makefile | 4 ++-- lib/efi/Makefile | 6 ++++-- 3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile index d5a17d0..af9e26c 100644 --- a/arch/x86/cpu/Makefile +++ b/arch/x86/cpu/Makefile @@ -18,7 +18,8 @@ obj-y += cpu.o cpu_x86.o ifndef CONFIG_$(SPL_)X86_64 AFLAGS_REMOVE_call32.o := -mregparm=3 \ $(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32) -AFLAGS_call32.o := -fpic -fshort-wchar +AFLAGS_call32.o := -fpic -fshort-wchar \ + $(if $(CONFIG_EFI_STUB_64BIT),-m64)
extra-y += call32.o endif diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index 2adb236..112ac3d 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -58,10 +58,10 @@ CFLAGS_reloc_ia32_efi.o += -fpic -fshort-wchar
# When building for 64-bit we must remove the i386-specific flags CFLAGS_REMOVE_reloc_x86_64_efi.o += -mregparm=3 -march=i386 -m32 -CFLAGS_reloc_x86_64_efi.o += -fpic -fshort-wchar +CFLAGS_reloc_x86_64_efi.o += -fpic -fshort-wchar -m64
AFLAGS_REMOVE_crt0_x86_64_efi.o += -mregparm=3 -march=i386 -m32 -AFLAGS_crt0_x86_64_efi.o += -fpic -fshort-wchar +AFLAGS_crt0_x86_64_efi.o += -fpic -fshort-wchar -m64
extra-$(CONFIG_EFI_STUB_32BIT) += crt0_ia32_efi.o reloc_ia32_efi.o extra-$(CONFIG_EFI_STUB_64BIT) += crt0_x86_64_efi.o reloc_x86_64_efi.o diff --git a/lib/efi/Makefile b/lib/efi/Makefile index 18d081a..f1a3929 100644 --- a/lib/efi/Makefile +++ b/lib/efi/Makefile @@ -7,9 +7,11 @@ obj-$(CONFIG_EFI_STUB) += efi_info.o
CFLAGS_REMOVE_efi_stub.o := -mregparm=3 \ $(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32) -CFLAGS_efi_stub.o := -fpic -fshort-wchar -DEFI_STUB +CFLAGS_efi_stub.o := -fpic -fshort-wchar -DEFI_STUB \ + $(if $(CONFIG_EFI_STUB_64BIT),-m64) CFLAGS_REMOVE_efi.o := -mregparm=3 \ $(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32) -CFLAGS_efi.o := -fpic -fshort-wchar -DEFI_STUB +CFLAGS_efi.o := -fpic -fshort-wchar -DEFI_STUB \ + $(if $(CONFIG_EFI_STUB_64BIT),-m64)
extra-$(CONFIG_EFI_STUB) += efi_stub.o efi.o

On 10.06.18 15:25, Bin Meng wrote:
Attempting to use a toolchain that is preconfigured to generate code for the 32-bit architecture (i386), for example, the i386-linux-gcc toolchain on kernel.org, to compile the 64-bit EFI payload does not build. This updates the makefile fragments to ensure '-m64' is passed to toolchain when building the 64-bit EFI payload stub codes.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Is there any sane reason to keep the split between EFI and U-Boot long size alive? The x86_64 U-Boot port is getting along reasonably well from what I can tell and 32bit UEFI implementations on 64-bit hosts are dying out.
So can't we just remove all of that cruft altogether instead and just have x86_64 U-Boot with 64bit EFI stub and i386 U-Boot with 32bit EFI stub as only combinations?
That would dramatically simplify the code.
Alex

On Mon, Jun 11, 2018 at 3:11 AM, Alexander Graf agraf@suse.de wrote:
On 10.06.18 15:25, Bin Meng wrote:
Attempting to use a toolchain that is preconfigured to generate code for the 32-bit architecture (i386), for example, the i386-linux-gcc toolchain on kernel.org, to compile the 64-bit EFI payload does not build. This updates the makefile fragments to ensure '-m64' is passed to toolchain when building the 64-bit EFI payload stub codes.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Is there any sane reason to keep the split between EFI and U-Boot long size alive? The x86_64 U-Boot port is getting along reasonably well from what I can tell and 32bit UEFI implementations on 64-bit hosts are dying out.
I think you are mixing two type of things. U-Boot building as 32-bit or 64-bit is one thing. How to build U-Boot is another thing. This patch was to address the build.
So can't we just remove all of that cruft altogether instead and just have x86_64 U-Boot with 64bit EFI stub and i386 U-Boot with 32bit EFI stub as only combinations?
Some day once U-Boot x86_64 support is mature, we can consider that. Even if we only support 64-bit U-Boot as the 64-bit EFI payload, that does not mean i386-linux-gcc cannot be used. '-m64' is required to pass to such toolchain to cross-compile 64-bit codes correctly.
That would dramatically simplify the code.
Regards, Bin

On 11.06.18 04:34, Bin Meng wrote:
On Mon, Jun 11, 2018 at 3:11 AM, Alexander Graf agraf@suse.de wrote:
On 10.06.18 15:25, Bin Meng wrote:
Attempting to use a toolchain that is preconfigured to generate code for the 32-bit architecture (i386), for example, the i386-linux-gcc toolchain on kernel.org, to compile the 64-bit EFI payload does not build. This updates the makefile fragments to ensure '-m64' is passed to toolchain when building the 64-bit EFI payload stub codes.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Is there any sane reason to keep the split between EFI and U-Boot long size alive? The x86_64 U-Boot port is getting along reasonably well from what I can tell and 32bit UEFI implementations on 64-bit hosts are dying out.
I think you are mixing two type of things. U-Boot building as 32-bit or 64-bit is one thing. How to build U-Boot is another thing. This patch was to address the build.
So can't we just remove all of that cruft altogether instead and just have x86_64 U-Boot with 64bit EFI stub and i386 U-Boot with 32bit EFI stub as only combinations?
Some day once U-Boot x86_64 support is mature, we can consider that. Even if we only support 64-bit U-Boot as the 64-bit EFI payload, that does not mean i386-linux-gcc cannot be used. '-m64' is required to pass to such toolchain to cross-compile 64-bit codes correctly.
Yes, but then all of this would be unconditional for the full code base and not depend on CONFIG_EFI_STUB_64BIT at all :).
I'm just wary that the efi payload code is quite hard to follow with all the combinations of 32/64 payload/u-boot bitnesses.
Alex

Hi Alex,
On Mon, Jun 11, 2018 at 1:55 PM, Alexander Graf agraf@suse.de wrote:
On 11.06.18 04:34, Bin Meng wrote:
On Mon, Jun 11, 2018 at 3:11 AM, Alexander Graf agraf@suse.de wrote:
On 10.06.18 15:25, Bin Meng wrote:
Attempting to use a toolchain that is preconfigured to generate code for the 32-bit architecture (i386), for example, the i386-linux-gcc toolchain on kernel.org, to compile the 64-bit EFI payload does not build. This updates the makefile fragments to ensure '-m64' is passed to toolchain when building the 64-bit EFI payload stub codes.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Is there any sane reason to keep the split between EFI and U-Boot long size alive? The x86_64 U-Boot port is getting along reasonably well from what I can tell and 32bit UEFI implementations on 64-bit hosts are dying out.
I think you are mixing two type of things. U-Boot building as 32-bit or 64-bit is one thing. How to build U-Boot is another thing. This patch was to address the build.
So can't we just remove all of that cruft altogether instead and just have x86_64 U-Boot with 64bit EFI stub and i386 U-Boot with 32bit EFI stub as only combinations?
Some day once U-Boot x86_64 support is mature, we can consider that. Even if we only support 64-bit U-Boot as the 64-bit EFI payload, that does not mean i386-linux-gcc cannot be used. '-m64' is required to pass to such toolchain to cross-compile 64-bit codes correctly.
Yes, but then all of this would be unconditional for the full code base and not depend on CONFIG_EFI_STUB_64BIT at all :).
No, it is not unconditional. The '-m64' flag will only be added when compiling efi_stub.c if CONFIG_EFI_STUB_64BIT is on. See below.
CFLAGS_efi_stub.o := -fpic -fshort-wchar -DEFI_STUB \ $(if $(CONFIG_EFI_STUB_64BIT),-m64)
I'm just wary that the efi payload code is quite hard to follow with all the combinations of 32/64 payload/u-boot bitnesses.
Yes, but not that bad. Still manageable :)
Regards, Bin

On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
Attempting to use a toolchain that is preconfigured to generate code for the 32-bit architecture (i386), for example, the i386-linux-gcc toolchain on kernel.org, to compile the 64-bit EFI payload does not build. This updates the makefile fragments to ensure '-m64' is passed to toolchain when building the 64-bit EFI payload stub codes.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/Makefile | 3 ++- arch/x86/lib/Makefile | 4 ++-- lib/efi/Makefile | 6 ++++-- 3 files changed, 8 insertions(+), 5 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
Nice to get this working with an i386 compiler!

On Mon, Jun 11, 2018 at 10:53 PM, Simon Glass sjg@chromium.org wrote:
On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
Attempting to use a toolchain that is preconfigured to generate code for the 32-bit architecture (i386), for example, the i386-linux-gcc toolchain on kernel.org, to compile the 64-bit EFI payload does not build. This updates the makefile fragments to ensure '-m64' is passed to toolchain when building the 64-bit EFI payload stub codes.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/Makefile | 3 ++- arch/x86/lib/Makefile | 4 ++-- lib/efi/Makefile | 6 ++++-- 3 files changed, 8 insertions(+), 5 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
Nice to get this working with an i386 compiler!
applied to u-boot-x86, thanks!

Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86 64-bit payload does not work anymore. The call to GetMemoryMap() in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since the payload itself is still 32-bit U-Boot, efi_uintn_t gets wrongly interpreted as int, but it should actually be long in a 64-bit EFI environment.
Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t") Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
include/efi_api.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h index 64c27e4..d1158de 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -28,7 +28,11 @@ enum efi_timer_delay { EFI_TIMER_RELATIVE = 2 };
+#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB) +#define efi_uintn_t unsigned long +#else #define efi_uintn_t size_t +#endif typedef uint16_t *efi_string_t;
#define EVT_TIMER 0x80000000

On 06/10/2018 03:25 PM, Bin Meng wrote:
Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86 64-bit payload does not work anymore. The call to GetMemoryMap() in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since the payload itself is still 32-bit U-Boot
Above you say 64-bit payload and now you say 32-bit?
Why don't you compile U-Boot as 64-bit? How do you want to load a 64bit Linux EFI stub from an 32-bit EFI implementation in U-Boot?
, efi_uintn_t gets wrongly interpreted as int, but it should actually be long in a 64-bit EFI environment.
Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t") Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/efi_api.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h index 64c27e4..d1158de 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -28,7 +28,11 @@ enum efi_timer_delay { EFI_TIMER_RELATIVE = 2 };
+#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB) +#define efi_uintn_t unsigned long +#else #define efi_uintn_t size_t
NAK
This change will create a lot of build warnings if EFI_STUB and EFI_LOADER are both configured.
Could you, please, explain under which compiler settings size_t and unsigned long have a different number of bits?
Obviously we have the EFI API exposed by U-Boot which has the bitness of U-Boot.
If you want to consume an EFI API of another bitness I suggest that you create separate interface definitions.
Best regards
Heinrich Schuchardt
+#endif typedef uint16_t *efi_string_t;
#define EVT_TIMER 0x80000000

Hi Heinrich,
On Sun, Jun 10, 2018 at 10:02 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/10/2018 03:25 PM, Bin Meng wrote:
Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86 64-bit payload does not work anymore. The call to GetMemoryMap() in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since the payload itself is still 32-bit U-Boot
Above you say 64-bit payload and now you say 32-bit?
Why don't you compile U-Boot as 64-bit? How do you want to load a 64bit Linux EFI stub from an 32-bit EFI implementation in U-Boot?
U-Boot itself as the EFI pyaload is 32-bit. The EFI stub is 64-bit as it has to be loaded from the 64-bit EFI BIOS. Note in case you misunderstand: the generated u-boot-payload.efi is 64-bit stub codes (for 64-bit EFI BIOS) or 32-bit stub codes (for 32-bit EFI BIOS) plus 32-bit U-Boot payload. The payload is always 32-bit as of today as U-Boot on x86 is mainly on 32-bit. 64-bit support, as you see from README.x86, is far from mature yet.
, efi_uintn_t gets wrongly interpreted as int, but it should actually be long in a 64-bit EFI environment.
Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t") Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/efi_api.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h index 64c27e4..d1158de 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -28,7 +28,11 @@ enum efi_timer_delay { EFI_TIMER_RELATIVE = 2 };
+#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB) +#define efi_uintn_t unsigned long +#else #define efi_uintn_t size_t
NAK
This change will create a lot of build warnings if EFI_STUB and EFI_LOADER are both configured.
I don't see any build warnings when building efi-x86_payload32 or efi-x86_payload64. I see both EFI_STUB and EFI_LOADER are enabled with these two targets. AFAIK, only x86 supports EFI_STUB currently. I don't know where you see a lot of build warnings.
Could you, please, explain under which compiler settings size_t and unsigned long have a different number of bits?
As mentioned above, the EFI stub codes (efi_stub.c) are built for 64-bit, which expects 'efi_uintn_t' to be 64-bit. However, it is defined as size_t, which in U-Boot 32, will be 'unsigned int' (see arch/x86/include/asm/posix_types.h) - the bug here!
Obviously we have the EFI API exposed by U-Boot which has the bitness of U-Boot.
If you want to consume an EFI API of another bitness I suggest that you create separate interface definitions.
Regards, Bin

On 06/10/2018 04:30 PM, Bin Meng wrote:
Hi Heinrich,
On Sun, Jun 10, 2018 at 10:02 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/10/2018 03:25 PM, Bin Meng wrote:
Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86 64-bit payload does not work anymore. The call to GetMemoryMap() in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since the payload itself is still 32-bit U-Boot
Above you say 64-bit payload and now you say 32-bit?
Why don't you compile U-Boot as 64-bit? How do you want to load a 64bit Linux EFI stub from an 32-bit EFI implementation in U-Boot?
U-Boot itself as the EFI pyaload is 32-bit. The EFI stub is 64-bit as it has to be loaded from the 64-bit EFI BIOS. Note in case you misunderstand: the generated u-boot-payload.efi is 64-bit stub codes (for 64-bit EFI BIOS) or 32-bit stub codes (for 32-bit EFI BIOS) plus 32-bit U-Boot payload. The payload is always 32-bit as of today as U-Boot on x86 is mainly on 32-bit. 64-bit support, as you see from README.x86, is far from mature yet.
, efi_uintn_t gets wrongly interpreted as int, but it should actually be long in a 64-bit EFI environment.
Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t") Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/efi_api.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h index 64c27e4..d1158de 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -28,7 +28,11 @@ enum efi_timer_delay { EFI_TIMER_RELATIVE = 2 };
+#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB) +#define efi_uintn_t unsigned long +#else #define efi_uintn_t size_t
NAK
This change will create a lot of build warnings if EFI_STUB and EFI_LOADER are both configured.
I don't see any build warnings when building efi-x86_payload32 or efi-x86_payload64. I see both EFI_STUB and EFI_LOADER are enabled with these two targets. AFAIK, only x86 supports EFI_STUB currently. I don't know where you see a lot of build warnings.
Currently you cannot build with EFI_LOADER=Y on 32 bit with a 64bit stub. See lib/efi_loader/Kconfig. The problem is with the build scripts for the stub using the same CONFIG variables as those used for other binaries.
To emulate what would happen with your change once we can build with EFI_LOADER=y and 64bit stub I made the following change:
--- a/include/efi_api.h +++ b/include/efi_api.h @@ -28,7 +28,8 @@ enum efi_timer_delay { EFI_TIMER_RELATIVE = 2 };
-#define efi_uintn_t size_t +#define efi_uintn_t unsigned long typedef uint16_t *efi_string_t;
And then I tried to build: make qemu-x86_defconfig make -j6
It gives me a bunch of errors like below.
^~~~~~~~~ include/efi_loader.h:31:8: warning: format ‘%zu’ expects argument of type ‘size_t’, but argument 13 has type ‘long unsigned int’ [-Wformat=] debug("%sEFI: Entry %s(" format ")\n", __efi_nesting_inc(), \ ^ include/linux/printk.h:37:21: note: in definition of macro ‘pr_fmt’ #define pr_fmt(fmt) fmt ^~~ include/log.h:141:2: note: in expansion of macro ‘debug_cond’ debug_cond(_DEBUG, fmt, ##args) ^~~~~~~~~~ include/efi_loader.h:31:2: note: in expansion of macro ‘debug’ debug("%sEFI: Entry %s(" format ")\n", __efi_nesting_inc(), \ ^~~~~ lib/efi_loader/efi_gop.c:333:2: note: in expansion of macro ‘EFI_ENTRY’ EFI_ENTRY("%p, %p, %u, %zu, %zu, %zu, %zu, %zu, %zu, %zu", this, ^~~~~~~~~ In file included from include/linux/bug.h:7:0, from include/common.h:25, from lib/efi_loader/efi_disk.c:8: lib/efi_loader/efi_disk.c: In function ‘efi_disk_read_blocks’: include/efi_loader.h:31:8: warning: format ‘%zx’ expects argument of type ‘size_t’, but argument 7 has type ‘long unsigned int’ [-Wformat=] debug("%sEFI: Entry %s(" format ")\n", __efi_nesting_inc(), \ ^ include/linux/printk.h:37:21: note: in definition of macro ‘pr_fmt’ #define pr_fmt(fmt) fmt ^~~ include/log.h:141:2: note: in expansion of macro ‘debug_cond’ debug_cond(_DEBUG, fmt, ##args) ^~~~~~~~~~ include/efi_loader.h:31:2: note: in expansion of macro ‘debug’ debug("%sEFI: Entry %s(" format ")\n", __efi_nesting_inc(), \ ^~~~~ lib/efi_loader/efi_disk.c:114:2: note: in expansion of macro ‘EFI_ENTRY’ EFI_ENTRY("%p, %x, %" PRIx64 ", %zx, %p", this, media_id, lba, ^~~~~~~~~ lib/efi_loader/efi_disk.c: In function ‘efi_disk_write_blocks’: include/efi_loader.h:31:8: warning: format ‘%zx’ expects argument of type ‘size_t’, but argument 7 has type ‘long unsigned int’ [-Wformat=] debug("%sEFI: Entry %s(" format ")\n", __efi_nesting_inc(), \ ^ include/linux/printk.h:37:21: note: in definition of macro ‘pr_fmt’ #define pr_fmt(fmt) fmt ^~~ include/log.h:141:2: note: in expansion of macro ‘debug_cond’ debug_cond(_DEBUG, fmt, ##args) ^~~~~~~~~~ include/efi_loader.h:31:2: note: in expansion of macro ‘debug’ debug("%sEFI: Entry %s(" format ")\n", __efi_nesting_inc(), \
So, please, do not change the type of efi_uintn_t.
What is needed is using different types in lib/efi_loader/ and in the calls to the primary firmware if they have different bitness.
Best regards
Heinrich
Could you, please, explain under which compiler settings size_t and unsigned long have a different number of bits?
As mentioned above, the EFI stub codes (efi_stub.c) are built for 64-bit, which expects 'efi_uintn_t' to be 64-bit. However, it is defined as size_t, which in U-Boot 32, will be 'unsigned int' (see arch/x86/include/asm/posix_types.h) - the bug here!
Obviously we have the EFI API exposed by U-Boot which has the bitness of U-Boot.
If you want to consume an EFI API of another bitness I suggest that you create separate interface definitions.
Regards, Bin

Hi Heinrich,
On Mon, Jun 11, 2018 at 2:17 AM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/10/2018 04:30 PM, Bin Meng wrote:
Hi Heinrich,
On Sun, Jun 10, 2018 at 10:02 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/10/2018 03:25 PM, Bin Meng wrote:
Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86 64-bit payload does not work anymore. The call to GetMemoryMap() in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since the payload itself is still 32-bit U-Boot
Above you say 64-bit payload and now you say 32-bit?
Why don't you compile U-Boot as 64-bit? How do you want to load a 64bit Linux EFI stub from an 32-bit EFI implementation in U-Boot?
U-Boot itself as the EFI pyaload is 32-bit. The EFI stub is 64-bit as it has to be loaded from the 64-bit EFI BIOS. Note in case you misunderstand: the generated u-boot-payload.efi is 64-bit stub codes (for 64-bit EFI BIOS) or 32-bit stub codes (for 32-bit EFI BIOS) plus 32-bit U-Boot payload. The payload is always 32-bit as of today as U-Boot on x86 is mainly on 32-bit. 64-bit support, as you see from README.x86, is far from mature yet.
, efi_uintn_t gets wrongly interpreted as int, but it should actually be long in a 64-bit EFI environment.
Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t") Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/efi_api.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h index 64c27e4..d1158de 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -28,7 +28,11 @@ enum efi_timer_delay { EFI_TIMER_RELATIVE = 2 };
+#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB) +#define efi_uintn_t unsigned long +#else #define efi_uintn_t size_t
NAK
This change will create a lot of build warnings if EFI_STUB and EFI_LOADER are both configured.
I don't see any build warnings when building efi-x86_payload32 or efi-x86_payload64. I see both EFI_STUB and EFI_LOADER are enabled with these two targets. AFAIK, only x86 supports EFI_STUB currently. I don't know where you see a lot of build warnings.
Currently you cannot build with EFI_LOADER=Y on 32 bit with a 64bit stub. See lib/efi_loader/Kconfig. The problem is with the build scripts for the stub using the same CONFIG variables as those used for other binaries.
To emulate what would happen with your change once we can build with EFI_LOADER=y and 64bit stub I made the following change:
--- a/include/efi_api.h +++ b/include/efi_api.h @@ -28,7 +28,8 @@ enum efi_timer_delay { EFI_TIMER_RELATIVE = 2 };
-#define efi_uintn_t size_t +#define efi_uintn_t unsigned long typedef uint16_t *efi_string_t;
I am not sure why do you unconditionally change efi_uintn_t? My patch has
#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB)
to guard the change.
And then I tried to build: make qemu-x86_defconfig make -j6
I know. But my patch does not produce any build warnings on efi-x86_payload32_defconfig and efi-x86_payload64_defconfig, on u-boot-x86/efi-working branch.
It gives me a bunch of errors like below.
[snip]
Regards, Bin

On 06/11/2018 01:36 AM, Bin Meng wrote:
Hi Heinrich,
On Mon, Jun 11, 2018 at 2:17 AM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/10/2018 04:30 PM, Bin Meng wrote:
Hi Heinrich,
On Sun, Jun 10, 2018 at 10:02 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/10/2018 03:25 PM, Bin Meng wrote:
Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86 64-bit payload does not work anymore. The call to GetMemoryMap() in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since the payload itself is still 32-bit U-Boot
Above you say 64-bit payload and now you say 32-bit?
Why don't you compile U-Boot as 64-bit? How do you want to load a 64bit Linux EFI stub from an 32-bit EFI implementation in U-Boot?
U-Boot itself as the EFI pyaload is 32-bit. The EFI stub is 64-bit as it has to be loaded from the 64-bit EFI BIOS. Note in case you misunderstand: the generated u-boot-payload.efi is 64-bit stub codes (for 64-bit EFI BIOS) or 32-bit stub codes (for 32-bit EFI BIOS) plus 32-bit U-Boot payload. The payload is always 32-bit as of today as U-Boot on x86 is mainly on 32-bit. 64-bit support, as you see from README.x86, is far from mature yet.
, efi_uintn_t gets wrongly interpreted as int, but it should actually be long in a 64-bit EFI environment.
Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t") Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/efi_api.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h index 64c27e4..d1158de 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -28,7 +28,11 @@ enum efi_timer_delay { EFI_TIMER_RELATIVE = 2 };
+#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB) +#define efi_uintn_t unsigned long +#else #define efi_uintn_t size_t
NAK
This change will create a lot of build warnings if EFI_STUB and EFI_LOADER are both configured.
I don't see any build warnings when building efi-x86_payload32 or efi-x86_payload64. I see both EFI_STUB and EFI_LOADER are enabled with these two targets. AFAIK, only x86 supports EFI_STUB currently. I don't know where you see a lot of build warnings.
Currently you cannot build with EFI_LOADER=Y on 32 bit with a 64bit stub. See lib/efi_loader/Kconfig. The problem is with the build scripts for the stub using the same CONFIG variables as those used for other binaries.
To emulate what would happen with your change once we can build with EFI_LOADER=y and 64bit stub I made the following change:
--- a/include/efi_api.h +++ b/include/efi_api.h @@ -28,7 +28,8 @@ enum efi_timer_delay { EFI_TIMER_RELATIVE = 2 };
-#define efi_uintn_t size_t +#define efi_uintn_t unsigned long typedef uint16_t *efi_string_t;
I am not sure why do you unconditionally change efi_uintn_t? My patch has
#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB)
Currently it is not possible to enable CONFIG_EFI_STUB_64BIT and EFI_LOADER on 32bit U-Boot. Once we have removed this restriction in the build system your patch together with EFI_LOADER=y and CONFIG_EFI_STUB_64BIT=y will provoke all those errors. This is why I NAKed you patch.
Best regards
Heinrich
to guard the change.
And then I tried to build: make qemu-x86_defconfig make -j6
I know. But my patch does not produce any build warnings on efi-x86_payload32_defconfig and efi-x86_payload64_defconfig, on u-boot-x86/efi-working branch.
It gives me a bunch of errors like below.
[snip]
Regards, Bin

Hi Heinrich,
On Mon, Jun 11, 2018 at 11:31 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/11/2018 01:36 AM, Bin Meng wrote:
Hi Heinrich,
On Mon, Jun 11, 2018 at 2:17 AM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/10/2018 04:30 PM, Bin Meng wrote:
Hi Heinrich,
On Sun, Jun 10, 2018 at 10:02 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/10/2018 03:25 PM, Bin Meng wrote:
Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86 64-bit payload does not work anymore. The call to GetMemoryMap() in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since the payload itself is still 32-bit U-Boot
Above you say 64-bit payload and now you say 32-bit?
Why don't you compile U-Boot as 64-bit? How do you want to load a 64bit Linux EFI stub from an 32-bit EFI implementation in U-Boot?
U-Boot itself as the EFI pyaload is 32-bit. The EFI stub is 64-bit as it has to be loaded from the 64-bit EFI BIOS. Note in case you misunderstand: the generated u-boot-payload.efi is 64-bit stub codes (for 64-bit EFI BIOS) or 32-bit stub codes (for 32-bit EFI BIOS) plus 32-bit U-Boot payload. The payload is always 32-bit as of today as U-Boot on x86 is mainly on 32-bit. 64-bit support, as you see from README.x86, is far from mature yet.
, efi_uintn_t gets wrongly interpreted as int, but it should actually be long in a 64-bit EFI environment.
Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t") Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/efi_api.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h index 64c27e4..d1158de 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -28,7 +28,11 @@ enum efi_timer_delay { EFI_TIMER_RELATIVE = 2 };
+#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB) +#define efi_uintn_t unsigned long +#else #define efi_uintn_t size_t
NAK
This change will create a lot of build warnings if EFI_STUB and EFI_LOADER are both configured.
I don't see any build warnings when building efi-x86_payload32 or efi-x86_payload64. I see both EFI_STUB and EFI_LOADER are enabled with these two targets. AFAIK, only x86 supports EFI_STUB currently. I don't know where you see a lot of build warnings.
Currently you cannot build with EFI_LOADER=Y on 32 bit with a 64bit stub. See lib/efi_loader/Kconfig. The problem is with the build scripts for the stub using the same CONFIG variables as those used for other binaries.
To emulate what would happen with your change once we can build with EFI_LOADER=y and 64bit stub I made the following change:
--- a/include/efi_api.h +++ b/include/efi_api.h @@ -28,7 +28,8 @@ enum efi_timer_delay { EFI_TIMER_RELATIVE = 2 };
-#define efi_uintn_t size_t +#define efi_uintn_t unsigned long typedef uint16_t *efi_string_t;
I am not sure why do you unconditionally change efi_uintn_t? My patch has
#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB)
Currently it is not possible to enable CONFIG_EFI_STUB_64BIT and EFI_LOADER on 32bit U-Boot. Once we have removed this restriction in the build system your patch together with EFI_LOADER=y and CONFIG_EFI_STUB_64BIT=y will provoke all those errors. This is why I NAKed you patch.
I did the following to try to reproduce what you saw:
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index d38780b..29e67b6 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -3,10 +3,6 @@ config EFI_LOADER depends on (ARM || X86) && OF_LIBFDT # We do not support bootefi booting ARMv7 in non-secure mode depends on !ARMV7_NONSEC - # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB - depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT - # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB - depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT default y select LIB_UUID select HAVE_BLOCK_DEVICE
Then do a $ make efi-x86_payload32_defconfig $ make
It succeeded without any error
But doing: $ make efi-x86_payload64_defconfig $ make
Failed with a different error (no compiler warning were seen)
toolchains/gcc-7.3.0-nolibc/i386-linux/bin/i386-linux-ld.bfd: i386 architecture of input file `lib/efi_loader/helloworld.o' is incompatible with i386:x86-64 output scripts/Makefile.lib:407: recipe for target 'lib/efi_loader/helloworld_efi.so' failed
Switching to x86_64-linux-gcc, exposed the same error:
toolchains/gcc-7.3.0-nolibc/x86_64-linux/bin/x86_64-linux-ld.bfd: i386 architecture of input file `lib/efi_loader/helloworld.o' is incompatible with i386:x86-64 output
Regards, Bin

On 06/11/2018 06:35 PM, Bin Meng wrote:
Hi Heinrich,
On Mon, Jun 11, 2018 at 11:31 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/11/2018 01:36 AM, Bin Meng wrote:
Hi Heinrich,
On Mon, Jun 11, 2018 at 2:17 AM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/10/2018 04:30 PM, Bin Meng wrote:
Hi Heinrich,
On Sun, Jun 10, 2018 at 10:02 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/10/2018 03:25 PM, Bin Meng wrote: > Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86 > 64-bit payload does not work anymore. The call to GetMemoryMap() > in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since > the payload itself is still 32-bit U-Boot
Above you say 64-bit payload and now you say 32-bit?
Why don't you compile U-Boot as 64-bit? How do you want to load a 64bit Linux EFI stub from an 32-bit EFI implementation in U-Boot?
U-Boot itself as the EFI pyaload is 32-bit. The EFI stub is 64-bit as it has to be loaded from the 64-bit EFI BIOS. Note in case you misunderstand: the generated u-boot-payload.efi is 64-bit stub codes (for 64-bit EFI BIOS) or 32-bit stub codes (for 32-bit EFI BIOS) plus 32-bit U-Boot payload. The payload is always 32-bit as of today as U-Boot on x86 is mainly on 32-bit. 64-bit support, as you see from README.x86, is far from mature yet.
> , efi_uintn_t gets wrongly > interpreted as int, but it should actually be long in a 64-bit EFI > environment. > > Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t") > Signed-off-by: Bin Meng bmeng.cn@gmail.com > --- > > include/efi_api.h | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/include/efi_api.h b/include/efi_api.h > index 64c27e4..d1158de 100644 > --- a/include/efi_api.h > +++ b/include/efi_api.h > @@ -28,7 +28,11 @@ enum efi_timer_delay { > EFI_TIMER_RELATIVE = 2 > }; > > +#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB) > +#define efi_uintn_t unsigned long > +#else > #define efi_uintn_t size_t
NAK
This change will create a lot of build warnings if EFI_STUB and EFI_LOADER are both configured.
I don't see any build warnings when building efi-x86_payload32 or efi-x86_payload64. I see both EFI_STUB and EFI_LOADER are enabled with these two targets. AFAIK, only x86 supports EFI_STUB currently. I don't know where you see a lot of build warnings.
Currently you cannot build with EFI_LOADER=Y on 32 bit with a 64bit stub. See lib/efi_loader/Kconfig. The problem is with the build scripts for the stub using the same CONFIG variables as those used for other binaries.
To emulate what would happen with your change once we can build with EFI_LOADER=y and 64bit stub I made the following change:
--- a/include/efi_api.h +++ b/include/efi_api.h @@ -28,7 +28,8 @@ enum efi_timer_delay { EFI_TIMER_RELATIVE = 2 };
-#define efi_uintn_t size_t +#define efi_uintn_t unsigned long typedef uint16_t *efi_string_t;
I am not sure why do you unconditionally change efi_uintn_t? My patch has
#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB)
Currently it is not possible to enable CONFIG_EFI_STUB_64BIT and EFI_LOADER on 32bit U-Boot. Once we have removed this restriction in the build system your patch together with EFI_LOADER=y and CONFIG_EFI_STUB_64BIT=y will provoke all those errors. This is why I NAKed you patch.
My mistake was to confuse EFI_STUB and CONFIG_EFI_STUB.
EFI_STUB is only defined in lib/efi/Makefile when compiling lib/efi/efi.c and lib/efi/efi_stub.c
These two files are compiled with -m64 when CONFIG_EFI_STUB_64BIT=y.
The problem should be fixed in arch/x86/include/asm/posix_types.h
That way anybody using size_t in lib/efi/ can be sure that size_t has the same size as a pointer, cf:
lib/efi/efi_stub.c:92: void *memcpy(void *dest, const void *src, size_t size) lib/efi/efi_stub.c:104: void *memset(void *inptr, int ch, size_t size)
I did the following to try to reproduce what you saw:
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index d38780b..29e67b6 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -3,10 +3,6 @@ config EFI_LOADER depends on (ARM || X86) && OF_LIBFDT # We do not support bootefi booting ARMv7 in non-secure mode depends on !ARMV7_NONSEC
# We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB
depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT
# We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT default y select LIB_UUID select HAVE_BLOCK_DEVICE
Then do a $ make efi-x86_payload32_defconfig $ make
It succeeded without any error
But doing: $ make efi-x86_payload64_defconfig $ make
Failed with a different error (no compiler warning were seen)
toolchains/gcc-7.3.0-nolibc/i386-linux/bin/i386-linux-ld.bfd: i386 architecture of input file `lib/efi_loader/helloworld.o' is incompatible with i386:x86-64 output scripts/Makefile.lib:407: recipe for target 'lib/efi_loader/helloworld_efi.so' failed
This is due to using variable EFI_LDS, EFI_CRT0, and EFI_RELOC both when building the stub (64bit) and helloworld (32bit) (see arch/x86/config.mk).
To resolve the issue we would have to use different values for the stub and the other EFI payloads (helloworld and efi_selftest_miniapp_*).
Best regards
Heinrich
Switching to x86_64-linux-gcc, exposed the same error:
toolchains/gcc-7.3.0-nolibc/x86_64-linux/bin/x86_64-linux-ld.bfd: i386 architecture of input file `lib/efi_loader/helloworld.o' is incompatible with i386:x86-64 output
Regards, Bin

Hi Alex,
On Sun, Jun 10, 2018 at 9:25 PM, Bin Meng bmeng.cn@gmail.com wrote:
Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86 64-bit payload does not work anymore. The call to GetMemoryMap() in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since the payload itself is still 32-bit U-Boot, efi_uintn_t gets wrongly interpreted as int, but it should actually be long in a 64-bit EFI environment.
Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t") Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/efi_api.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h index 64c27e4..d1158de 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -28,7 +28,11 @@ enum efi_timer_delay { EFI_TIMER_RELATIVE = 2 };
+#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB) +#define efi_uintn_t unsigned long +#else #define efi_uintn_t size_t +#endif typedef uint16_t *efi_string_t;
#define EVT_TIMER 0x80000000
With your proposed changes to efi.h in [1], do you think we should also fix this by:
#ifdef __x86_64__ #define efi_uintn_t unsigned long #else #define efi_uintn_t size_t
[1] https://lists.denx.de/pipermail/u-boot/2018-June/331193.html
Regards, Bin

On 11.06.18 11:11, Bin Meng wrote:
Hi Alex,
On Sun, Jun 10, 2018 at 9:25 PM, Bin Meng bmeng.cn@gmail.com wrote:
Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86 64-bit payload does not work anymore. The call to GetMemoryMap() in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since the payload itself is still 32-bit U-Boot, efi_uintn_t gets wrongly interpreted as int, but it should actually be long in a 64-bit EFI environment.
Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t") Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/efi_api.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h index 64c27e4..d1158de 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -28,7 +28,11 @@ enum efi_timer_delay { EFI_TIMER_RELATIVE = 2 };
+#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB) +#define efi_uintn_t unsigned long +#else #define efi_uintn_t size_t +#endif typedef uint16_t *efi_string_t;
#define EVT_TIMER 0x80000000
With your proposed changes to efi.h in [1], do you think we should also fix this by:
#ifdef __x86_64__ #define efi_uintn_t unsigned long #else #define efi_uintn_t size_t
Can't we just change the definition in arch/x86/include/asm/posix_types.h to adhere to __x86_64__ instead? Then the typedef would just simply always go to size_t.
Alex

From: Christian Gmeiner christian.gmeiner@gmail.com
If we use U-Boot as coreboot payload with a generic dts without any ranges specified we fail in pci pre_probe and our pci bus is not usable.
So convert decode_regions(..) into a void function and do the simple error handling there.
Signed-off-by: Christian Gmeiner christian.gmeiner@gmail.com Reviewed-by: Bin Meng bmeng.cn@gmail.com [bmeng: fixed 'u-boot' in the commit message and checkpatch warning] Signed-off-by: Bin Meng bmeng.cn@gmail.com
---
drivers/pci/pci-uclass.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c index 1cd1e40..de4c71b 100644 --- a/drivers/pci/pci-uclass.c +++ b/drivers/pci/pci-uclass.c @@ -810,8 +810,8 @@ error: return ret; }
-static int decode_regions(struct pci_controller *hose, ofnode parent_node, - ofnode node) +static void decode_regions(struct pci_controller *hose, ofnode parent_node, + ofnode node) { int pci_addr_cells, addr_cells, size_cells; int cells_per_record; @@ -820,8 +820,11 @@ static int decode_regions(struct pci_controller *hose, ofnode parent_node, int i;
prop = ofnode_get_property(node, "ranges", &len); - if (!prop) - return -EINVAL; + if (!prop) { + debug("%s: Cannot decode regions\n", __func__); + return; + } + pci_addr_cells = ofnode_read_simple_addr_cells(node); addr_cells = ofnode_read_simple_addr_cells(parent_node); size_cells = ofnode_read_simple_size_cells(node); @@ -883,7 +886,7 @@ static int decode_regions(struct pci_controller *hose, ofnode parent_node, bd_t *bd = gd->bd;
if (!bd) - return 0; + return;
for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) { if (bd->bi_dram[i].size) { @@ -908,13 +911,12 @@ static int decode_regions(struct pci_controller *hose, ofnode parent_node, base, size, PCI_REGION_MEM | PCI_REGION_SYS_MEMORY); #endif
- return 0; + return; }
static int pci_uclass_pre_probe(struct udevice *bus) { struct pci_controller *hose; - int ret;
debug("%s, bus=%d/%s, parent=%s\n", __func__, bus->seq, bus->name, bus->parent->name); @@ -923,12 +925,7 @@ static int pci_uclass_pre_probe(struct udevice *bus) /* For bridges, use the top-level PCI controller */ if (!device_is_on_pci_bus(bus)) { hose->ctlr = bus; - ret = decode_regions(hose, dev_ofnode(bus->parent), - dev_ofnode(bus)); - if (ret) { - debug("%s: Cannot decode regions\n", __func__); - return ret; - } + decode_regions(hose, dev_ofnode(bus->parent), dev_ofnode(bus)); } else { struct pci_controller *parent_hose;

On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
From: Christian Gmeiner christian.gmeiner@gmail.com
If we use U-Boot as coreboot payload with a generic dts without any ranges specified we fail in pci pre_probe and our pci bus is not usable.
So convert decode_regions(..) into a void function and do the simple error handling there.
Signed-off-by: Christian Gmeiner christian.gmeiner@gmail.com Reviewed-by: Bin Meng bmeng.cn@gmail.com [bmeng: fixed 'u-boot' in the commit message and checkpatch warning] Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/pci/pci-uclass.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org

On Mon, Jun 11, 2018 at 10:53 PM, Simon Glass sjg@chromium.org wrote:
On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
From: Christian Gmeiner christian.gmeiner@gmail.com
If we use U-Boot as coreboot payload with a generic dts without any ranges specified we fail in pci pre_probe and our pci bus is not usable.
So convert decode_regions(..) into a void function and do the simple error handling there.
Signed-off-by: Christian Gmeiner christian.gmeiner@gmail.com Reviewed-by: Bin Meng bmeng.cn@gmail.com [bmeng: fixed 'u-boot' in the commit message and checkpatch warning] Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/pci/pci-uclass.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
applied to u-boot-x86, thanks!

From: Christian Gmeiner christian.gmeiner@gmail.com
If U-Boot gets used as coreboot payload all pci resources got assigned by coreboot. If a dts without any pci ranges gets used the dm is not able to access pci device memory. To get things working make use of a 1:1 mapping for bus <-> phy addresses.
This change makes it possible to get the e1000 U-Boot driver working on a sandybridge device where U-Boot is used as coreboot payload.
Signed-off-by: Christian Gmeiner christian.gmeiner@gmail.com Reviewed-by: Bin Meng bmeng.cn@gmail.com [bmeng: fixed 'u-boot' in the commit message] Signed-off-by: Bin Meng bmeng.cn@gmail.com
---
drivers/pci/pci-uclass.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c index de4c71b..46e9c71 100644 --- a/drivers/pci/pci-uclass.c +++ b/drivers/pci/pci-uclass.c @@ -1182,6 +1182,11 @@ static int _dm_pci_bus_to_phys(struct udevice *ctlr, struct pci_region *res; int i;
+ if (hose->region_count == 0) { + *pa = bus_addr; + return 0; + } + for (i = 0; i < hose->region_count; i++) { res = &hose->regions[i];
@@ -1245,6 +1250,11 @@ int _dm_pci_phys_to_bus(struct udevice *dev, phys_addr_t phys_addr, ctlr = pci_get_controller(dev); hose = dev_get_uclass_priv(ctlr);
+ if (hose->region_count == 0) { + *ba = phys_addr; + return 0; + } + for (i = 0; i < hose->region_count; i++) { res = &hose->regions[i];

On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
From: Christian Gmeiner christian.gmeiner@gmail.com
If U-Boot gets used as coreboot payload all pci resources got assigned by coreboot. If a dts without any pci ranges gets used the dm is not able to access pci device memory. To get things working make use of a 1:1 mapping for bus <-> phy addresses.
This change makes it possible to get the e1000 U-Boot driver working on a sandybridge device where U-Boot is used as coreboot payload.
Signed-off-by: Christian Gmeiner christian.gmeiner@gmail.com Reviewed-by: Bin Meng bmeng.cn@gmail.com [bmeng: fixed 'u-boot' in the commit message] Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/pci/pci-uclass.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org

On Mon, Jun 11, 2018 at 10:54 PM, Simon Glass sjg@chromium.org wrote:
On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
From: Christian Gmeiner christian.gmeiner@gmail.com
If U-Boot gets used as coreboot payload all pci resources got assigned by coreboot. If a dts without any pci ranges gets used the dm is not able to access pci device memory. To get things working make use of a 1:1 mapping for bus <-> phy addresses.
This change makes it possible to get the e1000 U-Boot driver working on a sandybridge device where U-Boot is used as coreboot payload.
Signed-off-by: Christian Gmeiner christian.gmeiner@gmail.com Reviewed-by: Bin Meng bmeng.cn@gmail.com [bmeng: fixed 'u-boot' in the commit message] Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/pci/pci-uclass.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org
applied to u-boot-x86, thanks!

At present the EFI application and payload support codes in the x86 directory is distributed in a hybrid way. For example, the Kconfig options for both app and payload are in arch/x86/lib/efi/Kconfig, but the source codes in the same directory get built only for CONFIG_EFI_STUB.
This refactors the codes by consolidating all the EFI support codes into arch/x86/cpu/efi, just like other x86 targets.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/Kconfig | 3 +-- arch/x86/cpu/Makefile | 2 +- arch/x86/{lib => cpu}/efi/Kconfig | 0 arch/x86/cpu/efi/Makefile | 7 +++++++ arch/x86/{lib => cpu}/efi/car.S | 0 arch/x86/{lib/efi/efi.c => cpu/efi/payload.c} | 0 arch/x86/lib/Makefile | 1 - arch/x86/lib/efi/Makefile | 7 ------- 8 files changed, 9 insertions(+), 11 deletions(-) rename arch/x86/{lib => cpu}/efi/Kconfig (100%) rename arch/x86/{lib => cpu}/efi/car.S (100%) rename arch/x86/{lib/efi/efi.c => cpu/efi/payload.c} (100%) delete mode 100644 arch/x86/lib/efi/Makefile
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 460aed6..43fa30b 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -112,6 +112,7 @@ source "arch/x86/cpu/braswell/Kconfig" source "arch/x86/cpu/broadwell/Kconfig" source "arch/x86/cpu/coreboot/Kconfig" source "arch/x86/cpu/ivybridge/Kconfig" +source "arch/x86/cpu/efi/Kconfig" source "arch/x86/cpu/qemu/Kconfig" source "arch/x86/cpu/quark/Kconfig" source "arch/x86/cpu/queensbay/Kconfig" @@ -781,6 +782,4 @@ config HIGH_TABLE_SIZE Increse it if the default size does not fit the board's needs. This is most likely due to a large ACPI DSDT table is used.
-source "arch/x86/lib/efi/Kconfig" - endmenu diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile index af9e26c..f862d8c 100644 --- a/arch/x86/cpu/Makefile +++ b/arch/x86/cpu/Makefile @@ -29,7 +29,7 @@ obj-$(CONFIG_INTEL_BAYTRAIL) += baytrail/ obj-$(CONFIG_INTEL_BRASWELL) += braswell/ obj-$(CONFIG_INTEL_BROADWELL) += broadwell/ obj-$(CONFIG_SYS_COREBOOT) += coreboot/ -obj-$(CONFIG_EFI_APP) += efi/ +obj-$(CONFIG_EFI) += efi/ obj-$(CONFIG_QEMU) += qemu/ obj-$(CONFIG_NORTHBRIDGE_INTEL_IVYBRIDGE) += ivybridge/ obj-$(CONFIG_INTEL_QUARK) += quark/ diff --git a/arch/x86/lib/efi/Kconfig b/arch/x86/cpu/efi/Kconfig similarity index 100% rename from arch/x86/lib/efi/Kconfig rename to arch/x86/cpu/efi/Kconfig diff --git a/arch/x86/cpu/efi/Makefile b/arch/x86/cpu/efi/Makefile index 06d0480..32c2dde 100644 --- a/arch/x86/cpu/efi/Makefile +++ b/arch/x86/cpu/efi/Makefile @@ -2,5 +2,12 @@ # # Copyright (c) 2015 Google, Inc
+ifdef CONFIG_EFI_APP obj-y += efi.o obj-y += sdram.o +endif + +ifdef CONFIG_EFI_STUB +obj-y += car.o +obj-y += payload.o +endif diff --git a/arch/x86/lib/efi/car.S b/arch/x86/cpu/efi/car.S similarity index 100% rename from arch/x86/lib/efi/car.S rename to arch/x86/cpu/efi/car.S diff --git a/arch/x86/lib/efi/efi.c b/arch/x86/cpu/efi/payload.c similarity index 100% rename from arch/x86/lib/efi/efi.c rename to arch/x86/cpu/efi/payload.c diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index 112ac3d..ba83ce2 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -14,7 +14,6 @@ endif obj-y += cmd_boot.o obj-$(CONFIG_SEABIOS) += coreboot_table.o obj-y += early_cmos.o -obj-$(CONFIG_EFI) += efi/ obj-y += e820.o obj-y += init_helpers.o obj-y += interrupts.o diff --git a/arch/x86/lib/efi/Makefile b/arch/x86/lib/efi/Makefile deleted file mode 100644 index f6c6523..0000000 --- a/arch/x86/lib/efi/Makefile +++ /dev/null @@ -1,7 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0+ -# -# (C) Copyright 2002-2006 -# Wolfgang Denk, DENX Software Engineering, wd@denx.de. - -obj-$(CONFIG_EFI_STUB) += car.o -obj-$(CONFIG_EFI_STUB) += efi.o

On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
At present the EFI application and payload support codes in the x86 directory is distributed in a hybrid way. For example, the Kconfig options for both app and payload are in arch/x86/lib/efi/Kconfig, but the source codes in the same directory get built only for CONFIG_EFI_STUB.
This refactors the codes by consolidating all the EFI support codes into arch/x86/cpu/efi, just like other x86 targets.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/Kconfig | 3 +-- arch/x86/cpu/Makefile | 2 +- arch/x86/{lib => cpu}/efi/Kconfig | 0 arch/x86/cpu/efi/Makefile | 7 +++++++ arch/x86/{lib => cpu}/efi/car.S | 0 arch/x86/{lib/efi/efi.c => cpu/efi/payload.c} | 0 arch/x86/lib/Makefile | 1 - arch/x86/lib/efi/Makefile | 7 ------- 8 files changed, 9 insertions(+), 11 deletions(-) rename arch/x86/{lib => cpu}/efi/Kconfig (100%) rename arch/x86/{lib => cpu}/efi/car.S (100%) rename arch/x86/{lib/efi/efi.c => cpu/efi/payload.c} (100%) delete mode 100644 arch/x86/lib/efi/Makefile
Reviewed-by: Simon Glass sjg@chromium.org

This adds arch_cpu_init() to the payload codes, in preparation for supporting a generic efi payload.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/efi/payload.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/cpu/efi/payload.c b/arch/x86/cpu/efi/payload.c index 81fb8b5..9fd9f57 100644 --- a/arch/x86/cpu/efi/payload.c +++ b/arch/x86/cpu/efi/payload.c @@ -5,11 +5,9 @@ */
#include <common.h> -#include <debug_uart.h> #include <efi.h> #include <errno.h> -#include <linux/err.h> -#include <linux/types.h> +#include <asm/post.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -126,6 +124,13 @@ int dram_init_banksize(void) return 0; }
+int arch_cpu_init(void) +{ + post_code(POST_CPU_INIT); + + return x86_cpu_init_f(); +} + int checkcpu(void) { return 0;

On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
This adds arch_cpu_init() to the payload codes, in preparation for supporting a generic efi payload.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/efi/payload.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org

If GetMemoryMap() fails, we really want to know EFI_BITS_PER_LONG instead of BITS_PER_LONG. A space and LF are added in places where error message is output to improve readability.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
lib/efi/efi_stub.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c index 3138739..09023a2 100644 --- a/lib/efi/efi_stub.c +++ b/lib/efi/efi_stub.c @@ -281,7 +281,8 @@ efi_status_t efi_main(efi_handle_t image, struct efi_system_table *sys_table)
ret = efi_init(priv, "Payload", image, sys_table); if (ret) { - printhex2(ret); puts(" efi_init() failed\n"); + printhex2(ret); + puts(" efi_init() failed\n"); return ret; } global_priv = priv; @@ -294,7 +295,8 @@ efi_status_t efi_main(efi_handle_t image, struct efi_system_table *sys_table) size = 0; ret = boot->get_memory_map(&size, NULL, &key, &desc_size, &version); if (ret != EFI_BUFFER_TOO_SMALL) { - printhex2(BITS_PER_LONG); + printhex2(EFI_BITS_PER_LONG); + putc(' '); printhex2(ret); puts(" No memory map\n"); return ret; @@ -303,7 +305,7 @@ efi_status_t efi_main(efi_handle_t image, struct efi_system_table *sys_table) desc = efi_malloc(priv, size, &ret); if (!desc) { printhex2(ret); - puts(" No memory for memory descriptor: "); + puts(" No memory for memory descriptor\n"); return ret; } ret = setup_info_table(priv, size + 128);

On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
If GetMemoryMap() fails, we really want to know EFI_BITS_PER_LONG instead of BITS_PER_LONG. A space and LF are added in places where error message is output to improve readability.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
lib/efi/efi_stub.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org

On Mon, Jun 11, 2018 at 10:54 PM, Simon Glass sjg@chromium.org wrote:
On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
If GetMemoryMap() fails, we really want to know EFI_BITS_PER_LONG instead of BITS_PER_LONG. A space and LF are added in places where error message is output to improve readability.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
lib/efi/efi_stub.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
applied to u-boot-x86, thanks!

It is possible to create a generic EFI payload for all x86 boards. The payload is configured to include as many generic drivers as possible. All stuff that touches low-level initialization are not allowed as such is the EFI BIOS's responsibility. Platform specific drivers (like gpio, spi, etc) are not included.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/dts/Makefile | 1 + arch/x86/dts/efi-x86_payload.dts | 36 +++++++++++++++++++++++++++++++++ board/efi/Kconfig | 9 +++++++++ board/efi/efi-x86_payload/Kconfig | 38 +++++++++++++++++++++++++++++++++++ board/efi/efi-x86_payload/MAINTAINERS | 7 +++++++ board/efi/efi-x86_payload/Makefile | 5 +++++ board/efi/efi-x86_payload/start.S | 8 ++++++++ configs/efi-x86_payload32_defconfig | 35 ++++++++++++++++++++++++++++++++ configs/efi-x86_payload64_defconfig | 36 +++++++++++++++++++++++++++++++++ include/configs/efi-x86_payload.h | 32 +++++++++++++++++++++++++++++ 10 files changed, 207 insertions(+) create mode 100644 arch/x86/dts/efi-x86_payload.dts create mode 100644 board/efi/efi-x86_payload/Kconfig create mode 100644 board/efi/efi-x86_payload/MAINTAINERS create mode 100644 board/efi/efi-x86_payload/Makefile create mode 100644 board/efi/efi-x86_payload/start.S create mode 100644 configs/efi-x86_payload32_defconfig create mode 100644 configs/efi-x86_payload64_defconfig create mode 100644 include/configs/efi-x86_payload.h
diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile index 7379774..9872c04 100644 --- a/arch/x86/dts/Makefile +++ b/arch/x86/dts/Makefile @@ -11,6 +11,7 @@ dtb-y += bayleybay.dtb \ dfi-bt700-q7x-151.dtb \ edison.dtb \ efi.dtb \ + efi-x86_payload.dtb \ galileo.dtb \ minnowmax.dtb \ qemu-x86_i440fx.dtb \ diff --git a/arch/x86/dts/efi-x86_payload.dts b/arch/x86/dts/efi-x86_payload.dts new file mode 100644 index 0000000..137bde5 --- /dev/null +++ b/arch/x86/dts/efi-x86_payload.dts @@ -0,0 +1,36 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018, Bin Meng bmeng.cn@gmail.com + * + * Generic EFI payload device tree for x86 targets + */ + +/dts-v1/; + +/include/ "skeleton.dtsi" +/include/ "serial.dtsi" +/include/ "keyboard.dtsi" +/include/ "rtc.dtsi" +/include/ "tsc_timer.dtsi" + +/ { + model = "EFI x86 Payload"; + compatible = "efi,x86-payload"; + + aliases { + serial0 = &serial; + }; + + config { + silent_console = <0>; + }; + + chosen { + stdout-path = "/serial"; + }; + + pci { + compatible = "pci-x86"; + u-boot,dm-pre-reloc; + }; +}; diff --git a/board/efi/Kconfig b/board/efi/Kconfig index 6f86a48..d37f6ff 100644 --- a/board/efi/Kconfig +++ b/board/efi/Kconfig @@ -12,8 +12,17 @@ config TARGET_EFI takes over once the RAM, video and CPU are fully running. U-Boot is loaded as an application from EFI.
+config TARGET_EFI_PAYLOAD + bool "efi payload" + help + This target is used for running U-Boot on top of EFI. In + this case EFI does the early initialisation, and U-Boot + takes over once the RAM, video and CPU are fully running. + U-Boot is loaded as a payload from EFI. + endchoice
source "board/efi/efi-x86/Kconfig" +source "board/efi/efi-x86_payload/Kconfig"
endif diff --git a/board/efi/efi-x86_payload/Kconfig b/board/efi/efi-x86_payload/Kconfig new file mode 100644 index 0000000..dcf4de8 --- /dev/null +++ b/board/efi/efi-x86_payload/Kconfig @@ -0,0 +1,38 @@ +if TARGET_EFI_PAYLOAD + +config SYS_BOARD + default "efi-x86_payload" + +config SYS_VENDOR + default "efi" + +config SYS_SOC + default "efi" + +config SYS_CONFIG_NAME + default "efi-x86_payload" + +config SYS_TEXT_BASE + default 0x00200000 + +config BOARD_SPECIFIC_OPTIONS # dummy + def_bool y + imply SYS_NS16550 + imply SCSI + imply SCSI_AHCI + imply AHCI_PCI + imply MMC + imply MMC_PCI + imply MMC_SDHCI + imply MMC_SDHCI_SDMA + imply USB + imply USB_EHCI_HCD + imply USB_XHCI_HCD + imply USB_STORAGE + imply USB_KEYBOARD + imply E1000 + imply ETH_DESIGNWARE + imply PCH_GBE + imply RTL8169 + +endif diff --git a/board/efi/efi-x86_payload/MAINTAINERS b/board/efi/efi-x86_payload/MAINTAINERS new file mode 100644 index 0000000..abf3a15 --- /dev/null +++ b/board/efi/efi-x86_payload/MAINTAINERS @@ -0,0 +1,7 @@ +EFI-X86_PAYLOAD BOARD +M: Bin Meng bmeng.cn@gmail.com +S: Maintained +F: board/efi/efi-x86_payload/ +F: include/configs/efi-x86_payload.h +F: configs/efi-x86_payload32_defconfig +F: configs/efi-x86_payload64_defconfig diff --git a/board/efi/efi-x86_payload/Makefile b/board/efi/efi-x86_payload/Makefile new file mode 100644 index 0000000..6982340 --- /dev/null +++ b/board/efi/efi-x86_payload/Makefile @@ -0,0 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0+ +# +# Copyright (C) 2018, Bin Meng bmeng.cn@gmail.com + +obj-y += start.o diff --git a/board/efi/efi-x86_payload/start.S b/board/efi/efi-x86_payload/start.S new file mode 100644 index 0000000..f7eaa7c --- /dev/null +++ b/board/efi/efi-x86_payload/start.S @@ -0,0 +1,8 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (C) 2018, Bin Meng bmeng.cn@gmail.com + */ + +.globl early_board_init +early_board_init: + jmp early_board_init_ret diff --git a/configs/efi-x86_payload32_defconfig b/configs/efi-x86_payload32_defconfig new file mode 100644 index 0000000..7f0cab0 --- /dev/null +++ b/configs/efi-x86_payload32_defconfig @@ -0,0 +1,35 @@ +CONFIG_X86=y +CONFIG_VENDOR_EFI=y +CONFIG_DEFAULT_DEVICE_TREE="efi-x86_payload" +CONFIG_TARGET_EFI_PAYLOAD=y +CONFIG_FIT=y +CONFIG_FIT_SIGNATURE=y +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" +CONFIG_SYS_CONSOLE_INFO_QUIET=y +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_LAST_STAGE_INIT=y +CONFIG_HUSH_PARSER=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_IDE=y +CONFIG_CMD_MMC=y +CONFIG_CMD_PART=y +CONFIG_CMD_USB=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_DHCP=y +# CONFIG_CMD_NFS is not set +CONFIG_CMD_PING=y +CONFIG_CMD_TIME=y +CONFIG_CMD_EXT2=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_EXT4_WRITE=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +CONFIG_MAC_PARTITION=y +CONFIG_ISO_PARTITION=y +CONFIG_EFI_PARTITION=y +CONFIG_REGMAP=y +CONFIG_SYSCON=y +# CONFIG_PCI_PNP is not set +CONFIG_EFI=y +CONFIG_EFI_STUB=y diff --git a/configs/efi-x86_payload64_defconfig b/configs/efi-x86_payload64_defconfig new file mode 100644 index 0000000..8d7f3f0 --- /dev/null +++ b/configs/efi-x86_payload64_defconfig @@ -0,0 +1,36 @@ +CONFIG_X86=y +CONFIG_VENDOR_EFI=y +CONFIG_DEFAULT_DEVICE_TREE="efi-x86_payload" +CONFIG_TARGET_EFI_PAYLOAD=y +CONFIG_FIT=y +CONFIG_FIT_SIGNATURE=y +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" +CONFIG_SYS_CONSOLE_INFO_QUIET=y +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_LAST_STAGE_INIT=y +CONFIG_HUSH_PARSER=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_IDE=y +CONFIG_CMD_MMC=y +CONFIG_CMD_PART=y +CONFIG_CMD_USB=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_DHCP=y +# CONFIG_CMD_NFS is not set +CONFIG_CMD_PING=y +CONFIG_CMD_TIME=y +CONFIG_CMD_EXT2=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_EXT4_WRITE=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +CONFIG_MAC_PARTITION=y +CONFIG_ISO_PARTITION=y +CONFIG_EFI_PARTITION=y +CONFIG_REGMAP=y +CONFIG_SYSCON=y +# CONFIG_PCI_PNP is not set +CONFIG_EFI=y +CONFIG_EFI_STUB=y +CONFIG_EFI_STUB_64BIT=y diff --git a/include/configs/efi-x86_payload.h b/include/configs/efi-x86_payload.h new file mode 100644 index 0000000..9c62fd2 --- /dev/null +++ b/include/configs/efi-x86_payload.h @@ -0,0 +1,32 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (C) 2018, Bin Meng bmeng.cn@gmail.com + */ + +/* + * board/config.h - configuration options, board specific + */ + +#ifndef __CONFIG_H +#define __CONFIG_H + +#include <configs/x86-common.h> + +#define CONFIG_SYS_MONITOR_LEN (1 << 20) + +#define CONFIG_STD_DEVICES_SETTINGS "stdin=serial,i8042-kbd\0" \ + "stdout=serial,vidconsole\0" \ + "stderr=serial,vidconsole\0" + +/* ATA/IDE support */ +#define CONFIG_SYS_IDE_MAXBUS 2 +#define CONFIG_SYS_IDE_MAXDEVICE 4 +#define CONFIG_SYS_ATA_BASE_ADDR 0 +#define CONFIG_SYS_ATA_DATA_OFFSET 0 +#define CONFIG_SYS_ATA_REG_OFFSET 0 +#define CONFIG_SYS_ATA_ALT_OFFSET 0 +#define CONFIG_SYS_ATA_IDE0_OFFSET 0x1f0 +#define CONFIG_SYS_ATA_IDE1_OFFSET 0x170 +#define CONFIG_ATAPI + +#endif /* __CONFIG_H */

On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
It is possible to create a generic EFI payload for all x86 boards. The payload is configured to include as many generic drivers as possible. All stuff that touches low-level initialization are not allowed as such is the EFI BIOS's responsibility. Platform specific drivers (like gpio, spi, etc) are not included.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/dts/Makefile | 1 + arch/x86/dts/efi-x86_payload.dts | 36 +++++++++++++++++++++++++++++++++ board/efi/Kconfig | 9 +++++++++ board/efi/efi-x86_payload/Kconfig | 38 +++++++++++++++++++++++++++++++++++ board/efi/efi-x86_payload/MAINTAINERS | 7 +++++++ board/efi/efi-x86_payload/Makefile | 5 +++++ board/efi/efi-x86_payload/start.S | 8 ++++++++ configs/efi-x86_payload32_defconfig | 35 ++++++++++++++++++++++++++++++++ configs/efi-x86_payload64_defconfig | 36 +++++++++++++++++++++++++++++++++ include/configs/efi-x86_payload.h | 32 +++++++++++++++++++++++++++++ 10 files changed, 207 insertions(+) create mode 100644 arch/x86/dts/efi-x86_payload.dts create mode 100644 board/efi/efi-x86_payload/Kconfig create mode 100644 board/efi/efi-x86_payload/MAINTAINERS create mode 100644 board/efi/efi-x86_payload/Makefile create mode 100644 board/efi/efi-x86_payload/start.S create mode 100644 configs/efi-x86_payload32_defconfig create mode 100644 configs/efi-x86_payload64_defconfig create mode 100644 include/configs/efi-x86_payload.h
Reviewed-by: Simon Glass sjg@chromium.org

Now that we have generic EFI payload support for all x86 boards, drop the QEMU-specific one.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/qemu/Makefile | 2 -- arch/x86/cpu/qemu/qemu.c | 4 --- board/emulation/qemu-x86/Kconfig | 6 ++-- configs/qemu-x86_efi_payload32_defconfig | 47 ------------------------------- configs/qemu-x86_efi_payload64_defconfig | 48 -------------------------------- 5 files changed, 3 insertions(+), 104 deletions(-) delete mode 100644 configs/qemu-x86_efi_payload32_defconfig delete mode 100644 configs/qemu-x86_efi_payload64_defconfig
diff --git a/arch/x86/cpu/qemu/Makefile b/arch/x86/cpu/qemu/Makefile index e5ea925..1761244 100644 --- a/arch/x86/cpu/qemu/Makefile +++ b/arch/x86/cpu/qemu/Makefile @@ -2,8 +2,6 @@ # # Copyright (C) 2015, Bin Meng bmeng.cn@gmail.com
-ifndef CONFIG_EFI_STUB obj-y += car.o dram.o -endif obj-y += qemu.o obj-$(CONFIG_QFW) += cpu.o e820.o diff --git a/arch/x86/cpu/qemu/qemu.c b/arch/x86/cpu/qemu/qemu.c index 1fdb11c..ca4b3f0 100644 --- a/arch/x86/cpu/qemu/qemu.c +++ b/arch/x86/cpu/qemu/qemu.c @@ -143,10 +143,6 @@ int arch_cpu_init(void)
return x86_cpu_init_f(); } -#endif - -#if !CONFIG_IS_ENABLED(EFI_STUB) && \ - !CONFIG_IS_ENABLED(SPL_X86_32BIT_INIT)
int checkcpu(void) { diff --git a/board/emulation/qemu-x86/Kconfig b/board/emulation/qemu-x86/Kconfig index a593f8c..41a27dd 100644 --- a/board/emulation/qemu-x86/Kconfig +++ b/board/emulation/qemu-x86/Kconfig @@ -13,12 +13,12 @@ config SYS_CONFIG_NAME default "qemu-x86"
config SYS_TEXT_BASE - default 0xfff00000 if !EFI_STUB && !SUPPORT_SPL - default 0x01110000 if EFI_STUB || SUPPORT_SPL + default 0xfff00000 if !SUPPORT_SPL + default 0x01110000 if SUPPORT_SPL
config BOARD_SPECIFIC_OPTIONS # dummy def_bool y - select X86_RESET_VECTOR if !EFI_STUB + select X86_RESET_VECTOR select QEMU select BOARD_ROMSIZE_KB_1024
diff --git a/configs/qemu-x86_efi_payload32_defconfig b/configs/qemu-x86_efi_payload32_defconfig deleted file mode 100644 index 36705db..0000000 --- a/configs/qemu-x86_efi_payload32_defconfig +++ /dev/null @@ -1,47 +0,0 @@ -CONFIG_X86=y -CONFIG_SYS_TEXT_BASE=0x1110000 -CONFIG_MAX_CPUS=2 -CONFIG_DEFAULT_DEVICE_TREE="qemu-x86_i440fx" -CONFIG_SMP=y -CONFIG_FIT=y -CONFIG_BOOTSTAGE=y -CONFIG_BOOTSTAGE_REPORT=y -CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" -CONFIG_SYS_CONSOLE_INFO_QUIET=y -CONFIG_DISPLAY_BOARDINFO_LATE=y -CONFIG_LAST_STAGE_INIT=y -CONFIG_HUSH_PARSER=y -CONFIG_CMD_CPU=y -# CONFIG_CMD_FLASH is not set -CONFIG_CMD_IDE=y -CONFIG_CMD_PART=y -CONFIG_CMD_SF=y -CONFIG_CMD_SPI=y -CONFIG_CMD_USB=y -# CONFIG_CMD_SETEXPR is not set -CONFIG_CMD_DHCP=y -# CONFIG_CMD_NFS is not set -CONFIG_CMD_PING=y -CONFIG_CMD_TIME=y -CONFIG_CMD_QFW=y -CONFIG_CMD_BOOTSTAGE=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_EXT4=y -CONFIG_CMD_EXT4_WRITE=y -CONFIG_CMD_FAT=y -CONFIG_CMD_FS_GENERIC=y -CONFIG_MAC_PARTITION=y -CONFIG_ISO_PARTITION=y -CONFIG_EFI_PARTITION=y -CONFIG_REGMAP=y -CONFIG_SYSCON=y -CONFIG_CPU=y -CONFIG_SPI=y -CONFIG_USB_STORAGE=y -CONFIG_USB_KEYBOARD=y -CONFIG_FRAMEBUFFER_SET_VESA_MODE=y -CONFIG_FRAMEBUFFER_VESA_MODE_112=y -CONFIG_CONSOLE_SCROLL_LINES=5 -CONFIG_EFI=y -CONFIG_EFI_STUB=y diff --git a/configs/qemu-x86_efi_payload64_defconfig b/configs/qemu-x86_efi_payload64_defconfig deleted file mode 100644 index 5b0806b..0000000 --- a/configs/qemu-x86_efi_payload64_defconfig +++ /dev/null @@ -1,48 +0,0 @@ -CONFIG_X86=y -CONFIG_SYS_TEXT_BASE=0x1110000 -CONFIG_MAX_CPUS=2 -CONFIG_DEFAULT_DEVICE_TREE="qemu-x86_i440fx" -CONFIG_SMP=y -CONFIG_FIT=y -CONFIG_BOOTSTAGE=y -CONFIG_BOOTSTAGE_REPORT=y -CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" -CONFIG_SYS_CONSOLE_INFO_QUIET=y -CONFIG_DISPLAY_BOARDINFO_LATE=y -CONFIG_LAST_STAGE_INIT=y -CONFIG_HUSH_PARSER=y -CONFIG_CMD_CPU=y -# CONFIG_CMD_FLASH is not set -CONFIG_CMD_IDE=y -CONFIG_CMD_PART=y -CONFIG_CMD_SF=y -CONFIG_CMD_SPI=y -CONFIG_CMD_USB=y -# CONFIG_CMD_SETEXPR is not set -CONFIG_CMD_DHCP=y -# CONFIG_CMD_NFS is not set -CONFIG_CMD_PING=y -CONFIG_CMD_TIME=y -CONFIG_CMD_QFW=y -CONFIG_CMD_BOOTSTAGE=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_EXT4=y -CONFIG_CMD_EXT4_WRITE=y -CONFIG_CMD_FAT=y -CONFIG_CMD_FS_GENERIC=y -CONFIG_MAC_PARTITION=y -CONFIG_ISO_PARTITION=y -CONFIG_EFI_PARTITION=y -CONFIG_REGMAP=y -CONFIG_SYSCON=y -CONFIG_CPU=y -CONFIG_SPI=y -CONFIG_USB_STORAGE=y -CONFIG_USB_KEYBOARD=y -CONFIG_FRAMEBUFFER_SET_VESA_MODE=y -CONFIG_FRAMEBUFFER_VESA_MODE_112=y -CONFIG_CONSOLE_SCROLL_LINES=5 -CONFIG_EFI=y -CONFIG_EFI_STUB=y -CONFIG_EFI_STUB_64BIT=y

On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
Now that we have generic EFI payload support for all x86 boards, drop the QEMU-specific one.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/qemu/Makefile | 2 -- arch/x86/cpu/qemu/qemu.c | 4 --- board/emulation/qemu-x86/Kconfig | 6 ++-- configs/qemu-x86_efi_payload32_defconfig | 47 ------------------------------- configs/qemu-x86_efi_payload64_defconfig | 48 -------------------------------- 5 files changed, 3 insertions(+), 104 deletions(-) delete mode 100644 configs/qemu-x86_efi_payload32_defconfig delete mode 100644 configs/qemu-x86_efi_payload64_defconfig
Reviewed-by: Simon Glass sjg@chromium.org

Now that we have generic EFI payload support, drop EFI-specific test logics in BayTrail Kconfig and codes, and all BayTrail boards too.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/baytrail/Kconfig | 6 +++--- arch/x86/cpu/baytrail/valleyview.c | 3 --- board/advantech/som-db5800-som-6867/Kconfig | 5 ++--- board/congatec/conga-qeval20-qa3-e3845/Kconfig | 5 ++--- board/dfi/dfi-bt700/Kconfig | 5 ++--- board/intel/minnowmax/Kconfig | 5 ++--- 6 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/arch/x86/cpu/baytrail/Kconfig b/arch/x86/cpu/baytrail/Kconfig index 022a9f2..d2c3473 100644 --- a/arch/x86/cpu/baytrail/Kconfig +++ b/arch/x86/cpu/baytrail/Kconfig @@ -4,10 +4,10 @@
config INTEL_BAYTRAIL bool - select HAVE_FSP if !EFI - select ARCH_MISC_INIT if !EFI + select HAVE_FSP + select ARCH_MISC_INIT select CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED - imply HAVE_INTEL_ME if !EFI + imply HAVE_INTEL_ME imply ENABLE_MRC_CACHE imply AHCI_PCI imply ICH_SPI diff --git a/arch/x86/cpu/baytrail/valleyview.c b/arch/x86/cpu/baytrail/valleyview.c index 3194f8c..b7d481a 100644 --- a/arch/x86/cpu/baytrail/valleyview.c +++ b/arch/x86/cpu/baytrail/valleyview.c @@ -17,7 +17,6 @@ #define BYT_TRIG_LVL BIT(24) #define BYT_TRIG_POS BIT(25)
-#ifndef CONFIG_EFI_APP int arch_cpu_init(void) { post_code(POST_CPU_INIT); @@ -57,8 +56,6 @@ int arch_misc_init(void) return 0; }
-#endif - void reset_cpu(ulong addr) { /* cold reset */ diff --git a/board/advantech/som-db5800-som-6867/Kconfig b/board/advantech/som-db5800-som-6867/Kconfig index fac562a..35d58fc 100644 --- a/board/advantech/som-db5800-som-6867/Kconfig +++ b/board/advantech/som-db5800-som-6867/Kconfig @@ -13,12 +13,11 @@ config SYS_CONFIG_NAME default "som-db5800-som-6867"
config SYS_TEXT_BASE - default 0xfff00000 if !EFI_STUB - default 0x01110000 if EFI_STUB + default 0xfff00000
config BOARD_SPECIFIC_OPTIONS # dummy def_bool y - select X86_RESET_VECTOR if !EFI_STUB + select X86_RESET_VECTOR select INTEL_BAYTRAIL select BOARD_ROMSIZE_KB_8192 select BOARD_EARLY_INIT_F diff --git a/board/congatec/conga-qeval20-qa3-e3845/Kconfig b/board/congatec/conga-qeval20-qa3-e3845/Kconfig index 9e44413..6469250 100644 --- a/board/congatec/conga-qeval20-qa3-e3845/Kconfig +++ b/board/congatec/conga-qeval20-qa3-e3845/Kconfig @@ -12,12 +12,11 @@ config SYS_CONFIG_NAME default "theadorable-x86-conga-qa3-e3845" if TARGET_THEADORABLE_X86_CONGA_QA3_E3845
config SYS_TEXT_BASE - default 0xfff00000 if !EFI_STUB - default 0x01110000 if EFI_STUB + default 0xfff00000
config BOARD_SPECIFIC_OPTIONS # dummy def_bool y - select X86_RESET_VECTOR if !EFI_STUB + select X86_RESET_VECTOR select INTEL_BAYTRAIL select BOARD_ROMSIZE_KB_8192 select BOARD_EARLY_INIT_F diff --git a/board/dfi/dfi-bt700/Kconfig b/board/dfi/dfi-bt700/Kconfig index f92f50a..50c7b2a 100644 --- a/board/dfi/dfi-bt700/Kconfig +++ b/board/dfi/dfi-bt700/Kconfig @@ -12,12 +12,11 @@ config SYS_CONFIG_NAME default "theadorable-x86-dfi-bt700" if TARGET_THEADORABLE_X86_DFI_BT700
config SYS_TEXT_BASE - default 0xfff00000 if !EFI_STUB - default 0x01110000 if EFI_STUB + default 0xfff00000
config BOARD_SPECIFIC_OPTIONS # dummy def_bool y - select X86_RESET_VECTOR if !EFI_STUB + select X86_RESET_VECTOR select INTEL_BAYTRAIL select BOARD_ROMSIZE_KB_8192 select BOARD_EARLY_INIT_F diff --git a/board/intel/minnowmax/Kconfig b/board/intel/minnowmax/Kconfig index a8668e4..543468c 100644 --- a/board/intel/minnowmax/Kconfig +++ b/board/intel/minnowmax/Kconfig @@ -13,12 +13,11 @@ config SYS_CONFIG_NAME default "minnowmax"
config SYS_TEXT_BASE - default 0xfff00000 if !EFI_STUB - default 0x01110000 if EFI_STUB + default 0xfff00000
config BOARD_SPECIFIC_OPTIONS # dummy def_bool y - select X86_RESET_VECTOR if !EFI_STUB + select X86_RESET_VECTOR select INTEL_BAYTRAIL select BOARD_ROMSIZE_KB_8192 select SPI_FLASH_STMICRO

On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
Now that we have generic EFI payload support, drop EFI-specific test logics in BayTrail Kconfig and codes, and all BayTrail boards too.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/baytrail/Kconfig | 6 +++--- arch/x86/cpu/baytrail/valleyview.c | 3 --- board/advantech/som-db5800-som-6867/Kconfig | 5 ++--- board/congatec/conga-qeval20-qa3-e3845/Kconfig | 5 ++--- board/dfi/dfi-bt700/Kconfig | 5 ++--- board/intel/minnowmax/Kconfig | 5 ++--- 6 files changed, 11 insertions(+), 18 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org

If UEFI BIOS has the graphics output protocol (GOP), let's pass its information to U-Boot payload so that U-Boot can utilize it (eg: an EFI framebuffer driver).
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
include/efi.h | 35 +++++++++++++++++++++++++++++++++++ lib/efi/efi_stub.c | 15 +++++++++++++++ 2 files changed, 50 insertions(+)
diff --git a/include/efi.h b/include/efi.h index 98bddba..e08a913 100644 --- a/include/efi.h +++ b/include/efi.h @@ -242,6 +242,7 @@ struct efi_open_protocol_info_entry { enum efi_entry_t { EFIET_END, /* Signals this is the last (empty) entry */ EFIET_MEMORY_MAP, + EFIET_GOP_MODE,
/* Number of entries */ EFIET_MEMORY_COUNT, @@ -298,6 +299,40 @@ struct efi_entry_memmap { struct efi_mem_desc desc[]; };
+/** + * struct efi_entry_gopmode - a GOP mode table passed to U-Boot + * + * @fb_base: EFI's framebuffer base address + * @fb_size: EFI's framebuffer size + * @info_size: GOP mode info structure size + * @info: Start address of the GOP mode info structure + */ +struct efi_entry_gopmode { + efi_physical_addr_t fb_base; + /* + * Not like the ones in 'struct efi_gop_mode' which are 'unsigned + * long', @fb_size and @info_size have to be 'u64' here. As the EFI + * stub codes may have different bit size from the U-Boot payload, + * using 'long' will cause mismatch between the producer (stub) and + * the consumer (payload). + */ + u64 fb_size; + u64 info_size; + /* + * We cannot directly use 'struct efi_gop_mode_info info[]' here as + * it causes compiler to complain: array type has incomplete element + * type 'struct efi_gop_mode_info'. + */ + struct /* efi_gop_mode_info */ { + u32 version; + u32 width; + u32 height; + u32 pixel_format; + u32 pixel_bitmask[4]; + u32 pixels_per_scanline; + } info[]; +}; + static inline struct efi_mem_desc *efi_get_next_mem_desc( struct efi_entry_memmap *map, struct efi_mem_desc *desc) { diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c index 09023a2..4819373 100644 --- a/lib/efi/efi_stub.c +++ b/lib/efi/efi_stub.c @@ -274,6 +274,9 @@ efi_status_t efi_main(efi_handle_t image, struct efi_system_table *sys_table) struct efi_boot_services *boot = sys_table->boottime; struct efi_mem_desc *desc; struct efi_entry_memmap map; + struct efi_gop *gop; + struct efi_entry_gopmode mode; + efi_guid_t efi_gop_guid = EFI_GOP_GUID; efi_uintn_t key, desc_size, size; efi_status_t ret; u32 version; @@ -312,6 +315,18 @@ efi_status_t efi_main(efi_handle_t image, struct efi_system_table *sys_table) if (ret) return ret;
+ ret = boot->locate_protocol(&efi_gop_guid, NULL, (void **)&gop); + if (ret) { + puts(" GOP unavailable\n"); + } else { + mode.fb_base = gop->mode->fb_base; + mode.fb_size = gop->mode->fb_size; + mode.info_size = gop->mode->info_size; + add_entry_addr(priv, EFIET_GOP_MODE, &mode, sizeof(mode), + gop->mode->info, + sizeof(struct efi_gop_mode_info)); + } + ret = boot->get_memory_map(&size, desc, &key, &desc_size, &version); if (ret) { printhex2(ret);

On 10.06.18 15:25, Bin Meng wrote:
If UEFI BIOS has the graphics output protocol (GOP), let's pass its information to U-Boot payload so that U-Boot can utilize it (eg: an EFI framebuffer driver).
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Why can't the FB drive determine all of this on its own and just fail probe if no GOP protocol can be found?
Alex

On Mon, Jun 11, 2018 at 3:16 AM, Alexander Graf agraf@suse.de wrote:
On 10.06.18 15:25, Bin Meng wrote:
If UEFI BIOS has the graphics output protocol (GOP), let's pass its information to U-Boot payload so that U-Boot can utilize it (eg: an EFI framebuffer driver).
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Why can't the FB drive determine all of this on its own and just fail probe if no GOP protocol can be found?
It cannot. Once U-Boot payload is running, the boot services are gone. There is no way to determine the GOP protocol.
Regards, Bin

On 11.06.18 01:29, Bin Meng wrote:
On Mon, Jun 11, 2018 at 3:16 AM, Alexander Graf agraf@suse.de wrote:
On 10.06.18 15:25, Bin Meng wrote:
If UEFI BIOS has the graphics output protocol (GOP), let's pass its information to U-Boot payload so that U-Boot can utilize it (eg: an EFI framebuffer driver).
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Why can't the FB drive determine all of this on its own and just fail probe if no GOP protocol can be found?
It cannot. Once U-Boot payload is running, the boot services are gone. There is no way to determine the GOP protocol.
Interesting. Is there a particular reason you're not preserving boot services?
It might be quite handy to reuse UEFI block interfaces for example. It might also be useful to preserve (parts of?) the memory map so we don't overwrite random SMM code for example.
Maybe I misunderstand the purpose of the UEFI U-Boot support though ;).
Alex

Hi Alex,
On Mon, Jun 11, 2018 at 1:52 PM, Alexander Graf agraf@suse.de wrote:
On 11.06.18 01:29, Bin Meng wrote:
On Mon, Jun 11, 2018 at 3:16 AM, Alexander Graf agraf@suse.de wrote:
On 10.06.18 15:25, Bin Meng wrote:
If UEFI BIOS has the graphics output protocol (GOP), let's pass its information to U-Boot payload so that U-Boot can utilize it (eg: an EFI framebuffer driver).
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Why can't the FB drive determine all of this on its own and just fail probe if no GOP protocol can be found?
It cannot. Once U-Boot payload is running, the boot services are gone. There is no way to determine the GOP protocol.
Interesting. Is there a particular reason you're not preserving boot services?
This is EFI payload support with CONFIG_EFI_STUB. Preserving boot services is EFI application, with CONFIG_EFI_APP. For example, see serial_efi.c which is the serial driver that uses EFI's boot services to output characters on the serial port.
It might be quite handy to reuse UEFI block interfaces for example. It might also be useful to preserve (parts of?) the memory map so we don't overwrite random SMM code for example.
Maybe I misunderstand the purpose of the UEFI U-Boot support though ;).
Looks there is some misunderstanding around the EFI payload support.
Regards, Bin

On 06/11/2018 08:01 AM, Bin Meng wrote:
Hi Alex,
On Mon, Jun 11, 2018 at 1:52 PM, Alexander Graf agraf@suse.de wrote:
On 11.06.18 01:29, Bin Meng wrote:
On Mon, Jun 11, 2018 at 3:16 AM, Alexander Graf agraf@suse.de wrote:
On 10.06.18 15:25, Bin Meng wrote:
If UEFI BIOS has the graphics output protocol (GOP), let's pass its information to U-Boot payload so that U-Boot can utilize it (eg: an EFI framebuffer driver).
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Why can't the FB drive determine all of this on its own and just fail probe if no GOP protocol can be found?
It cannot. Once U-Boot payload is running, the boot services are gone. There is no way to determine the GOP protocol.
Interesting. Is there a particular reason you're not preserving boot services?
This is EFI payload support with CONFIG_EFI_STUB. Preserving boot services is EFI application, with CONFIG_EFI_APP. For example, see serial_efi.c which is the serial driver that uses EFI's boot services to output characters on the serial port.
Oh, I see. That makes sense now.
Do people actually need CONFIG_EFI_STUB then?
It might be quite handy to reuse UEFI block interfaces for example. It might also be useful to preserve (parts of?) the memory map so we don't overwrite random SMM code for example.
Maybe I misunderstand the purpose of the UEFI U-Boot support though ;).
Looks there is some misunderstanding around the EFI payload support.
Yes, I have to admit that I never really cared enough about it to read its documentation though :).
Alex

Hi Alex,
On Mon, Jun 11, 2018 at 3:34 PM, Alexander Graf agraf@suse.de wrote:
On 06/11/2018 08:01 AM, Bin Meng wrote:
Hi Alex,
On Mon, Jun 11, 2018 at 1:52 PM, Alexander Graf agraf@suse.de wrote:
On 11.06.18 01:29, Bin Meng wrote:
On Mon, Jun 11, 2018 at 3:16 AM, Alexander Graf agraf@suse.de wrote:
On 10.06.18 15:25, Bin Meng wrote:
If UEFI BIOS has the graphics output protocol (GOP), let's pass its information to U-Boot payload so that U-Boot can utilize it (eg: an EFI framebuffer driver).
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Why can't the FB drive determine all of this on its own and just fail probe if no GOP protocol can be found?
It cannot. Once U-Boot payload is running, the boot services are gone. There is no way to determine the GOP protocol.
Interesting. Is there a particular reason you're not preserving boot services?
This is EFI payload support with CONFIG_EFI_STUB. Preserving boot services is EFI application, with CONFIG_EFI_APP. For example, see serial_efi.c which is the serial driver that uses EFI's boot services to output characters on the serial port.
Oh, I see. That makes sense now.
Do people actually need CONFIG_EFI_STUB then?
I think you wanted to say: Do people actually need CONFIG_EFI_APP then? CONFIG_EFI_STUB is more useful than CONFIG_EFI_APP. The application support is very limited.
As the README.u-boot_on_efi says:
Running U-Boot on EFI is useful in several situations:
- You have EFI running on a board but U-Boot does not natively support it fully yet. You can boot into U-Boot from EFI and use that until U-Boot is fully ported
- You need to use an EFI implementation (e.g. UEFI) because your vendor requires it in order to provide support
- You plan to use coreboot to boot into U-Boot but coreboot support does not currently exist for your platform. In the meantime you can use U-Boot on EFI and then move to U-Boot on coreboot when ready
- You use EFI but want to experiment with a simpler alternative like U-Boot
Right now, I have one Intel SkyLake board, and before I get a native U-Boot up and running as the 1st stage bootloader on this board, I can run U-Boot as the EFI payload to experiment something, which is very handy.
It might be quite handy to reuse UEFI block interfaces for example. It might also be useful to preserve (parts of?) the memory map so we don't overwrite random SMM code for example.
Maybe I misunderstand the purpose of the UEFI U-Boot support though ;).
Looks there is some misunderstanding around the EFI payload support.
Yes, I have to admit that I never really cared enough about it to read its documentation though :).
Yep, this sometimes confuses people :)
Regards, Bin

On 06/11/2018 09:44 AM, Bin Meng wrote:
Hi Alex,
On Mon, Jun 11, 2018 at 3:34 PM, Alexander Graf agraf@suse.de wrote:
On 06/11/2018 08:01 AM, Bin Meng wrote:
Hi Alex,
On Mon, Jun 11, 2018 at 1:52 PM, Alexander Graf agraf@suse.de wrote:
On 11.06.18 01:29, Bin Meng wrote:
On Mon, Jun 11, 2018 at 3:16 AM, Alexander Graf agraf@suse.de wrote:
On 10.06.18 15:25, Bin Meng wrote: > If UEFI BIOS has the graphics output protocol (GOP), let's pass its > information to U-Boot payload so that U-Boot can utilize it (eg: > an EFI framebuffer driver). > > Signed-off-by: Bin Meng bmeng.cn@gmail.com Why can't the FB drive determine all of this on its own and just fail probe if no GOP protocol can be found?
It cannot. Once U-Boot payload is running, the boot services are gone. There is no way to determine the GOP protocol.
Interesting. Is there a particular reason you're not preserving boot services?
This is EFI payload support with CONFIG_EFI_STUB. Preserving boot services is EFI application, with CONFIG_EFI_APP. For example, see serial_efi.c which is the serial driver that uses EFI's boot services to output characters on the serial port.
Oh, I see. That makes sense now.
Do people actually need CONFIG_EFI_STUB then?
I think you wanted to say: Do people actually need CONFIG_EFI_APP then? CONFIG_EFI_STUB is more useful than CONFIG_EFI_APP. The application support is very limited.
As the README.u-boot_on_efi says:
Running U-Boot on EFI is useful in several situations:
- You have EFI running on a board but U-Boot does not natively support it
fully yet. You can boot into U-Boot from EFI and use that until U-Boot is fully ported
- You need to use an EFI implementation (e.g. UEFI) because your vendor
requires it in order to provide support
- You plan to use coreboot to boot into U-Boot but coreboot support does
not currently exist for your platform. In the meantime you can use U-Boot on EFI and then move to U-Boot on coreboot when ready
- You use EFI but want to experiment with a simpler alternative like U-Boot
Right now, I have one Intel SkyLake board, and before I get a native U-Boot up and running as the 1st stage bootloader on this board, I can run U-Boot as the EFI payload to experiment something, which is very handy.
Oh, I see. So it's mostly used as bringup aid. In that case I agree that the stub bit makes a lot of sense.
The one thing that really bites us with the stub and different bitness is when you want to use efi_api.h again from within U-Boot. The obvious example is a 32bit U-Boot built as 64bit payload, allowing 32bit UEFI applications to run inside.
Do you think we could just agree on efi.h to not consume any stub config options and just determine things from its build environment instead? That way it automatically adapts according to the -m32/-m64 build flag for the stub and we would not need to worry about the stub in generic code.
Something like the patch below? If yes, I'll resend it with proper indentation :).
Alex
diff --git a/include/efi.h b/include/efi.h index 98bddbac1a..5e1e8ac78c 100644 --- a/include/efi.h +++ b/include/efi.h @@ -19,12 +19,12 @@ Â #include <linux/string.h> Â #include <linux/types.h>
-#if CONFIG_EFI_STUB_64BIT || (!defined(CONFIG_EFI_STUB) && defined(__x86_64__)) -/* EFI uses the Microsoft ABI which is not the default for GCC */ +/* EFI on x86_64 uses the Microsoft ABI which is not the default for GCC */ +#ifdef __x86_64__  #define EFIAPI __attribute__((ms_abi))  #else  #define EFIAPI asmlinkage -#endif +#endif /* __x86_64__ */
struct efi_device_path;
@@ -32,16 +32,7 @@ typedef struct { Â Â Â Â u8 b[16]; Â } efi_guid_t;
-#define EFI_BITS_PER_LONGÂ Â Â BITS_PER_LONG - -/* - * With 64-bit EFI stub, EFI_BITS_PER_LONG has to be 64. EFI_STUB is set - * in lib/efi/Makefile, when building the stub. - */ -#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB) -#undef EFI_BITS_PER_LONG -#define EFI_BITS_PER_LONGÂ Â Â 64 -#endif +#define EFI_BITS_PER_LONGÂ Â Â (sizeof(long) * 8)
/* Bit mask for EFI status code with error */ Â #define EFI_ERROR_MASK (1UL << (EFI_BITS_PER_LONG - 1))

Hi Alex,
On Mon, Jun 11, 2018 at 4:33 PM, Alexander Graf agraf@suse.de wrote:
On 06/11/2018 09:44 AM, Bin Meng wrote:
Hi Alex,
On Mon, Jun 11, 2018 at 3:34 PM, Alexander Graf agraf@suse.de wrote:
On 06/11/2018 08:01 AM, Bin Meng wrote:
Hi Alex,
On Mon, Jun 11, 2018 at 1:52 PM, Alexander Graf agraf@suse.de wrote:
On 11.06.18 01:29, Bin Meng wrote:
On Mon, Jun 11, 2018 at 3:16 AM, Alexander Graf agraf@suse.de wrote: > > > On 10.06.18 15:25, Bin Meng wrote: >> >> If UEFI BIOS has the graphics output protocol (GOP), let's pass its >> information to U-Boot payload so that U-Boot can utilize it (eg: >> an EFI framebuffer driver). >> >> Signed-off-by: Bin Meng bmeng.cn@gmail.com > > Why can't the FB drive determine all of this on its own and just fail > probe if no GOP protocol can be found? > It cannot. Once U-Boot payload is running, the boot services are gone. There is no way to determine the GOP protocol.
Interesting. Is there a particular reason you're not preserving boot services?
This is EFI payload support with CONFIG_EFI_STUB. Preserving boot services is EFI application, with CONFIG_EFI_APP. For example, see serial_efi.c which is the serial driver that uses EFI's boot services to output characters on the serial port.
Oh, I see. That makes sense now.
Do people actually need CONFIG_EFI_STUB then?
I think you wanted to say: Do people actually need CONFIG_EFI_APP then? CONFIG_EFI_STUB is more useful than CONFIG_EFI_APP. The application support is very limited.
As the README.u-boot_on_efi says:
Running U-Boot on EFI is useful in several situations:
- You have EFI running on a board but U-Boot does not natively support it
fully yet. You can boot into U-Boot from EFI and use that until U-Boot is fully ported
- You need to use an EFI implementation (e.g. UEFI) because your vendor
requires it in order to provide support
- You plan to use coreboot to boot into U-Boot but coreboot support does
not currently exist for your platform. In the meantime you can use U-Boot on EFI and then move to U-Boot on coreboot when ready
- You use EFI but want to experiment with a simpler alternative like
U-Boot
Right now, I have one Intel SkyLake board, and before I get a native U-Boot up and running as the 1st stage bootloader on this board, I can run U-Boot as the EFI payload to experiment something, which is very handy.
Oh, I see. So it's mostly used as bringup aid. In that case I agree that the stub bit makes a lot of sense.
The one thing that really bites us with the stub and different bitness is when you want to use efi_api.h again from within U-Boot. The obvious example is a 32bit U-Boot built as 64bit payload, allowing 32bit UEFI applications to run inside.
Do you think we could just agree on efi.h to not consume any stub config options and just determine things from its build environment instead? That way it automatically adapts according to the -m32/-m64 build flag for the stub and we would not need to worry about the stub in generic code.
Great, this way is smarter!
Something like the patch below? If yes, I'll resend it with proper indentation :).
Yes, and I belive we will also need remove -DEFI_STUB in lib/efi/Makefile.
diff --git a/include/efi.h b/include/efi.h index 98bddbac1a..5e1e8ac78c 100644 --- a/include/efi.h +++ b/include/efi.h @@ -19,12 +19,12 @@ #include <linux/string.h> #include <linux/types.h>
-#if CONFIG_EFI_STUB_64BIT || (!defined(CONFIG_EFI_STUB) && defined(__x86_64__)) -/* EFI uses the Microsoft ABI which is not the default for GCC */ +/* EFI on x86_64 uses the Microsoft ABI which is not the default for GCC */ +#ifdef __x86_64__ #define EFIAPI __attribute__((ms_abi)) #else #define EFIAPI asmlinkage -#endif +#endif /* __x86_64__ */
struct efi_device_path;
@@ -32,16 +32,7 @@ typedef struct { u8 b[16]; } efi_guid_t;
-#define EFI_BITS_PER_LONG BITS_PER_LONG
-/*
- With 64-bit EFI stub, EFI_BITS_PER_LONG has to be 64. EFI_STUB is set
- in lib/efi/Makefile, when building the stub.
- */
-#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB) -#undef EFI_BITS_PER_LONG -#define EFI_BITS_PER_LONG 64 -#endif +#define EFI_BITS_PER_LONG (sizeof(long) * 8)
/* Bit mask for EFI status code with error */ #define EFI_ERROR_MASK (1UL << (EFI_BITS_PER_LONG - 1))
Regards, Bin

Hi,
On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
If UEFI BIOS has the graphics output protocol (GOP), let's pass its information to U-Boot payload so that U-Boot can utilize it (eg: an EFI framebuffer driver).
Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/efi.h | 35 +++++++++++++++++++++++++++++++++++ lib/efi/efi_stub.c | 15 +++++++++++++++ 2 files changed, 50 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org
Note (for Alex) that the stub can use boot services but the payload (U-Boot itself) cannot.
It is a different mode from U-Boot as an EFI application.
- Simon

This adds a DM video driver for U-Boot as the EFI payload. The driver makes use of all necessary information from the passed EFI GOP info to create a linear framebuffer device, as if it were initialized by U-Boot itself.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/video/Kconfig | 9 +++ drivers/video/Makefile | 1 + drivers/video/efi.c | 146 +++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 156 insertions(+) create mode 100644 drivers/video/efi.c
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 4c4d286..5ee9032 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -156,6 +156,15 @@ config VIDEO_COREBOOT coreboot already. This can in principle be used with any platform that coreboot supports.
+config VIDEO_EFI + bool "Enable EFI framebuffer driver support" + depends on EFI_STUB + help + Turn on this option to enable a framebuffeer driver when U-Boot is + loaded as a payload (see README.u-boot_on_efi) by an EFI BIOS where + the graphics device is configured by the EFI BIOS already. This can + in principle be used with any platform that has an EFI BIOS. + config VIDEO_VESA bool "Enable VESA video driver support" default n diff --git a/drivers/video/Makefile b/drivers/video/Makefile index cf7ad28..7c89c67 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -32,6 +32,7 @@ obj-$(CONFIG_LD9040) += ld9040.o obj-$(CONFIG_VIDEO_BCM2835) += bcm2835.o obj-$(CONFIG_VIDEO_COREBOOT) += coreboot.o obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o +obj-$(CONFIG_VIDEO_EFI) += efi.o obj-$(CONFIG_VIDEO_LCD_ANX9804) += anx9804.o obj-$(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM) += hitachi_tx18d42vm_lcd.o obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o diff --git a/drivers/video/efi.c b/drivers/video/efi.c new file mode 100644 index 0000000..653cb47 --- /dev/null +++ b/drivers/video/efi.c @@ -0,0 +1,146 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018, Bin Meng bmeng.cn@gmail.com + * + * EFI framebuffer driver based on GOP + */ + +#include <common.h> +#include <dm.h> +#include <efi_api.h> +#include <vbe.h> +#include <video.h> + +struct pixel { + u8 pos; + u8 size; +}; + +static const struct efi_framebuffer { + struct pixel red; + struct pixel green; + struct pixel blue; + struct pixel rsvd; +} efi_framebuffer_format_map[] = { + [EFI_GOT_RGBA8] = { {0, 8}, {8, 8}, {16, 8}, {24, 8} }, + [EFI_GOT_BGRA8] = { {16, 8}, {8, 8}, {0, 8}, {24, 8} }, +}; + +static void efi_find_pixel_bits(u32 mask, u8 *pos, u8 *size) +{ + u8 first, len; + + first = 0; + len = 0; + + if (mask) { + while (!(mask & 0x1)) { + mask = mask >> 1; + first++; + } + + while (mask & 0x1) { + mask = mask >> 1; + len++; + } + } + + *pos = first; + *size = len; +} + +static int save_vesa_mode(struct vesa_mode_info *vesa) +{ + struct efi_entry_gopmode *mode; + const struct efi_framebuffer *fbinfo; + int size; + int ret; + + ret = efi_info_get(EFIET_GOP_MODE, (void **)&mode, &size); + if (ret == -ENOENT) { + debug("efi graphics output protocol mode not found\n"); + return -ENXIO; + } + + vesa->phys_base_ptr = mode->fb_base; + vesa->x_resolution = mode->info->width; + vesa->y_resolution = mode->info->height; + + if (mode->info->pixel_format < EFI_GOT_BITMASK) { + fbinfo = &efi_framebuffer_format_map[mode->info->pixel_format]; + vesa->red_mask_size = fbinfo->red.size; + vesa->red_mask_pos = fbinfo->red.pos; + vesa->green_mask_size = fbinfo->green.size; + vesa->green_mask_pos = fbinfo->green.pos; + vesa->blue_mask_size = fbinfo->blue.size; + vesa->blue_mask_pos = fbinfo->blue.pos; + vesa->reserved_mask_size = fbinfo->rsvd.size; + vesa->reserved_mask_pos = fbinfo->rsvd.pos; + + vesa->bits_per_pixel = 32; + vesa->bytes_per_scanline = mode->info->pixels_per_scanline * 4; + } else if (mode->info->pixel_format == EFI_GOT_BITMASK) { + efi_find_pixel_bits(mode->info->pixel_bitmask[0], + &vesa->red_mask_pos, + &vesa->red_mask_size); + efi_find_pixel_bits(mode->info->pixel_bitmask[1], + &vesa->green_mask_pos, + &vesa->green_mask_size); + efi_find_pixel_bits(mode->info->pixel_bitmask[2], + &vesa->blue_mask_pos, + &vesa->blue_mask_size); + efi_find_pixel_bits(mode->info->pixel_bitmask[3], + &vesa->reserved_mask_pos, + &vesa->reserved_mask_size); + vesa->bits_per_pixel = vesa->red_mask_size + + vesa->green_mask_size + + vesa->blue_mask_size + + vesa->reserved_mask_size; + vesa->bytes_per_scanline = (mode->info->pixels_per_scanline * + vesa->bits_per_pixel) / 8; + } else { + debug("efi set unknown framebuffer format: %d\n", + mode->info->pixel_format); + return -EINVAL; + } + + return 0; +} + +static int efi_video_probe(struct udevice *dev) +{ + struct video_uc_platdata *plat = dev_get_uclass_platdata(dev); + struct video_priv *uc_priv = dev_get_uclass_priv(dev); + struct vesa_mode_info *vesa = &mode_info.vesa; + int ret; + + /* Initialize vesa_mode_info structure */ + ret = save_vesa_mode(vesa); + if (ret) + goto err; + + ret = vbe_setup_video_priv(vesa, uc_priv, plat); + if (ret) + goto err; + + printf("Video: %dx%dx%d\n", uc_priv->xsize, uc_priv->ysize, + vesa->bits_per_pixel); + + return 0; + +err: + printf("No video mode configured in EFI!\n"); + return ret; +} + +static const struct udevice_id efi_video_ids[] = { + { .compatible = "efi-fb" }, + { } +}; + +U_BOOT_DRIVER(efi_video) = { + .name = "efi_video", + .id = UCLASS_VIDEO, + .of_match = efi_video_ids, + .probe = efi_video_probe, +};

Hi Bin,
On Sun, 10 Jun 2018 06:25:14 -0700 Bin Meng bmeng.cn@gmail.com wrote:
This adds a DM video driver for U-Boot as the EFI payload. The driver makes use of all necessary information from the passed EFI GOP info to create a linear framebuffer device, as if it were initialized by U-Boot itself.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Reviewed-by: Anatolij Gustschin agust@denx.de
-- Anatolij

This turns on the EFI framebuffer driver support so that a graphics console can be of additional help.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/dts/efi-x86_payload.dts | 4 ++++ board/efi/efi-x86_payload/Kconfig | 1 + 2 files changed, 5 insertions(+)
diff --git a/arch/x86/dts/efi-x86_payload.dts b/arch/x86/dts/efi-x86_payload.dts index 137bde5..148b587 100644 --- a/arch/x86/dts/efi-x86_payload.dts +++ b/arch/x86/dts/efi-x86_payload.dts @@ -33,4 +33,8 @@ compatible = "pci-x86"; u-boot,dm-pre-reloc; }; + + efi-fb { + compatible = "efi-fb"; + }; }; diff --git a/board/efi/efi-x86_payload/Kconfig b/board/efi/efi-x86_payload/Kconfig index dcf4de8..b6e57b9 100644 --- a/board/efi/efi-x86_payload/Kconfig +++ b/board/efi/efi-x86_payload/Kconfig @@ -30,6 +30,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply USB_XHCI_HCD imply USB_STORAGE imply USB_KEYBOARD + imply VIDEO_EFI imply E1000 imply ETH_DESIGNWARE imply PCH_GBE

On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
This turns on the EFI framebuffer driver support so that a graphics console can be of additional help.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/dts/efi-x86_payload.dts | 4 ++++ board/efi/efi-x86_payload/Kconfig | 1 + 2 files changed, 5 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org

To avoid confusion, let's rename the efi-x86 target to efi-x86_app.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/efi/Makefile | 2 +- arch/x86/cpu/efi/{efi.c => app.c} | 0 arch/x86/cpu/intel_common/Makefile | 2 +- arch/x86/dts/Makefile | 2 +- arch/x86/dts/{efi.dts => efi-x86_app.dts} | 4 ++-- board/efi/Kconfig | 6 +++--- board/efi/{efi-x86 => efi-x86_app}/Kconfig | 6 +++--- board/efi/{efi-x86 => efi-x86_app}/MAINTAINERS | 0 board/efi/{efi-x86 => efi-x86_app}/Makefile | 2 +- board/efi/{efi-x86/efi.c => efi-x86_app/app.c} | 0 configs/{efi-x86_defconfig => efi-x86_app_defconfig} | 4 ++-- include/configs/{efi-x86.h => efi-x86_app.h} | 0 12 files changed, 14 insertions(+), 14 deletions(-) rename arch/x86/cpu/efi/{efi.c => app.c} (100%) rename arch/x86/dts/{efi.dts => efi-x86_app.dts} (82%) rename board/efi/{efi-x86 => efi-x86_app}/Kconfig (64%) rename board/efi/{efi-x86 => efi-x86_app}/MAINTAINERS (100%) rename board/efi/{efi-x86 => efi-x86_app}/Makefile (82%) rename board/efi/{efi-x86/efi.c => efi-x86_app/app.c} (100%) rename configs/{efi-x86_defconfig => efi-x86_app_defconfig} (92%) rename include/configs/{efi-x86.h => efi-x86_app.h} (100%)
diff --git a/arch/x86/cpu/efi/Makefile b/arch/x86/cpu/efi/Makefile index 32c2dde..9716a4e 100644 --- a/arch/x86/cpu/efi/Makefile +++ b/arch/x86/cpu/efi/Makefile @@ -3,7 +3,7 @@ # Copyright (c) 2015 Google, Inc
ifdef CONFIG_EFI_APP -obj-y += efi.o +obj-y += app.o obj-y += sdram.o endif
diff --git a/arch/x86/cpu/efi/efi.c b/arch/x86/cpu/efi/app.c similarity index 100% rename from arch/x86/cpu/efi/efi.c rename to arch/x86/cpu/efi/app.c diff --git a/arch/x86/cpu/intel_common/Makefile b/arch/x86/cpu/intel_common/Makefile index c0fcf0c..bf798c2 100644 --- a/arch/x86/cpu/intel_common/Makefile +++ b/arch/x86/cpu/intel_common/Makefile @@ -10,7 +10,7 @@ obj-$(CONFIG_$(SPL_)X86_32BIT_INIT) += mrc.o endif obj-y += cpu.o obj-y += lpc.o -ifndef CONFIG_TARGET_EFI +ifndef CONFIG_TARGET_EFI_APP obj-y += microcode.o endif obj-y += pch.o diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile index 9872c04..37e4fdc 100644 --- a/arch/x86/dts/Makefile +++ b/arch/x86/dts/Makefile @@ -10,7 +10,7 @@ dtb-y += bayleybay.dtb \ crownbay.dtb \ dfi-bt700-q7x-151.dtb \ edison.dtb \ - efi.dtb \ + efi-x86_app.dtb \ efi-x86_payload.dtb \ galileo.dtb \ minnowmax.dtb \ diff --git a/arch/x86/dts/efi.dts b/arch/x86/dts/efi-x86_app.dts similarity index 82% rename from arch/x86/dts/efi.dts rename to arch/x86/dts/efi-x86_app.dts index 62ae96a..e70e351 100644 --- a/arch/x86/dts/efi.dts +++ b/arch/x86/dts/efi-x86_app.dts @@ -9,8 +9,8 @@ /include/ "tsc_timer.dtsi"
/ { - model = "EFI"; - compatible = "efi,app"; + model = "EFI x86 Application"; + compatible = "efi,x86-app";
chosen { stdout-path = &serial; diff --git a/board/efi/Kconfig b/board/efi/Kconfig index d37f6ff..291bd2c 100644 --- a/board/efi/Kconfig +++ b/board/efi/Kconfig @@ -4,8 +4,8 @@ choice prompt "Mainboard model" optional
-config TARGET_EFI - bool "efi" +config TARGET_EFI_APP + bool "efi application" help This target is used for running U-Boot on top of EFI. In this case EFI does the early initialisation, and U-Boot @@ -22,7 +22,7 @@ config TARGET_EFI_PAYLOAD
endchoice
-source "board/efi/efi-x86/Kconfig" +source "board/efi/efi-x86_app/Kconfig" source "board/efi/efi-x86_payload/Kconfig"
endif diff --git a/board/efi/efi-x86/Kconfig b/board/efi/efi-x86_app/Kconfig similarity index 64% rename from board/efi/efi-x86/Kconfig rename to board/efi/efi-x86_app/Kconfig index fa609ba..ae87bf3 100644 --- a/board/efi/efi-x86/Kconfig +++ b/board/efi/efi-x86_app/Kconfig @@ -1,7 +1,7 @@ -if TARGET_EFI +if TARGET_EFI_APP
config SYS_BOARD - default "efi-x86" + default "efi-x86_app"
config SYS_VENDOR default "efi" @@ -10,6 +10,6 @@ config SYS_SOC default "efi"
config SYS_CONFIG_NAME - default "efi-x86" + default "efi-x86_app"
endif diff --git a/board/efi/efi-x86/MAINTAINERS b/board/efi/efi-x86_app/MAINTAINERS similarity index 100% rename from board/efi/efi-x86/MAINTAINERS rename to board/efi/efi-x86_app/MAINTAINERS diff --git a/board/efi/efi-x86/Makefile b/board/efi/efi-x86_app/Makefile similarity index 82% rename from board/efi/efi-x86/Makefile rename to board/efi/efi-x86_app/Makefile index 2097283..cb48d1c 100644 --- a/board/efi/efi-x86/Makefile +++ b/board/efi/efi-x86_app/Makefile @@ -2,4 +2,4 @@ # # Copyright (c) 2015 Google, Inc
-obj-y += efi.o +obj-y += app.o diff --git a/board/efi/efi-x86/efi.c b/board/efi/efi-x86_app/app.c similarity index 100% rename from board/efi/efi-x86/efi.c rename to board/efi/efi-x86_app/app.c diff --git a/configs/efi-x86_defconfig b/configs/efi-x86_app_defconfig similarity index 92% rename from configs/efi-x86_defconfig rename to configs/efi-x86_app_defconfig index 741a169..4088dae 100644 --- a/configs/efi-x86_defconfig +++ b/configs/efi-x86_app_defconfig @@ -1,7 +1,7 @@ CONFIG_X86=y CONFIG_VENDOR_EFI=y -CONFIG_DEFAULT_DEVICE_TREE="efi" -CONFIG_TARGET_EFI=y +CONFIG_DEFAULT_DEVICE_TREE="efi-x86_app" +CONFIG_TARGET_EFI_APP=y CONFIG_DEBUG_UART=y CONFIG_FIT=y CONFIG_USE_BOOTARGS=y diff --git a/include/configs/efi-x86.h b/include/configs/efi-x86_app.h similarity index 100% rename from include/configs/efi-x86.h rename to include/configs/efi-x86_app.h

On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
To avoid confusion, let's rename the efi-x86 target to efi-x86_app.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/efi/Makefile | 2 +- arch/x86/cpu/efi/{efi.c => app.c} | 0 arch/x86/cpu/intel_common/Makefile | 2 +- arch/x86/dts/Makefile | 2 +- arch/x86/dts/{efi.dts => efi-x86_app.dts} | 4 ++-- board/efi/Kconfig | 6 +++--- board/efi/{efi-x86 => efi-x86_app}/Kconfig | 6 +++--- board/efi/{efi-x86 => efi-x86_app}/MAINTAINERS | 0 board/efi/{efi-x86 => efi-x86_app}/Makefile | 2 +- board/efi/{efi-x86/efi.c => efi-x86_app/app.c} | 0 configs/{efi-x86_defconfig => efi-x86_app_defconfig} | 4 ++-- include/configs/{efi-x86.h => efi-x86_app.h} | 0 12 files changed, 14 insertions(+), 14 deletions(-) rename arch/x86/cpu/efi/{efi.c => app.c} (100%) rename arch/x86/dts/{efi.dts => efi-x86_app.dts} (82%) rename board/efi/{efi-x86 => efi-x86_app}/Kconfig (64%) rename board/efi/{efi-x86 => efi-x86_app}/MAINTAINERS (100%) rename board/efi/{efi-x86 => efi-x86_app}/Makefile (82%) rename board/efi/{efi-x86/efi.c => efi-x86_app/app.c} (100%) rename configs/{efi-x86_defconfig => efi-x86_app_defconfig} (92%) rename include/configs/{efi-x86.h => efi-x86_app.h} (100%)
Reviewed-by: Simon Glass sjg@chromium.org
Is a docs update needed too?

Hi Simon,
On Mon, Jun 11, 2018 at 10:54 PM, Simon Glass sjg@chromium.org wrote:
On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
To avoid confusion, let's rename the efi-x86 target to efi-x86_app.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/efi/Makefile | 2 +- arch/x86/cpu/efi/{efi.c => app.c} | 0 arch/x86/cpu/intel_common/Makefile | 2 +- arch/x86/dts/Makefile | 2 +- arch/x86/dts/{efi.dts => efi-x86_app.dts} | 4 ++-- board/efi/Kconfig | 6 +++--- board/efi/{efi-x86 => efi-x86_app}/Kconfig | 6 +++--- board/efi/{efi-x86 => efi-x86_app}/MAINTAINERS | 0 board/efi/{efi-x86 => efi-x86_app}/Makefile | 2 +- board/efi/{efi-x86/efi.c => efi-x86_app/app.c} | 0 configs/{efi-x86_defconfig => efi-x86_app_defconfig} | 4 ++-- include/configs/{efi-x86.h => efi-x86_app.h} | 0 12 files changed, 14 insertions(+), 14 deletions(-) rename arch/x86/cpu/efi/{efi.c => app.c} (100%) rename arch/x86/dts/{efi.dts => efi-x86_app.dts} (82%) rename board/efi/{efi-x86 => efi-x86_app}/Kconfig (64%) rename board/efi/{efi-x86 => efi-x86_app}/MAINTAINERS (100%) rename board/efi/{efi-x86 => efi-x86_app}/Makefile (82%) rename board/efi/{efi-x86/efi.c => efi-x86_app/app.c} (100%) rename configs/{efi-x86_defconfig => efi-x86_app_defconfig} (92%) rename include/configs/{efi-x86.h => efi-x86_app.h} (100%)
Reviewed-by: Simon Glass sjg@chromium.org
Is a docs update needed too?
Yes, will send v2 to include doc update.
Regards, Bin

Currently when EFI application boots, it says:
CPU: x86_64, vendor <invalid cpu vendor>, device 0h
Fix this by calling x86_cpu_init_f() in arch_cpu_init().
Signed-off-by: Bin Meng bmeng.cn@gmail.com
---
arch/x86/cpu/efi/app.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/cpu/efi/app.c b/arch/x86/cpu/efi/app.c index cda4fab..ba7c02b 100644 --- a/arch/x86/cpu/efi/app.c +++ b/arch/x86/cpu/efi/app.c @@ -9,7 +9,7 @@
int arch_cpu_init(void) { - return 0; + return x86_cpu_init_f(); }
int checkcpu(void)

On 10 June 2018 at 05:25, Bin Meng bmeng.cn@gmail.com wrote:
Currently when EFI application boots, it says:
CPU: x86_64, vendor <invalid cpu vendor>, device 0h
Fix this by calling x86_cpu_init_f() in arch_cpu_init().
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/efi/app.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Simon Glass sjg@chromium.org

Hi Bin,
On 10 June 2018 at 05:24, Bin Meng bmeng.cn@gmail.com wrote:
Unfortunately the EFI x86 application and payload support have been broken for quite a while. This series addresses various bug fixes, plus several enhancements like toolchain compatibility (eg: kernel.org i386-linux-gcc), introduction of generic EFI payload which can run on any x86 board, and a EFI framebuffer driver for the payload.
This series is available at u-boot-x86/efi-working for testing.
I wonder if it is possible to put qemu testing of the EFI stuff into travis?
Also, are the problems only with the i386 compiler, or are things truly broken everywhere?
Regards, Simon

Hi Simon,
On Mon, Jun 11, 2018 at 10:53 PM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 10 June 2018 at 05:24, Bin Meng bmeng.cn@gmail.com wrote:
Unfortunately the EFI x86 application and payload support have been broken for quite a while. This series addresses various bug fixes, plus several enhancements like toolchain compatibility (eg: kernel.org i386-linux-gcc), introduction of generic EFI payload which can run on any x86 board, and a EFI framebuffer driver for the payload.
This series is available at u-boot-x86/efi-working for testing.
I wonder if it is possible to put qemu testing of the EFI stuff into travis?
I will take a look.
Also, are the problems only with the i386 compiler, or are things truly broken everywhere?
Current mainline status of the EFI stuff is:
1. EFI application does not boot 2. EFI 32-bit payload boots fine 3. EFI 64-bit payload does not boot 4. i386-linux-gcc compiler does not build EFI 64-bit payload, but can build 32-bit payload and application 5. x86_64-linux-gcc compiler can build everything
Regards, Bin

Hi Bin,
On 11 June 2018 at 09:53, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Jun 11, 2018 at 10:53 PM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 10 June 2018 at 05:24, Bin Meng bmeng.cn@gmail.com wrote:
Unfortunately the EFI x86 application and payload support have been broken for quite a while. This series addresses various bug fixes, plus several enhancements like toolchain compatibility (eg: kernel.org i386-linux-gcc), introduction of generic EFI payload which can run on any x86 board, and a EFI framebuffer driver for the payload.
This series is available at u-boot-x86/efi-working for testing.
I wonder if it is possible to put qemu testing of the EFI stuff into travis?
I will take a look.
Also, are the problems only with the i386 compiler, or are things truly broken everywhere?
Current mainline status of the EFI stuff is:
- EFI application does not boot
- EFI 32-bit payload boots fine
- EFI 64-bit payload does not boot
- i386-linux-gcc compiler does not build EFI 64-bit payload, but can
build 32-bit payload and application 5. x86_64-linux-gcc compiler can build everything
OK great, thank you.
Re (1) it seems a bit tricky since as you say it is a shared library. I suppose we could get a list of unresolved symbols and check them against a whitelist. Or statically link the efi app just for testing purposes.
Regards, Simon
participants (5)
-
Alexander Graf
-
Anatolij Gustschin
-
Bin Meng
-
Heinrich Schuchardt
-
Simon Glass