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

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

[Bin Meng]

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

-- 
2.7.4

[U-Boot] [PATCH 01/18] x86: doc: Fix reference to EFI doc in U-Boot

[Bin Meng]

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
 --------------
-- 
2.7.4

[U-Boot] [PATCH 01/18] x86: doc: Fix reference to EFI doc in U-Boot

[Heinrich Schuchardt]

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
>  --------------
> 

[U-Boot] [PATCH 01/18] x86: doc: Fix reference to EFI doc in U-Boot

[Bin Meng]

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

[U-Boot] [PATCH 01/18] x86: doc: Fix reference to EFI doc in U-Boot

[Heinrich Schuchardt]

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
> 

[U-Boot] [PATCH 02/18] x86: Conditionally build the pinctrl_ich6 driver

[Bin Meng]

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
-- 
2.7.4

[U-Boot] [PATCH 02/18] x86: Conditionally build the pinctrl_ich6 driver

[Simon Glass]

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>

[U-Boot] [PATCH 02/18] x86: Conditionally build the pinctrl_ich6 driver

[Bin Meng]

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!

[U-Boot] [PATCH 03/18] x86: efi: app: Fix broken EFI application

[Bin Meng]

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
-- 
2.7.4

[U-Boot] [PATCH 03/18] x86: efi: app: Fix broken EFI application

[Simon Glass]

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>

[U-Boot] [PATCH 03/18] x86: efi: app: Fix broken EFI application

[Bin Meng]

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!

[U-Boot] [PATCH 03/18] x86: efi: app: Fix broken EFI application

[Heinrich Schuchardt]

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
> 

[U-Boot] [PATCH 03/18] x86: efi: app: Fix broken EFI application

[Bin Meng]

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

[U-Boot] [PATCH 04/18] x86: efi: payload: Enforce toolchain to generate 64-bit EFI payload stub codes

[Bin Meng]

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
-- 
2.7.4

[U-Boot] [PATCH 04/18] x86: efi: payload: Enforce toolchain to generate 64-bit EFI payload stub codes

[Alexander Graf]

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

[U-Boot] [PATCH 04/18] x86: efi: payload: Enforce toolchain to generate 64-bit EFI payload stub codes

[Bin Meng]

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

[U-Boot] [PATCH 04/18] x86: efi: payload: Enforce toolchain to generate 64-bit EFI payload stub codes

[Alexander Graf]

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

[U-Boot] [PATCH 04/18] x86: efi: payload: Enforce toolchain to generate 64-bit EFI payload stub codes

[Bin Meng]

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

[U-Boot] [PATCH 04/18] x86: efi: payload: Enforce toolchain to generate 64-bit EFI payload stub codes

[Simon Glass]

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!

[U-Boot] [PATCH 04/18] x86: efi: payload: Enforce toolchain to generate 64-bit EFI payload stub codes

[Bin Meng]

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!

[U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload

[Bin Meng]

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
-- 
2.7.4

[U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload

[Heinrich Schuchardt]

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
> 

[U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload

[Bin Meng]

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

[U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload

[Heinrich Schuchardt]

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
> 

[U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload

[Bin Meng]

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

[U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload

[Heinrich Schuchardt]

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
> 

[U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload

[Bin Meng]

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

[U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload

[Heinrich Schuchardt]

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
> 

[U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload

[Bin Meng]

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

[U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload

[Alexander Graf]

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

[U-Boot] [PATCH 06/18] dm: pci: Make ranges dt property optional

[Bin Meng]

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;
 
-- 
2.7.4

[U-Boot] [PATCH 06/18] dm: pci: Make ranges dt property optional

[Simon Glass]

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>

[U-Boot] [PATCH 06/18] dm: pci: Make ranges dt property optional

[Bin Meng]

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!

[U-Boot] [PATCH 07/18] dm: pci: Use a 1:1 mapping for bus <-> phy addresses

[Bin Meng]

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];
 
-- 
2.7.4

[U-Boot] [PATCH 07/18] dm: pci: Use a 1:1 mapping for bus <-> phy addresses

[Simon Glass]

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>

[U-Boot] [PATCH 07/18] dm: pci: Use a 1:1 mapping for bus <-> phy addresses

[Bin Meng]

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!

[U-Boot] [PATCH 08/18] x86: efi: Refactor the directory of EFI app and payload support

[Bin Meng]

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 at denx.de.
-
-obj-$(CONFIG_EFI_STUB) += car.o
-obj-$(CONFIG_EFI_STUB) += efi.o
-- 
2.7.4

[U-Boot] [PATCH 08/18] x86: efi: Refactor the directory of EFI app and payload support

[Simon Glass]

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>

[U-Boot] [PATCH 09/18] x86: efi: payload: Add arch_cpu_init()

[Bin Meng]

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;
-- 
2.7.4

[U-Boot] [PATCH 09/18] x86: efi: payload: Add arch_cpu_init()

[Simon Glass]

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>

[U-Boot] [PATCH 10/18] x86: efi: payload: Minor clean up on error message output

[Bin Meng]

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);
-- 
2.7.4

[U-Boot] [PATCH 10/18] x86: efi: payload: Minor clean up on error message output

[Simon Glass]

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>

[U-Boot] [PATCH 10/18] x86: efi: payload: Minor clean up on error message output

[Bin Meng]

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!

[U-Boot] [PATCH 11/18] x86: Add generic EFI payload support

[Bin Meng]

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 */
-- 
2.7.4

[U-Boot] [PATCH 11/18] x86: Add generic EFI payload support

[Simon Glass]

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>

[U-Boot] [PATCH 12/18] x86: Drop QEMU-specific EFI payload support

[Bin Meng]

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
-- 
2.7.4

[U-Boot] [PATCH 12/18] x86: Drop QEMU-specific EFI payload support

[Simon Glass]

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>

[U-Boot] [PATCH 13/18] x86: baytrail: Drop EFI-specific test logics

[Bin Meng]

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
-- 
2.7.4

[U-Boot] [PATCH 13/18] x86: baytrail: Drop EFI-specific test logics

[Simon Glass]

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>

[U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload

[Bin Meng]

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);
-- 
2.7.4

[U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload

[Alexander Graf]

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

[U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload

[Bin Meng]

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

[U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload

[Alexander Graf]

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

[U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload

[Bin Meng]

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

[U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload

[Alexander Graf]

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

[U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload

[Bin Meng]

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

[U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload

[Alexander Graf]

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))

[U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload

[Bin Meng]

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

[U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload

[Simon Glass]

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

[U-Boot] [PATCH 15/18] dm: video: Add an EFI framebuffer driver

[Bin Meng]

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,
+};
-- 
2.7.4

[U-Boot] [PATCH 15/18] dm: video: Add an EFI framebuffer driver

[Anatolij Gustschin]

Hi Bin,

On Sun, 10 Jun 2018 06:25:14 -0700
Bin Meng bmeng.cn at 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

[U-Boot] [PATCH 16/18] x86: efi: payload: Add EFI framebuffer driver support

[Bin Meng]

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
-- 
2.7.4

[U-Boot] [PATCH 16/18] x86: efi: payload: Add EFI framebuffer driver support

[Simon Glass]

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>

[U-Boot] [PATCH 17/18] x86: Rename efi-x86 target to efi-x86_app

[Bin Meng]

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
-- 
2.7.4

[U-Boot] [PATCH 17/18] x86: Rename efi-x86 target to efi-x86_app

[Simon Glass]

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?

[U-Boot] [PATCH 17/18] x86: Rename efi-x86 target to efi-x86_app

[Bin Meng]

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

[U-Boot] [PATCH 18/18] x86: efi: app: Display correct CPU info during boot

[Bin Meng]

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)
-- 
2.7.4

[U-Boot] [PATCH 18/18] x86: efi: app: Display correct CPU info during boot

[Simon Glass]

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>

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

[Simon Glass]

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

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

[Bin Meng]

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

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

[Simon Glass]

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:
>
> 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

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