[U-Boot] [PATCH v2 00/13] 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.
Changes in v2: - update the x86 doc to reference also README.uefi - new patch to "change __kernel_size_t conditionals to use compiler provided defines" - update README.u-boot_on_efi to reflect directory changes - update README.u-boot_on_efi to mention generic EFI payload support - update QEMU MAINTAINERS file to remove defconfig files - update README.u-boot_on_efi to use efi-x86_app - drop patches that were already applied to u-boot-x86
Alexander Graf (1): efi.h: Do not use config options
Bin Meng (12): x86: doc: Fix reference to EFI doc in U-Boot x86: Change __kernel_size_t conditionals to use compiler provided defines x86: efi: Refactor the directory of EFI app and payload support x86: efi: payload: Add arch_cpu_init() 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
arch/x86/Kconfig | 3 +- arch/x86/cpu/Makefile | 2 +- arch/x86/cpu/baytrail/Kconfig | 6 +- 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/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/include/asm/posix_types.h | 2 +- arch/x86/lib/Makefile | 1 - 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/emulation/qemu-x86/MAINTAINERS | 2 - board/intel/minnowmax/Kconfig | 5 +- .../{efi-x86_defconfig => efi-x86_app_defconfig} | 4 +- ...oad32_defconfig => efi-x86_payload32_defconfig} | 24 +--- ...oad64_defconfig => efi-x86_payload64_defconfig} | 24 +--- doc/README.u-boot_on_efi | 33 ++--- doc/README.x86 | 14 +- 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 | 52 ++++++-- lib/efi/Makefile | 4 +- lib/efi/efi_stub.c | 15 +++ 46 files changed, 433 insertions(+), 136 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} (92%) 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.
This updates the x86 doc to reference both README.u-boot_on_efi and README.uefi.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
Changes in v2: - update the x86 doc to reference also README.uefi
doc/README.x86 | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/README.x86 b/doc/README.x86 index 78664c3..9f657df 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -1134,18 +1134,18 @@ the "Power" submenu from the Windows start menu. EFI Support ----------- U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI. -This is enabled with CONFIG_EFI_STUB. U-Boot can also run as an EFI -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. +This is enabled with CONFIG_EFI_STUB to boot from both 32-bit and 64-bit +UEFI BIOS. U-Boot can also run as an EFI 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 and README.uefi for details of EFI support in U-Boot.
64-bit Support -------------- U-Boot supports booting a 64-bit kernel directly and is able to change to -64-bit mode to do so. It also supports (with CONFIG_EFI_STUB) booting from -both 32-bit and 64-bit UEFI. However, U-Boot itself is currently always built +64-bit mode to do so. However, U-Boot itself is currently always built in 32-bit mode. Some access to the full memory range is provided with arch_phys_memset().

On 06/12/2018 05:36 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.
This updates the x86 doc to reference both README.u-boot_on_efi and README.uefi.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Changes in v2:
- update the x86 doc to reference also README.uefi
doc/README.x86 | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/README.x86 b/doc/README.x86 index 78664c3..9f657df 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -1134,18 +1134,18 @@ the "Power" submenu from the Windows start menu. EFI Support
U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI. -This is enabled with CONFIG_EFI_STUB. U-Boot can also run as an EFI -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. +This is enabled with CONFIG_EFI_STUB to boot from both 32-bit and 64-bit +UEFI BIOS. U-Boot can also run as an EFI 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.
Do you mean "is not currently supported on x86 in conjunction with EFI_STUB" or do you mean "still has bugs on x86"?
On qemu-x86_defconfig I can start EFI applications like the helloworld.efi and ipxe. It is only the Linux kernel that has a problem with memory setup. That is of cause a bug that needs further attention.
Best regards
Heinrich
-See README.efi for details of EFI support in U-Boot. +See README.u-boot_on_efi and README.uefi for details of EFI support in U-Boot.
64-bit Support
U-Boot supports booting a 64-bit kernel directly and is able to change to -64-bit mode to do so. It also supports (with CONFIG_EFI_STUB) booting from -both 32-bit and 64-bit UEFI. However, U-Boot itself is currently always built +64-bit mode to do so. However, U-Boot itself is currently always built in 32-bit mode. Some access to the full memory range is provided with arch_phys_memset().

Hi Heinrich,
On Wed, Jun 13, 2018 at 12:04 AM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/12/2018 05:36 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.
This updates the x86 doc to reference both README.u-boot_on_efi and README.uefi.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Changes in v2:
- update the x86 doc to reference also README.uefi
doc/README.x86 | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/README.x86 b/doc/README.x86 index 78664c3..9f657df 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -1134,18 +1134,18 @@ the "Power" submenu from the Windows start menu. EFI Support
U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI. -This is enabled with CONFIG_EFI_STUB. U-Boot can also run as an EFI -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. +This is enabled with CONFIG_EFI_STUB to boot from both 32-bit and 64-bit +UEFI BIOS. U-Boot can also run as an EFI 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.
Do you mean "is not currently supported on x86 in conjunction with EFI_STUB" or do you mean "still has bugs on x86"?
On qemu-x86_defconfig I can start EFI applications like the helloworld.efi and ipxe. It is only the Linux kernel that has a problem with memory setup. That is of cause a bug that needs further attention.
I did not touch this when I updated the doc. I believe the doc means CONFIG_EFI_LOADER is not currently supported. As you mentioned, there are still some issues to work out. Maybe after you address all the remaining issues, we can update the doc for its support :)
Regards, Bin

Hi Heinrich,
On Wed, Jun 13, 2018 at 7:06 AM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Heinrich,
On Wed, Jun 13, 2018 at 12:04 AM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/12/2018 05:36 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.
This updates the x86 doc to reference both README.u-boot_on_efi and README.uefi.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Changes in v2:
- update the x86 doc to reference also README.uefi
doc/README.x86 | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/README.x86 b/doc/README.x86 index 78664c3..9f657df 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -1134,18 +1134,18 @@ the "Power" submenu from the Windows start menu. EFI Support
U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI. -This is enabled with CONFIG_EFI_STUB. U-Boot can also run as an EFI -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. +This is enabled with CONFIG_EFI_STUB to boot from both 32-bit and 64-bit +UEFI BIOS. U-Boot can also run as an EFI 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.
Do you mean "is not currently supported on x86 in conjunction with EFI_STUB" or do you mean "still has bugs on x86"?
On qemu-x86_defconfig I can start EFI applications like the helloworld.efi and ipxe. It is only the Linux kernel that has a problem with memory setup. That is of cause a bug that needs further attention.
I did not touch this when I updated the doc. I believe the doc means CONFIG_EFI_LOADER is not currently supported. As you mentioned, there are still some issues to work out. Maybe after you address all the remaining issues, we can update the doc for its support :)
I tested CONFIG_EFI_LOADER today, with U-Boot loads EFI application and EFI payload, on 32-bit QEMU. Here is the log:
=> load ide 0 1000000 u-boot-app.efi 683843 bytes read in 105 ms (6.2 MiB/s) => bootefi 1000000 Scanning disk ide.blk#0... Found 2 disks WARNING: booting without device tree ## Starting EFI application at 01000000 ... U-Boot EFI App starting
U-Boot 2018.07-rc1-00097-gc5eea16 (Jun 12 2018 - 23:02:03 +0800)
CPU: x86_64, vendor AMD, device 663h DRAM: 32 MiB Model: EFI x86 Application Hit any key to stop autoboot: 0 => => reset resetting ... U-Boot EFI exiting ## Application terminated, r = 0 => => => load ide 0 1000000 u-boot-payload.efi 486203 bytes read in 94 ms (4.9 MiB/s) => bootefi 1000000 WARNING: booting without device tree ## Starting EFI application at 01000000 ... U-Boot EFI Payload
U-Boot 2018.07-rc1-00097-gc5eea16 (Jun 12 2018 - 23:01:24 +0800)
CPU: x86_64, vendor AMD, device 663h DRAM: 108.2 MiB MMC: Video: 1024x768x32 Model: EFI x86 Payload Net: No ethernet found. IDE: Bus 0: OK Bus 1: OK Device 0: Model: QEMU HARDDISK Firm: 2.5+ Ser#: QM00001 Type: Hard Disk Supports 48-bit addressing Capacity: 504.0 MB = 0.4 GB (1032192 x 512) Device 1: not available Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM Type: Removable CD ROM Capacity: not available Device 3: not available Hit any key to stop autoboot: 0 => =>
I can update the documentation to change CONFIG_EFI_LOADER support status, but that is a separate patch.
Regards, Bin

On Tue, Jun 12, 2018 at 11:36 PM, Bin Meng bmeng.cn@gmail.com 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.
This updates the x86 doc to reference both README.u-boot_on_efi and README.uefi.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Changes in v2:
- update the x86 doc to reference also README.uefi
doc/README.x86 | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
applied to u-boot-x86, thanks!

From: Alexander Graf agraf@suse.de
Currently efi.h determines a few bits of its environment according to config options. This falls apart with the efi stub support which may result in efi.h getting pulled into the stub as well as real U-Boot code. In that case, one may be 32bit while the other one is 64bit.
This patch changes the conditionals to use compiler provided defines instead. That way we always adhere to the build environment we're in and the definitions adjust automatically.
Signed-off-by: Alexander Graf agraf@suse.de Reviewed-by: Bin Meng bmeng.cn@gmail.com Tested-by: Bin Meng bmeng.cn@gmail.com Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
Changes in v2: None
include/efi.h | 17 ++++------------- lib/efi/Makefile | 4 ++-- 2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/include/efi.h b/include/efi.h index 98bddba..5e1e8ac 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)) diff --git a/lib/efi/Makefile b/lib/efi/Makefile index f1a3929..a790d2d 100644 --- a/lib/efi/Makefile +++ b/lib/efi/Makefile @@ -7,11 +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 \ $(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 \ $(if $(CONFIG_EFI_STUB_64BIT),-m64)
extra-$(CONFIG_EFI_STUB) += efi_stub.o efi.o

Hi Bin, Alex,
On 12 June 2018 at 09:36, Bin Meng bmeng.cn@gmail.com wrote:
From: Alexander Graf agraf@suse.de
Currently efi.h determines a few bits of its environment according to config options. This falls apart with the efi stub support which may result in efi.h getting pulled into the stub as well as real U-Boot code. In that case, one may be 32bit while the other one is 64bit.
This patch changes the conditionals to use compiler provided defines instead. That way we always adhere to the build environment we're in and the definitions adjust automatically.
Signed-off-by: Alexander Graf agraf@suse.de Reviewed-by: Bin Meng bmeng.cn@gmail.com Tested-by: Bin Meng bmeng.cn@gmail.com Signed-off-by: Bin Meng bmeng.cn@gmail.com
Changes in v2: None
include/efi.h | 17 ++++------------- lib/efi/Makefile | 4 ++-- 2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/include/efi.h b/include/efi.h index 98bddba..5e1e8ac 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__ */
I made the same comment in another patch. This is becoming too ad-hoc where making EFI builds work is distributed and hidden in such a way that no one will be able to know whether a change causes problems or not.
I feel that build config should be deterministic given the CONFIG options provided by the board. Any checks of compiler predefines should be done in one place (efi.h?) and bugs in that stuff should there all be in one place too, and easier to debug and fix.
Regards, Simon

On 13.06.18 03:29, Simon Glass wrote:
Hi Bin, Alex,
On 12 June 2018 at 09:36, Bin Meng bmeng.cn@gmail.com wrote:
From: Alexander Graf agraf@suse.de
Currently efi.h determines a few bits of its environment according to config options. This falls apart with the efi stub support which may result in efi.h getting pulled into the stub as well as real U-Boot code. In that case, one may be 32bit while the other one is 64bit.
This patch changes the conditionals to use compiler provided defines instead. That way we always adhere to the build environment we're in and the definitions adjust automatically.
Signed-off-by: Alexander Graf agraf@suse.de Reviewed-by: Bin Meng bmeng.cn@gmail.com Tested-by: Bin Meng bmeng.cn@gmail.com Signed-off-by: Bin Meng bmeng.cn@gmail.com
Changes in v2: None
include/efi.h | 17 ++++------------- lib/efi/Makefile | 4 ++-- 2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/include/efi.h b/include/efi.h index 98bddba..5e1e8ac 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__ */
I made the same comment in another patch. This is becoming too ad-hoc where making EFI builds work is distributed and hidden in such a way that no one will be able to know whether a change causes problems or not.
I feel that build config should be deterministic given the CONFIG options provided by the board. Any checks of compiler predefines should be done in one place (efi.h?) and bugs in that stuff should there all be in one place too, and easier to debug and fix.
I actually think the opposite is true. We should get rid of any #ifdef CONFIG_ARCH checks throughout the code base that are not meant to actually check for the "target" (sandbox for example), but instead really only want to know the architecture the code is building against.
We can easily trust the compiler to emit correct defines for the target architecture it's building against. That's what every other piece of C code on earth depends on. Why be different?
Alex

Hi Alex,
On 13 June 2018 at 04:17, Alexander Graf agraf@suse.de wrote:
On 13.06.18 03:29, Simon Glass wrote:
Hi Bin, Alex,
On 12 June 2018 at 09:36, Bin Meng bmeng.cn@gmail.com wrote:
From: Alexander Graf agraf@suse.de
Currently efi.h determines a few bits of its environment according to config options. This falls apart with the efi stub support which may result in efi.h getting pulled into the stub as well as real U-Boot code. In that case, one may be 32bit while the other one is 64bit.
This patch changes the conditionals to use compiler provided defines instead. That way we always adhere to the build environment we're in and the definitions adjust automatically.
Signed-off-by: Alexander Graf agraf@suse.de Reviewed-by: Bin Meng bmeng.cn@gmail.com Tested-by: Bin Meng bmeng.cn@gmail.com Signed-off-by: Bin Meng bmeng.cn@gmail.com
Changes in v2: None
include/efi.h | 17 ++++------------- lib/efi/Makefile | 4 ++-- 2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/include/efi.h b/include/efi.h index 98bddba..5e1e8ac 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__ */
I made the same comment in another patch. This is becoming too ad-hoc where making EFI builds work is distributed and hidden in such a way that no one will be able to know whether a change causes problems or not.
I feel that build config should be deterministic given the CONFIG options provided by the board. Any checks of compiler predefines should be done in one place (efi.h?) and bugs in that stuff should there all be in one place too, and easier to debug and fix.
I actually think the opposite is true. We should get rid of any #ifdef CONFIG_ARCH checks throughout the code base that are not meant to actually check for the "target" (sandbox for example), but instead really only want to know the architecture the code is building against.
We can easily trust the compiler to emit correct defines for the target architecture it's building against. That's what every other piece of C code on earth depends on. Why be different?
By this logic we would check for __x86_64__ everywhere instead of CONFIG_X86. I can't think of a better way to explain this without repeating myself.
Bin, do you understand what I am getting at? Are my concerns unwarranted?
Regards, Simon

On 06/14/2018 02:58 PM, Simon Glass wrote:
Hi Alex,
On 13 June 2018 at 04:17, Alexander Graf agraf@suse.de wrote:
On 13.06.18 03:29, Simon Glass wrote:
Hi Bin, Alex,
On 12 June 2018 at 09:36, Bin Meng bmeng.cn@gmail.com wrote:
From: Alexander Graf agraf@suse.de
Currently efi.h determines a few bits of its environment according to config options. This falls apart with the efi stub support which may result in efi.h getting pulled into the stub as well as real U-Boot code. In that case, one may be 32bit while the other one is 64bit.
This patch changes the conditionals to use compiler provided defines instead. That way we always adhere to the build environment we're in and the definitions adjust automatically.
Signed-off-by: Alexander Graf agraf@suse.de Reviewed-by: Bin Meng bmeng.cn@gmail.com Tested-by: Bin Meng bmeng.cn@gmail.com Signed-off-by: Bin Meng bmeng.cn@gmail.com
Changes in v2: None
include/efi.h | 17 ++++------------- lib/efi/Makefile | 4 ++-- 2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/include/efi.h b/include/efi.h index 98bddba..5e1e8ac 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__ */
I made the same comment in another patch. This is becoming too ad-hoc where making EFI builds work is distributed and hidden in such a way that no one will be able to know whether a change causes problems or not.
I feel that build config should be deterministic given the CONFIG options provided by the board. Any checks of compiler predefines should be done in one place (efi.h?) and bugs in that stuff should there all be in one place too, and easier to debug and fix.
I actually think the opposite is true. We should get rid of any #ifdef CONFIG_ARCH checks throughout the code base that are not meant to actually check for the "target" (sandbox for example), but instead really only want to know the architecture the code is building against.
We can easily trust the compiler to emit correct defines for the target architecture it's building against. That's what every other piece of C code on earth depends on. Why be different?
By this logic we would check for __x86_64__ everywhere instead of CONFIG_X86. I can't think of a better way to explain this without repeating myself.
That's my point. I think most cases that check for CONFIG_X86 are just plain wrong.
Alex

Hi Simon,
On Thu, Jun 14, 2018 at 8:58 PM, Simon Glass sjg@chromium.org wrote:
Hi Alex,
On 13 June 2018 at 04:17, Alexander Graf agraf@suse.de wrote:
On 13.06.18 03:29, Simon Glass wrote:
Hi Bin, Alex,
On 12 June 2018 at 09:36, Bin Meng bmeng.cn@gmail.com wrote:
From: Alexander Graf agraf@suse.de
Currently efi.h determines a few bits of its environment according to config options. This falls apart with the efi stub support which may result in efi.h getting pulled into the stub as well as real U-Boot code. In that case, one may be 32bit while the other one is 64bit.
This patch changes the conditionals to use compiler provided defines instead. That way we always adhere to the build environment we're in and the definitions adjust automatically.
Signed-off-by: Alexander Graf agraf@suse.de Reviewed-by: Bin Meng bmeng.cn@gmail.com Tested-by: Bin Meng bmeng.cn@gmail.com Signed-off-by: Bin Meng bmeng.cn@gmail.com
Changes in v2: None
include/efi.h | 17 ++++------------- lib/efi/Makefile | 4 ++-- 2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/include/efi.h b/include/efi.h index 98bddba..5e1e8ac 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__ */
I made the same comment in another patch. This is becoming too ad-hoc where making EFI builds work is distributed and hidden in such a way that no one will be able to know whether a change causes problems or not.
I feel that build config should be deterministic given the CONFIG options provided by the board. Any checks of compiler predefines should be done in one place (efi.h?) and bugs in that stuff should there all be in one place too, and easier to debug and fix.
I actually think the opposite is true. We should get rid of any #ifdef CONFIG_ARCH checks throughout the code base that are not meant to actually check for the "target" (sandbox for example), but instead really only want to know the architecture the code is building against.
We can easily trust the compiler to emit correct defines for the target architecture it's building against. That's what every other piece of C code on earth depends on. Why be different?
By this logic we would check for __x86_64__ everywhere instead of CONFIG_X86. I can't think of a better way to explain this without repeating myself.
Bin, do you understand what I am getting at? Are my concerns unwarranted?
I got what you are concerned about. I guess you wanted to say "By this logic we would check __x86_64__ everywhere instead of *CONFIG_X86_64*" As when CONFIG_X86_64 is defined, the "-m64" flag is passed to compiler, and __x86_64__ takes effect. But I think this can only be applied in source codes. In makefiles, we still need CONFIG_X86_64.
For the bug we are trying to address here, I believe current patch to test __x86_64__ is the simplest way compared to a bunch of config options checks. In fact, __x86_64__ contains enough information to fix the problem, and the config options checks look superfluous.
How about we add some comments to the changes above to explain some more details? Does that look better?
Regards, Bin

Hi Bin,
On 15 June 2018 at 03:51, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Jun 14, 2018 at 8:58 PM, Simon Glass sjg@chromium.org wrote:
Hi Alex,
On 13 June 2018 at 04:17, Alexander Graf agraf@suse.de wrote:
On 13.06.18 03:29, Simon Glass wrote:
Hi Bin, Alex,
On 12 June 2018 at 09:36, Bin Meng bmeng.cn@gmail.com wrote:
From: Alexander Graf agraf@suse.de
Currently efi.h determines a few bits of its environment according to config options. This falls apart with the efi stub support which may result in efi.h getting pulled into the stub as well as real U-Boot code. In that case, one may be 32bit while the other one is 64bit.
This patch changes the conditionals to use compiler provided defines instead. That way we always adhere to the build environment we're in and the definitions adjust automatically.
Signed-off-by: Alexander Graf agraf@suse.de Reviewed-by: Bin Meng bmeng.cn@gmail.com Tested-by: Bin Meng bmeng.cn@gmail.com Signed-off-by: Bin Meng bmeng.cn@gmail.com
Changes in v2: None
include/efi.h | 17 ++++------------- lib/efi/Makefile | 4 ++-- 2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/include/efi.h b/include/efi.h index 98bddba..5e1e8ac 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__ */
I made the same comment in another patch. This is becoming too ad-hoc where making EFI builds work is distributed and hidden in such a way that no one will be able to know whether a change causes problems or not.
I feel that build config should be deterministic given the CONFIG options provided by the board. Any checks of compiler predefines should be done in one place (efi.h?) and bugs in that stuff should there all be in one place too, and easier to debug and fix.
I actually think the opposite is true. We should get rid of any #ifdef CONFIG_ARCH checks throughout the code base that are not meant to actually check for the "target" (sandbox for example), but instead really only want to know the architecture the code is building against.
We can easily trust the compiler to emit correct defines for the target architecture it's building against. That's what every other piece of C code on earth depends on. Why be different?
By this logic we would check for __x86_64__ everywhere instead of CONFIG_X86. I can't think of a better way to explain this without repeating myself.
Bin, do you understand what I am getting at? Are my concerns unwarranted?
I got what you are concerned about. I guess you wanted to say "By this logic we would check __x86_64__ everywhere instead of *CONFIG_X86_64*" As when CONFIG_X86_64 is defined, the "-m64" flag is passed to compiler, and __x86_64__ takes effect. But I think this can only be applied in source codes. In makefiles, we still need CONFIG_X86_64.
For the bug we are trying to address here, I believe current patch to test __x86_64__ is the simplest way compared to a bunch of config options checks. In fact, __x86_64__ contains enough information to fix the problem, and the config options checks look superfluous.
How about we add some comments to the changes above to explain some more details? Does that look better?
Thanks for looking at this.
Yes comments would really help, thanks.
Regards, Simon

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.
This changes the x86 __kernel_size_t conditionals to use compiler provided defines instead. That way we always adhere to the build environment we're in and the definitions adjust automatically.
Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t") Signed-off-by: Bin Meng bmeng.cn@gmail.com
---
Changes in v2: - new patch to "change __kernel_size_t conditionals to use compiler provided defines"
arch/x86/include/asm/posix_types.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/posix_types.h b/arch/x86/include/asm/posix_types.h index 717f6cb..a19f1a0 100644 --- a/arch/x86/include/asm/posix_types.h +++ b/arch/x86/include/asm/posix_types.h @@ -16,7 +16,7 @@ typedef int __kernel_pid_t; typedef unsigned short __kernel_ipc_pid_t; typedef unsigned short __kernel_uid_t; typedef unsigned short __kernel_gid_t; -#if CONFIG_IS_ENABLED(X86_64) +#if defined __x86_64__ typedef unsigned long __kernel_size_t; typedef long __kernel_ssize_t; #else

On 12.06.18 17:36, 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, efi_uintn_t gets wrongly interpreted as int, but it should actually be long in a 64-bit EFI environment.
This changes the x86 __kernel_size_t conditionals to use compiler provided defines instead. That way we always adhere to the build environment we're in and the definitions adjust automatically.
Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t") Signed-off-by: Bin Meng bmeng.cn@gmail.com
Reviewed-by: Alexander Graf agraf@suse.de
Alex
Changes in v2:
- new patch to "change __kernel_size_t conditionals to use compiler provided defines"
arch/x86/include/asm/posix_types.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/posix_types.h b/arch/x86/include/asm/posix_types.h index 717f6cb..a19f1a0 100644 --- a/arch/x86/include/asm/posix_types.h +++ b/arch/x86/include/asm/posix_types.h @@ -16,7 +16,7 @@ typedef int __kernel_pid_t; typedef unsigned short __kernel_ipc_pid_t; typedef unsigned short __kernel_uid_t; typedef unsigned short __kernel_gid_t; -#if CONFIG_IS_ENABLED(X86_64) +#if defined __x86_64__ typedef unsigned long __kernel_size_t; typedef long __kernel_ssize_t; #else

Hi Bin,
On 12 June 2018 at 09:36, 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.
This changes the x86 __kernel_size_t conditionals to use compiler provided defines instead. That way we always adhere to the build environment we're in and the definitions adjust automatically.
Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t") Signed-off-by: Bin Meng bmeng.cn@gmail.com
Changes in v2:
- new patch to "change __kernel_size_t conditionals to use compiler provided defines"
arch/x86/include/asm/posix_types.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/posix_types.h b/arch/x86/include/asm/posix_types.h index 717f6cb..a19f1a0 100644 --- a/arch/x86/include/asm/posix_types.h +++ b/arch/x86/include/asm/posix_types.h @@ -16,7 +16,7 @@ typedef int __kernel_pid_t; typedef unsigned short __kernel_ipc_pid_t; typedef unsigned short __kernel_uid_t; typedef unsigned short __kernel_gid_t; -#if CONFIG_IS_ENABLED(X86_64) +#if defined __x86_64__
Ick.
I worry that this is hiding an EFI peculiarity in generic code.
We have a lot of occurrences of '-#if CONFIG_IS_ENABLED(X86_64)' and it is not obvious why this one is wrong and the others are correct. A change to posix_types will presumably affect other things too.
I'm not sure of the best way to solve this,
Is it possible /sensible to introduce a new CONFIG which selects int or long for these types? I am not even sure what it could be called, but then it could normally be set according to the X86_64 setting (in U-Boot or SPL) but changed by EFI.
Or is this not a config setting, but a modulation of a config setting? If so, then perhaps we can have:
#if CONFIG_IS_ENABLED(X86_64) # if <some EFI condition> #define USE_LONG_FOR_64BIT #else #define USE_INT_FOR_64BIT #else #define USE_LONG_FOR_64BIT #endif
But in any case I think we need something explicit for the particular '64-bit int' needed by this particular build of EFI.
I suppose another possibility is that efi_stub.c should not use efi_uintn_t and we should just revert that patch? At present the 64-bit stub is quite clearly differentiated from the rest of U-Boot. Are we just going to end up with a spiderweb of problems here?
typedef unsigned long __kernel_size_t; typedef long __kernel_ssize_t;
#else
2.7.4
Regards, Simon

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 Reviewed-by: Simon Glass sjg@chromium.org
---
Changes in v2: - update README.u-boot_on_efi to reflect directory changes
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 ------- doc/README.u-boot_on_efi | 6 +----- 9 files changed, 10 insertions(+), 16 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 18c7fb2..a1c18d2 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" @@ -772,6 +773,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 0e054da..ba07ac7 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 diff --git a/doc/README.u-boot_on_efi b/doc/README.u-boot_on_efi index d5903c7..0349c56 100644 --- a/doc/README.u-boot_on_efi +++ b/doc/README.u-boot_on_efi @@ -235,12 +235,8 @@ Where is the code? lib/efi payload stub, application, support code. Mostly arch-neutral
-arch/x86/lib/efi - helper functions for the fake DRAM init, etc. These can be used by - any board that runs as a payload. - arch/x86/cpu/efi - x86 support code for running as an EFI application + x86 support code for running as an EFI application and payload
board/efi/efi-x86/efi.c x86 board code for running as an EFI application

On Tue, Jun 12, 2018 at 11:36 PM, 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 Reviewed-by: Simon Glass sjg@chromium.org
Changes in v2:
- update README.u-boot_on_efi to reflect directory changes
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 ------- doc/README.u-boot_on_efi | 6 +----- 9 files changed, 10 insertions(+), 16 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
applied to u-boot-x86, thanks!

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 Reviewed-by: Simon Glass sjg@chromium.org ---
Changes in v2: None
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 Tue, Jun 12, 2018 at 11:36 PM, 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 Reviewed-by: Simon Glass sjg@chromium.org
Changes in v2: None
arch/x86/cpu/efi/payload.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
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 Reviewed-by: Simon Glass sjg@chromium.org
---
Changes in v2: - update README.u-boot_on_efi to mention generic EFI payload support
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 +++++++++++++++++++++++++++++++++ doc/README.u-boot_on_efi | 19 +++++++++--------- include/configs/efi-x86_payload.h | 32 +++++++++++++++++++++++++++++ 11 files changed, 216 insertions(+), 10 deletions(-) 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/doc/README.u-boot_on_efi b/doc/README.u-boot_on_efi index 0349c56..8fba112 100644 --- a/doc/README.u-boot_on_efi +++ b/doc/README.u-boot_on_efi @@ -71,12 +71,13 @@ Just build U-Boot as normal, e.g. make efi-x86_defconfig make
-To build U-Boot as an EFI payload (32-bit or 64-bit EFI can be used), adjust an -existing config (like qemu-x86_defconfig) to enable CONFIG_EFI, CONFIG_EFI_STUB -and either CONFIG_EFI_STUB_32BIT or CONFIG_EFI_STUB_64BIT. All of these are -boolean Kconfig options. Then build U-Boot as normal, e.g. +To build U-Boot as an EFI payload (32-bit or 64-bit EFI can be used), enable +CONFIG_EFI, CONFIG_EFI_STUB, and select either CONFIG_EFI_STUB_32BIT or +CONFIG_EFI_STUB_64BIT. The efi-x86_payload configs (efi-x86_payload32_defconfig +and efi-x86_payload32_defconfig) are set up for this. Then build U-Boot as +normal, e.g.
- make qemu-x86_defconfig + make efi-x86_payload32_defconfig (or efi-x86_payload64_defconfig) make
You will end up with one of these files depending on what you build for: @@ -211,11 +212,6 @@ Future work ----------- This work could be extended in a number of ways:
-- Add a generic x86 EFI payload configuration. At present you need to modify -an existing one, but mostly the low-level x86 code is disabled when booting -on EFI anyway, so a generic 'EFI' board could be created with a suitable set -of drivers enabled. - - Add ARM support
- Add 64-bit application support @@ -241,6 +237,9 @@ arch/x86/cpu/efi board/efi/efi-x86/efi.c x86 board code for running as an EFI application
+board/efi/efi-x86_payload + generic x86 EFI payload board support code + common/cmd_efi.c the 'efi' command
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 Tue, Jun 12, 2018 at 11:36 PM, 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 Reviewed-by: Simon Glass sjg@chromium.org
Changes in v2:
- update README.u-boot_on_efi to mention generic EFI payload support
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 +++++++++++++++++++++++++++++++++ doc/README.u-boot_on_efi | 19 +++++++++--------- include/configs/efi-x86_payload.h | 32 +++++++++++++++++++++++++++++ 11 files changed, 216 insertions(+), 10 deletions(-) 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
applied to u-boot-x86, thanks!

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 Reviewed-by: Simon Glass sjg@chromium.org
---
Changes in v2: - update QEMU MAINTAINERS file to remove defconfig files
arch/x86/cpu/qemu/Makefile | 2 -- arch/x86/cpu/qemu/qemu.c | 4 --- board/emulation/qemu-x86/Kconfig | 6 ++-- board/emulation/qemu-x86/MAINTAINERS | 2 -- configs/qemu-x86_efi_payload32_defconfig | 47 ------------------------------- configs/qemu-x86_efi_payload64_defconfig | 48 -------------------------------- 6 files changed, 3 insertions(+), 106 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/board/emulation/qemu-x86/MAINTAINERS b/board/emulation/qemu-x86/MAINTAINERS index 4cf8ac9..9a99d38 100644 --- a/board/emulation/qemu-x86/MAINTAINERS +++ b/board/emulation/qemu-x86/MAINTAINERS @@ -4,8 +4,6 @@ S: Maintained F: board/emulation/qemu-x86/ F: include/configs/qemu-x86.h F: configs/qemu-x86_defconfig -F: configs/qemu-x86_efi_payload32_defconfig -F: configs/qemu-x86_efi_payload64_defconfig
QEMU X86 64-bit BOARD M: Bin Meng bmeng.cn@gmail.com 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 Tue, Jun 12, 2018 at 11:36 PM, 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 Reviewed-by: Simon Glass sjg@chromium.org
Changes in v2:
- update QEMU MAINTAINERS file to remove defconfig files
arch/x86/cpu/qemu/Makefile | 2 -- arch/x86/cpu/qemu/qemu.c | 4 --- board/emulation/qemu-x86/Kconfig | 6 ++-- board/emulation/qemu-x86/MAINTAINERS | 2 -- configs/qemu-x86_efi_payload32_defconfig | 47 ------------------------------- configs/qemu-x86_efi_payload64_defconfig | 48 -------------------------------- 6 files changed, 3 insertions(+), 106 deletions(-) delete mode 100644 configs/qemu-x86_efi_payload32_defconfig delete mode 100644 configs/qemu-x86_efi_payload64_defconfig
applied to u-boot-x86, thanks!

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 Reviewed-by: Simon Glass sjg@chromium.org ---
Changes in v2: None
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 Tue, Jun 12, 2018 at 11:36 PM, 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 Reviewed-by: Simon Glass sjg@chromium.org
Changes in v2: None
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(-)
applied to u-boot-x86, thanks!

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 Reviewed-by: Simon Glass sjg@chromium.org ---
Changes in v2: None
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 5e1e8ac..639ace0 100644 --- a/include/efi.h +++ b/include/efi.h @@ -233,6 +233,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, @@ -289,6 +290,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 Tue, Jun 12, 2018 at 11:36 PM, 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 Reviewed-by: Simon Glass sjg@chromium.org
Changes in v2: None
include/efi.h | 35 +++++++++++++++++++++++++++++++++++ lib/efi/efi_stub.c | 15 +++++++++++++++ 2 files changed, 50 insertions(+)
applied to u-boot-x86, thanks!

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 ---
Changes in v2: None
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, +};

On Tue, Jun 12, 2018 at 11:36 PM, 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
Changes in v2: None
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
applied to u-boot-x86, thanks!

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 Reviewed-by: Simon Glass sjg@chromium.org ---
Changes in v2: None
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 Tue, Jun 12, 2018 at 11:36 PM, 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 Reviewed-by: Simon Glass sjg@chromium.org
Changes in v2: None
arch/x86/dts/efi-x86_payload.dts | 4 ++++ board/efi/efi-x86_payload/Kconfig | 1 + 2 files changed, 5 insertions(+)
applied to u-boot-x86, thanks!

To avoid confusion, let's rename the efi-x86 target to efi-x86_app.
Signed-off-by: Bin Meng bmeng.cn@gmail.com Reviewed-by: Simon Glass sjg@chromium.org
---
Changes in v2: - update README.u-boot_on_efi to use efi-x86_app
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 ++-- doc/README.u-boot_on_efi | 8 ++++---- include/configs/{efi-x86.h => efi-x86_app.h} | 0 13 files changed, 18 insertions(+), 18 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 a2f072b..9c1d5e7 100644 --- a/configs/efi-x86_defconfig +++ b/configs/efi-x86_app_defconfig @@ -2,8 +2,8 @@ CONFIG_X86=y CONFIG_DEBUG_UART_BASE=0 CONFIG_DEBUG_UART_CLOCK=0 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/doc/README.u-boot_on_efi b/doc/README.u-boot_on_efi index 8fba112..e12dd4e 100644 --- a/doc/README.u-boot_on_efi +++ b/doc/README.u-boot_on_efi @@ -65,10 +65,10 @@ for that board. It will be either 32-bit or 64-bit. Alternatively, you can opt for using QEMU [1] and the OVMF [2], as detailed below.
To build U-Boot as an EFI application (32-bit EFI required), enable CONFIG_EFI -and CONFIG_EFI_APP. The efi-x86 config (efi-x86_defconfig) is set up for this. -Just build U-Boot as normal, e.g. +and CONFIG_EFI_APP. The efi-x86_app config (efi-x86_app_defconfig) is set up +for this. Just build U-Boot as normal, e.g.
- make efi-x86_defconfig + make efi-x86_app_defconfig make
To build U-Boot as an EFI payload (32-bit or 64-bit EFI can be used), enable @@ -234,7 +234,7 @@ lib/efi arch/x86/cpu/efi x86 support code for running as an EFI application and payload
-board/efi/efi-x86/efi.c +board/efi/efi-x86_app/efi.c x86 board code for running as an EFI application
board/efi/efi-x86_payload 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 Tue, Jun 12, 2018 at 11:36 PM, 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 Reviewed-by: Simon Glass sjg@chromium.org
Changes in v2:
- update README.u-boot_on_efi to use efi-x86_app
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 ++-- doc/README.u-boot_on_efi | 8 ++++---- include/configs/{efi-x86.h => efi-x86_app.h} | 0 13 files changed, 18 insertions(+), 18 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%)
applied to u-boot-x86, thanks!

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 Reviewed-by: Simon Glass sjg@chromium.org
---
Changes in v2: - drop patches that were already applied to u-boot-x86
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 Tue, Jun 12, 2018 at 11:36 PM, 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 Reviewed-by: Simon Glass sjg@chromium.org
Changes in v2:
- drop patches that were already applied to u-boot-x86
arch/x86/cpu/efi/app.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
applied to u-boot-x86, thanks!
participants (4)
-
Alexander Graf
-
Bin Meng
-
Heinrich Schuchardt
-
Simon Glass