[U-Boot] [PATCH 1/5] x86: timer: tsc: Allow specifying clock rate from device tree again

[U-Boot] [PATCH 1/5] x86: timer: tsc: Allow specifying clock rate from device tree again

[Bin Meng]

With the introduction of early timer support in the TSC driver,
the capability of getting clock rate from device tree was lost
unfortunately. Now we bring such functionality back, but with a
limitation that when TSC is used as early timer, specifying clock
rate from device tree does not work.

This fixes random boot failures seen on QEMU targets: printing "TSC
frequency is ZERO" and reset forever.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/timer/tsc_timer.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/timer/tsc_timer.c b/drivers/timer/tsc_timer.c
index cf86999..747f190 100644
--- a/drivers/timer/tsc_timer.c
+++ b/drivers/timer/tsc_timer.c
@@ -377,14 +377,23 @@ static int tsc_timer_probe(struct udevice *dev)
 {
 	struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
 
-	tsc_timer_ensure_setup();
-	uc_priv->clock_rate = gd->arch.clock_rate;
+	if (!uc_priv->clock_rate) {
+		tsc_timer_ensure_setup();
+		uc_priv->clock_rate = gd->arch.clock_rate;
+	} else {
+		gd->arch.tsc_base = rdtsc();
+	}
 
 	return 0;
 }
 
 unsigned long notrace timer_early_get_rate(void)
 {
+	/*
+	 * When TSC timer is used as the early timer, be warned that the timer
+	 * clock rate can only be calibrated via some hardware ways. Specifying
+	 * it in the device tree won't work for the early timer.
+	 */
 	tsc_timer_ensure_setup();
 
 	return gd->arch.clock_rate;
-- 
2.7.4

[U-Boot] [PATCH 2/5] x86: efi_loader: Build EFI memory map per E820 table

[Bin Meng]

On x86 traditional E820 table is used to pass the memory information
to kernel. With EFI loader we can build the EFI memory map from it.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 arch/x86/lib/e820.c | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/arch/x86/lib/e820.c b/arch/x86/lib/e820.c
index 9a9ec99..8b34f67 100644
--- a/arch/x86/lib/e820.c
+++ b/arch/x86/lib/e820.c
@@ -4,6 +4,7 @@
  */
 
 #include <common.h>
+#include <efi_loader.h>
 #include <asm/e820.h>
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -34,3 +35,41 @@ __weak unsigned int install_e820_map(unsigned int max_entries,
 
 	return 4;
 }
+
+#if defined(CONFIG_EFI_LOADER) && !defined(CONFIG_SPL_BUILD)
+void efi_add_known_memory(void)
+{
+	struct e820_entry e820[E820MAX];
+	unsigned int i, num;
+	u64 start, pages;
+	int type;
+
+	num = install_e820_map(ARRAY_SIZE(e820), e820);
+
+	for (i = 0; i < num; ++i) {
+		start = e820[i].addr;
+		pages = ALIGN(e820[i].size, EFI_PAGE_SIZE) >> EFI_PAGE_SHIFT;
+
+		switch (e820[i].type) {
+		case E820_RAM:
+			type = EFI_CONVENTIONAL_MEMORY;
+			break;
+		case E820_RESERVED:
+			type = EFI_RESERVED_MEMORY_TYPE;
+			break;
+		case E820_ACPI:
+			type = EFI_ACPI_RECLAIM_MEMORY;
+			break;
+		case E820_NVS:
+			type = EFI_ACPI_MEMORY_NVS;
+			break;
+		case E820_UNUSABLE:
+		default:
+			type = EFI_UNUSABLE_MEMORY;
+			break;
+		}
+
+		efi_add_memory_map(start, pages, type, false);
+	}
+}
+#endif /* defined(EFI_LOADER) && !defined(CONFIG_SPL_BUILD) */
-- 
2.7.4

[U-Boot] [PATCH 3/5] efi_loader: Install ACPI configuration tables

[Bin Meng]

ACPI tables can be passed via EFI configuration table to an EFI
application. This is only supported on x86 so far.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 cmd/bootefi.c             |  5 +++++
 include/efi_api.h         |  8 ++++++++
 include/efi_loader.h      |  8 ++++++++
 lib/efi_loader/Makefile   |  1 +
 lib/efi_loader/efi_acpi.c | 42 ++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 64 insertions(+)
 create mode 100644 lib/efi_loader/efi_acpi.c

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index f55a40d..cd755b6 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -61,6 +61,11 @@ efi_status_t efi_init_obj_list(void)
 	if (ret != EFI_SUCCESS)
 		goto out;
 #endif
+#ifdef CONFIG_GENERATE_ACPI_TABLE
+	ret = efi_acpi_register();
+	if (ret != EFI_SUCCESS)
+		goto out;
+#endif
 #ifdef CONFIG_GENERATE_SMBIOS_TABLE
 	ret = efi_smbios_register();
 	if (ret != EFI_SUCCESS)
diff --git a/include/efi_api.h b/include/efi_api.h
index 094be6e..69dcbac 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -286,6 +286,14 @@ struct efi_runtime_services {
 	EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3,  \
 		 0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
 
+#define ACPI_TABLE_GUID \
+	EFI_GUID(0xeb9d2d30, 0x2d88, 0x11d3, \
+		 0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
+
+#define ACPI_20_TABLE_GUID \
+	EFI_GUID(0x8868e871, 0xe4f1, 0x11d3, \
+		 0xbc, 0x22, 0x00, 0x80, 0xc7, 0x3c, 0x88, 0x81)
+
 struct efi_configuration_table
 {
 	efi_guid_t guid;
diff --git a/include/efi_loader.h b/include/efi_loader.h
index c66252a..d837e7b 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -215,6 +215,14 @@ efi_status_t efi_net_register(void);
 efi_status_t efi_watchdog_register(void);
 /* Called by bootefi to make SMBIOS tables available */
 /**
+ * efi_acpi_register() - write out ACPI tables
+ *
+ * Called by bootefi to make ACPI tables available
+ *
+ * @return 0 if OK, -ENOMEM if no memory is available for the tables
+ */
+efi_status_t efi_acpi_register(void);
+/**
  * efi_smbios_register() - write out SMBIOS tables
  *
  * Called by bootefi to make SMBIOS tables available
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index c6046e3..d6402c4 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -22,4 +22,5 @@ obj-$(CONFIG_LCD) += efi_gop.o
 obj-$(CONFIG_DM_VIDEO) += efi_gop.o
 obj-$(CONFIG_PARTITIONS) += efi_disk.o
 obj-$(CONFIG_NET) += efi_net.o
+obj-$(CONFIG_GENERATE_ACPI_TABLE) += efi_acpi.o
 obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
diff --git a/lib/efi_loader/efi_acpi.c b/lib/efi_loader/efi_acpi.c
new file mode 100644
index 0000000..b09292c
--- /dev/null
+++ b/lib/efi_loader/efi_acpi.c
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  EFI application ACPI tables support
+ *
+ *  Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+#include <common.h>
+#include <efi_loader.h>
+#include <asm/acpi_table.h>
+
+static const efi_guid_t acpi_guid = ACPI_20_TABLE_GUID;
+
+/*
+ * Install the ACPI table as a configuration table.
+ *
+ * @return	status code
+ */
+efi_status_t efi_acpi_register(void)
+{
+	/* Map within the low 32 bits, to allow for 32bit ACPI tables */
+	u64 acpi = U32_MAX;
+	efi_status_t ret;
+
+	/* Reserve 64kiB page for ACPI */
+	ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
+				 EFI_RUNTIME_SERVICES_DATA, 16, &acpi);
+	if (ret != EFI_SUCCESS)
+		return ret;
+
+	/*
+	 * Generate ACPI tables - we know that efi_allocate_pages() returns
+	 * a 4k-aligned address, so it is safe to assume that
+	 * write_acpi_tables() will write the table at that address.
+	 */
+	assert(!(acpi & 0xf));
+	write_acpi_tables(acpi);
+
+	/* And expose them to our EFI payload */
+	return efi_install_configuration_table(&acpi_guid,
+					       (void *)(uintptr_t)acpi);
+}
-- 
2.7.4

[U-Boot] [PATCH 4/5] x86: doc: Update EFI loader support

[Bin Meng]

CONFIG_EFI_LOADER is fully supported on x86 now.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 doc/README.x86 | 29 +++++++++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/doc/README.x86 b/doc/README.x86
index 9f657df..9162ea1 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -1136,9 +1136,34 @@ EFI Support
 U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI.
 This is enabled with CONFIG_EFI_STUB to boot from both 32-bit and 64-bit
 UEFI BIOS. U-Boot can also run as an EFI application, with CONFIG_EFI_APP.
-The CONFIG_EFI_LOADER option, where U-Booot provides an EFI environment to
+The CONFIG_EFI_LOADER option, where U-Boot 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.
+services) is supported too. For example, we can even use 'bootefi' command
+to load a 'u-boot-payload.efi', see below test logs on QEMU.
+
+  => load ide 0 3000000 u-boot-payload.efi
+  489787 bytes read in 138 ms (3.4 MiB/s)
+  => bootefi 3000000
+  Scanning disk ide.blk#0...
+  Found 2 disks
+  WARNING: booting without device tree
+  ## Starting EFI application at 03000000 ...
+  U-Boot EFI Payload
+
+
+  U-Boot 2018.07-rc2 (Jun 23 2018 - 17:12:58 +0800)
+
+  CPU: x86_64, vendor AMD, device 663h
+  DRAM:  2 GiB
+  MMC:
+  Video: 1024x768x32
+  Model: EFI x86 Payload
+  Net:   e1000: 52:54:00:12:34:56
+
+  Warning: e1000#0 using MAC address from ROM
+  eth0: e1000#0
+  No controllers found
+  Hit any key to stop autoboot:  0
 
 See README.u-boot_on_efi and README.uefi for details of EFI support in U-Boot.
 
-- 
2.7.4

[U-Boot] [PATCH 5/5] doc: vxworks: Mention chain-loading an x86 kernel via 'bootefi'

[Bin Meng]

This updates the doc to mention chain-loading an x86 kernel via
'bootefi' command, along with several typos fix.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 doc/README.vxworks | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/doc/README.vxworks b/doc/README.vxworks
index 1aa8e44..3e08711 100644
--- a/doc/README.vxworks
+++ b/doc/README.vxworks
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 # Copyright (C) 2013, Miao Yan <miao.yan@windriver.com>
-# Copyright (C) 2015, Bin Meng <bmeng.cn@gmail.com>
+# Copyright (C) 2015-2018, Bin Meng <bmeng.cn@gmail.com>
 
 VxWorks Support
 ===============
@@ -15,10 +15,13 @@ For booting old kernels (6.9.x) on PowerPC and ARM, and all kernel versions
 on other architectures, 'bootvx' shall be used. For booting VxWorks 7 kernels
 on PowerPC and ARM, 'bootm' shall be used.
 
+With CONFIG_EFI_LOADER option, it's possible to chain load a VxWorks x86 kernel
+via the UEFI boot loader application for VxWorks loaded by 'bootefi' command.
+
 VxWorks 7 on PowerPC and ARM
 ---------------------------
-From VxWorks 7, VxWorks starts adopting device tree as its hardware decription
-mechansim (for PowerPC and ARM), thus requiring boot interface changes.
+From VxWorks 7, VxWorks starts adopting device tree as its hardware description
+mechanism (for PowerPC and ARM), thus requiring boot interface changes.
 This section will describe the new interface.
 
 For PowerPC, the calling convention of the new VxWorks entry point conforms to
@@ -53,6 +56,9 @@ gatewayip, hostname, othbootargs.
 When using 'bootm', just define "bootargs" in the environment and U-Boot will
 handle bootline fix up for the kernel dtb automatically.
 
+When using 'bootefi' to chain load an x86 kernel, the UEFI boot loader
+application for VxWorks takes care of the kernel bootline preparation.
+
 Serial console
 --------------
 It's very common that VxWorks BSPs configure a different baud rate for the
@@ -63,9 +69,9 @@ look like VxWorks hangs somewhere as nothing outputs on the serial console.
 
 x86-specific information
 ------------------------
-Before loading an x86 kernel, one additional environment variable need to be
-provided. This is "vx_phys_mem_base", which represent the physical memory
-base address of VxWorks.
+Before direct loading an x86 kernel via 'bootvx', one additional environment
+variable need to be provided. This is "vx_phys_mem_base", which represent the
+physical memory base address of VxWorks.
 
 Check VxWorks kernel configuration to look for LOCAL_MEM_LOCAL_ADRS. For
 VxWorks 7, this is normally a virtual address and you need find out its
-- 
2.7.4

[U-Boot] [PATCH 1/5] x86: timer: tsc: Allow specifying clock rate from device tree again

[Simon Glass]

On 23 June 2018 at 04:03, Bin Meng <bmeng.cn@gmail.com> wrote:
> With the introduction of early timer support in the TSC driver,
> the capability of getting clock rate from device tree was lost
> unfortunately. Now we bring such functionality back, but with a
> limitation that when TSC is used as early timer, specifying clock
> rate from device tree does not work.
>
> This fixes random boot failures seen on QEMU targets: printing "TSC
> frequency is ZERO" and reset forever.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  drivers/timer/tsc_timer.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 2/5] x86: efi_loader: Build EFI memory map per E820 table

[Simon Glass]

On 23 June 2018 at 04:03, Bin Meng <bmeng.cn@gmail.com> wrote:
> On x86 traditional E820 table is used to pass the memory information
> to kernel. With EFI loader we can build the EFI memory map from it.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  arch/x86/lib/e820.c | 39 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
>

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 3/5] efi_loader: Install ACPI configuration tables

[Simon Glass]

On 23 June 2018 at 04:03, Bin Meng <bmeng.cn@gmail.com> wrote:
> ACPI tables can be passed via EFI configuration table to an EFI
> application. This is only supported on x86 so far.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  cmd/bootefi.c             |  5 +++++
>  include/efi_api.h         |  8 ++++++++
>  include/efi_loader.h      |  8 ++++++++
>  lib/efi_loader/Makefile   |  1 +
>  lib/efi_loader/efi_acpi.c | 42 ++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 64 insertions(+)
>  create mode 100644 lib/efi_loader/efi_acpi.c

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 4/5] x86: doc: Update EFI loader support

[Simon Glass]

On 23 June 2018 at 04:03, Bin Meng <bmeng.cn@gmail.com> wrote:
> CONFIG_EFI_LOADER is fully supported on x86 now.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  doc/README.x86 | 29 +++++++++++++++++++++++++++--
>  1 file changed, 27 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 5/5] doc: vxworks: Mention chain-loading an x86 kernel via 'bootefi'

[Simon Glass]

On 23 June 2018 at 04:03, Bin Meng <bmeng.cn@gmail.com> wrote:
> This updates the doc to mention chain-loading an x86 kernel via
> 'bootefi' command, along with several typos fix.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  doc/README.vxworks | 18 ++++++++++++------
>  1 file changed, 12 insertions(+), 6 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 2/5] x86: efi_loader: Build EFI memory map per E820 table

[Heinrich Schuchardt]

On 06/23/2018 12:03 PM, Bin Meng wrote:
> On x86 traditional E820 table is used to pass the memory information
> to kernel. With EFI loader we can build the EFI memory map from it.
> 
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
> 
>  arch/x86/lib/e820.c | 39 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/arch/x86/lib/e820.c b/arch/x86/lib/e820.c
> index 9a9ec99..8b34f67 100644
> --- a/arch/x86/lib/e820.c
> +++ b/arch/x86/lib/e820.c
> @@ -4,6 +4,7 @@
>   */
>  
>  #include <common.h>
> +#include <efi_loader.h>
>  #include <asm/e820.h>
>  
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -34,3 +35,41 @@ __weak unsigned int install_e820_map(unsigned int max_entries,
>  
>  	return 4;
>  }
> +
> +#if defined(CONFIG_EFI_LOADER) && !defined(CONFIG_SPL_BUILD)
> +void efi_add_known_memory(void)
> +{
> +	struct e820_entry e820[E820MAX];
> +	unsigned int i, num;
> +	u64 start, pages;
> +	int type;
> +
> +	num = install_e820_map(ARRAY_SIZE(e820), e820);

Thanks for the patch. Not handling the E820 table is a known deficiency
of our EFI implementation.

I am a bit worried about error handling here.

What guarantees that lib_sysinfo.n_memranges <= E820MAX?

install_e820_map() prints a message if max_entries is too small but it
does not return an error code.

So only if num < E820MAX we can be sure that the call returned all
information of interest.

My idea is that the interface of efi_add_known_memory() should be
changed to allow returning an error code if it fails. And
efi_memory_init() should return an eventual error to board_init_r().

Best regards

Heinrich

> +
> +	for (i = 0; i < num; ++i) {
> +		start = e820[i].addr;
> +		pages = ALIGN(e820[i].size, EFI_PAGE_SIZE) >> EFI_PAGE_SHIFT;
> +
> +		switch (e820[i].type) {
> +		case E820_RAM:
> +			type = EFI_CONVENTIONAL_MEMORY;
> +			break;
> +		case E820_RESERVED:
> +			type = EFI_RESERVED_MEMORY_TYPE;
> +			break;
> +		case E820_ACPI:
> +			type = EFI_ACPI_RECLAIM_MEMORY;
> +			break;
> +		case E820_NVS:
> +			type = EFI_ACPI_MEMORY_NVS;
> +			break;
> +		case E820_UNUSABLE:
> +		default:
> +			type = EFI_UNUSABLE_MEMORY;
> +			break;
> +		}
> +
> +		efi_add_memory_map(start, pages, type, false);
> +	}
> +}
> +#endif /* defined(EFI_LOADER) && !defined(CONFIG_SPL_BUILD) */
> 

[U-Boot] [PATCH 3/5] efi_loader: Install ACPI configuration tables

[Heinrich Schuchardt]

/On 06/23/2018 12:03 PM, Bin Meng wrote:
> ACPI tables can be passed via EFI configuration table to an EFI
> application. This is only supported on x86 so far.
> 
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
> 
>  cmd/bootefi.c             |  5 +++++
>  include/efi_api.h         |  8 ++++++++
>  include/efi_loader.h      |  8 ++++++++
>  lib/efi_loader/Makefile   |  1 +
>  lib/efi_loader/efi_acpi.c | 42 ++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 64 insertions(+)
>  create mode 100644 lib/efi_loader/efi_acpi.c
> 
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index f55a40d..cd755b6 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -61,6 +61,11 @@ efi_status_t efi_init_obj_list(void)
>  	if (ret != EFI_SUCCESS)
>  		goto out;
>  #endif
> +#ifdef CONFIG_GENERATE_ACPI_TABLE
> +	ret = efi_acpi_register();
> +	if (ret != EFI_SUCCESS)
> +		goto out;
> +#endif
>  #ifdef CONFIG_GENERATE_SMBIOS_TABLE
>  	ret = efi_smbios_register();
>  	if (ret != EFI_SUCCESS)
> diff --git a/include/efi_api.h b/include/efi_api.h
> index 094be6e..69dcbac 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -286,6 +286,14 @@ struct efi_runtime_services {
>  	EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3,  \
>  		 0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
>  
> +#define ACPI_TABLE_GUID \
> +	EFI_GUID(0xeb9d2d30, 0x2d88, 0x11d3, \
> +		 0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
> +
> +#define ACPI_20_TABLE_GUID \
> +	EFI_GUID(0x8868e871, 0xe4f1, 0x11d3, \
> +		 0xbc, 0x22, 0x00, 0x80, 0xc7, 0x3c, 0x88, 0x81)
> +
>  struct efi_configuration_table
>  {
>  	efi_guid_t guid;
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index c66252a..d837e7b 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -215,6 +215,14 @@ efi_status_t efi_net_register(void);
>  efi_status_t efi_watchdog_register(void);
>  /* Called by bootefi to make SMBIOS tables available */
>  /**
> + * efi_acpi_register() - write out ACPI tables
> + *
> + * Called by bootefi to make ACPI tables available
> + *
> + * @return 0 if OK, -ENOMEM if no memory is available for the tables
> + */
> +efi_status_t efi_acpi_register(void);
> +/**
>   * efi_smbios_register() - write out SMBIOS tables
>   *
>   * Called by bootefi to make SMBIOS tables available
> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> index c6046e3..d6402c4 100644
> --- a/lib/efi_loader/Makefile
> +++ b/lib/efi_loader/Makefile
> @@ -22,4 +22,5 @@ obj-$(CONFIG_LCD) += efi_gop.o
>  obj-$(CONFIG_DM_VIDEO) += efi_gop.o
>  obj-$(CONFIG_PARTITIONS) += efi_disk.o
>  obj-$(CONFIG_NET) += efi_net.o
> +obj-$(CONFIG_GENERATE_ACPI_TABLE) += efi_acpi.o
>  obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
> diff --git a/lib/efi_loader/efi_acpi.c b/lib/efi_loader/efi_acpi.c
> new file mode 100644
> index 0000000..b09292c
> --- /dev/null
> +++ b/lib/efi_loader/efi_acpi.c
> @@ -0,0 +1,42 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + *  EFI application ACPI tables support
> + *
> + *  Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> + */
> +
> +#include <common.h>
> +#include <efi_loader.h>
> +#include <asm/acpi_table.h>
> +
> +static const efi_guid_t acpi_guid = ACPI_20_TABLE_GUID;
> +
> +/*
> + * Install the ACPI table as a configuration table.
> + *
> + * @return	status code
> + */
> +efi_status_t efi_acpi_register(void)
> +{
> +	/* Map within the low 32 bits, to allow for 32bit ACPI tables */
> +	u64 acpi = U32_MAX;
> +	efi_status_t ret;
> +
> +	/* Reserve 64kiB page for ACPI */
> +	ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
> +				 EFI_RUNTIME_SERVICES_DATA, 16, &acpi);
> +	if (ret != EFI_SUCCESS)
> +		return ret;
> +
> +	/*
> +	 * Generate ACPI tables - we know that efi_allocate_pages() returns
> +	 * a 4k-aligned address, so it is safe to assume that
> +	 * write_acpi_tables() will write the table at that address.
> +	 */
> +	assert(!(acpi & 0xf));
> +	write_acpi_tables(acpi);
> +
> +	/* And expose them to our EFI payload */
> +	return efi_install_configuration_table(&acpi_guid,
> +					       (void *)(uintptr_t)acpi);

The maximum number of configuration tables is currently hard coded as 2
in efi_boottime.c. I think this limit should be raised. 16 seems
reasonable looking at which tables the Linux EFI stub or iPXE can process.

In lib/efi_loader/helloworld.c we output the installed configuration
tables. Please, add the ACPI 2.0 table there too. This will allow future
testing in Travis CI.

Best regards

Heinrich

> +}
> 

[U-Boot] [PATCH 3/5] efi_loader: Install ACPI configuration tables

[Alexander Graf]

On 06/24/2018 12:12 PM, Heinrich Schuchardt wrote:
> /On 06/23/2018 12:03 PM, Bin Meng wrote:
>> ACPI tables can be passed via EFI configuration table to an EFI
>> application. This is only supported on x86 so far.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>   cmd/bootefi.c             |  5 +++++
>>   include/efi_api.h         |  8 ++++++++
>>   include/efi_loader.h      |  8 ++++++++
>>   lib/efi_loader/Makefile   |  1 +
>>   lib/efi_loader/efi_acpi.c | 42 ++++++++++++++++++++++++++++++++++++++++++
>>   5 files changed, 64 insertions(+)
>>   create mode 100644 lib/efi_loader/efi_acpi.c
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index f55a40d..cd755b6 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -61,6 +61,11 @@ efi_status_t efi_init_obj_list(void)
>>   	if (ret != EFI_SUCCESS)
>>   		goto out;
>>   #endif
>> +#ifdef CONFIG_GENERATE_ACPI_TABLE
>> +	ret = efi_acpi_register();
>> +	if (ret != EFI_SUCCESS)
>> +		goto out;
>> +#endif
>>   #ifdef CONFIG_GENERATE_SMBIOS_TABLE
>>   	ret = efi_smbios_register();
>>   	if (ret != EFI_SUCCESS)
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index 094be6e..69dcbac 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -286,6 +286,14 @@ struct efi_runtime_services {
>>   	EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3,  \
>>   		 0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
>>   
>> +#define ACPI_TABLE_GUID \
>> +	EFI_GUID(0xeb9d2d30, 0x2d88, 0x11d3, \
>> +		 0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
>> +
>> +#define ACPI_20_TABLE_GUID \
>> +	EFI_GUID(0x8868e871, 0xe4f1, 0x11d3, \
>> +		 0xbc, 0x22, 0x00, 0x80, 0xc7, 0x3c, 0x88, 0x81)
>> +
>>   struct efi_configuration_table
>>   {
>>   	efi_guid_t guid;
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index c66252a..d837e7b 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -215,6 +215,14 @@ efi_status_t efi_net_register(void);
>>   efi_status_t efi_watchdog_register(void);
>>   /* Called by bootefi to make SMBIOS tables available */
>>   /**
>> + * efi_acpi_register() - write out ACPI tables
>> + *
>> + * Called by bootefi to make ACPI tables available
>> + *
>> + * @return 0 if OK, -ENOMEM if no memory is available for the tables
>> + */
>> +efi_status_t efi_acpi_register(void);
>> +/**
>>    * efi_smbios_register() - write out SMBIOS tables
>>    *
>>    * Called by bootefi to make SMBIOS tables available
>> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>> index c6046e3..d6402c4 100644
>> --- a/lib/efi_loader/Makefile
>> +++ b/lib/efi_loader/Makefile
>> @@ -22,4 +22,5 @@ obj-$(CONFIG_LCD) += efi_gop.o
>>   obj-$(CONFIG_DM_VIDEO) += efi_gop.o
>>   obj-$(CONFIG_PARTITIONS) += efi_disk.o
>>   obj-$(CONFIG_NET) += efi_net.o
>> +obj-$(CONFIG_GENERATE_ACPI_TABLE) += efi_acpi.o
>>   obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
>> diff --git a/lib/efi_loader/efi_acpi.c b/lib/efi_loader/efi_acpi.c
>> new file mode 100644
>> index 0000000..b09292c
>> --- /dev/null
>> +++ b/lib/efi_loader/efi_acpi.c
>> @@ -0,0 +1,42 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + *  EFI application ACPI tables support
>> + *
>> + *  Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
>> + */
>> +
>> +#include <common.h>
>> +#include <efi_loader.h>
>> +#include <asm/acpi_table.h>
>> +
>> +static const efi_guid_t acpi_guid = ACPI_20_TABLE_GUID;
>> +
>> +/*
>> + * Install the ACPI table as a configuration table.
>> + *
>> + * @return	status code
>> + */
>> +efi_status_t efi_acpi_register(void)
>> +{
>> +	/* Map within the low 32 bits, to allow for 32bit ACPI tables */
>> +	u64 acpi = U32_MAX;
>> +	efi_status_t ret;
>> +
>> +	/* Reserve 64kiB page for ACPI */
>> +	ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
>> +				 EFI_RUNTIME_SERVICES_DATA, 16, &acpi);
>> +	if (ret != EFI_SUCCESS)
>> +		return ret;
>> +
>> +	/*
>> +	 * Generate ACPI tables - we know that efi_allocate_pages() returns
>> +	 * a 4k-aligned address, so it is safe to assume that
>> +	 * write_acpi_tables() will write the table at that address.
>> +	 */
>> +	assert(!(acpi & 0xf));
>> +	write_acpi_tables(acpi);
>> +
>> +	/* And expose them to our EFI payload */
>> +	return efi_install_configuration_table(&acpi_guid,
>> +					       (void *)(uintptr_t)acpi);
> The maximum number of configuration tables is currently hard coded as 2
> in efi_boottime.c. I think this limit should be raised. 16 seems
> reasonable looking at which tables the Linux EFI stub or iPXE can process.

How about we just move efi_conf_table from .bss into something 
dynamically allocated? If we wanted to keep things simple, we could even 
just always allocate a full page on the first invocation of 
efi_install_configuration_table() and just check against that size limit 
going forward.


Alex

[U-Boot] [PATCH 5/5] doc: vxworks: Mention chain-loading an x86 kernel via 'bootefi'

[Alexander Graf]

On 06/23/2018 12:03 PM, Bin Meng wrote:
> This updates the doc to mention chain-loading an x86 kernel via
> 'bootefi' command, along with several typos fix.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Reviewed-by: Alexander Graf <agraf@suse.de>


Alex

[U-Boot] [PATCH 4/5] x86: doc: Update EFI loader support

[Alexander Graf]

On 06/23/2018 12:03 PM, Bin Meng wrote:
> CONFIG_EFI_LOADER is fully supported on x86 now.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Reviewed-by: Alexander Graf <agraf@suse.de>


Alex

[U-Boot] [PATCH 2/5] x86: efi_loader: Build EFI memory map per E820 table

[Bin Meng]

Hi Heinrich,

On Sun, Jun 24, 2018 at 5:41 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> On 06/23/2018 12:03 PM, Bin Meng wrote:
>> On x86 traditional E820 table is used to pass the memory information
>> to kernel. With EFI loader we can build the EFI memory map from it.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  arch/x86/lib/e820.c | 39 +++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 39 insertions(+)
>>
>> diff --git a/arch/x86/lib/e820.c b/arch/x86/lib/e820.c
>> index 9a9ec99..8b34f67 100644
>> --- a/arch/x86/lib/e820.c
>> +++ b/arch/x86/lib/e820.c
>> @@ -4,6 +4,7 @@
>>   */
>>
>>  #include <common.h>
>> +#include <efi_loader.h>
>>  #include <asm/e820.h>
>>
>>  DECLARE_GLOBAL_DATA_PTR;
>> @@ -34,3 +35,41 @@ __weak unsigned int install_e820_map(unsigned int max_entries,
>>
>>       return 4;
>>  }
>> +
>> +#if defined(CONFIG_EFI_LOADER) && !defined(CONFIG_SPL_BUILD)
>> +void efi_add_known_memory(void)
>> +{
>> +     struct e820_entry e820[E820MAX];
>> +     unsigned int i, num;
>> +     u64 start, pages;
>> +     int type;
>> +
>> +     num = install_e820_map(ARRAY_SIZE(e820), e820);
>
> Thanks for the patch. Not handling the E820 table is a known deficiency
> of our EFI implementation.
>
> I am a bit worried about error handling here.
>
> What guarantees that lib_sysinfo.n_memranges <= E820MAX?
>

I think you referred to coreboot here? The guarantee comes form the
caller who calls install_e820_map(), which in the coreboot case is 32.
So 32 is the maximum number of E820 table entry it can write.

> install_e820_map() prints a message if max_entries is too small but it
> does not return an error code.
>
> So only if num < E820MAX we can be sure that the call returned all
> information of interest.
>
> My idea is that the interface of efi_add_known_memory() should be
> changed to allow returning an error code if it fails. And
> efi_memory_init() should return an eventual error to board_init_r().
>

Regards,
Bin

[U-Boot] [PATCH 1/5] x86: timer: tsc: Allow specifying clock rate from device tree again

[Bin Meng]

On Sat, Jun 23, 2018 at 10:21 PM, Simon Glass <sjg@chromium.org> wrote:
> On 23 June 2018 at 04:03, Bin Meng <bmeng.cn@gmail.com> wrote:
>> With the introduction of early timer support in the TSC driver,
>> the capability of getting clock rate from device tree was lost
>> unfortunately. Now we bring such functionality back, but with a
>> limitation that when TSC is used as early timer, specifying clock
>> rate from device tree does not work.
>>
>> This fixes random boot failures seen on QEMU targets: printing "TSC
>> frequency is ZERO" and reset forever.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  drivers/timer/tsc_timer.c | 13 +++++++++++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>

applied to u-boot-x86, thanks!