efi_loader: Expose SMBIOS table

We need the checksum function without all the other table functionality soon, so let's split it out into its own header file.

Signed-off-by Alexander Graf <[email protected]>

---
 arch/x86/include/asm/tables.h |  2 ++
 arch/x86/lib/tables.c         | 12 ------------
 include/tables_csum.h         | 22 ++++++++++++++++++++++
 3 files changed, 24 insertions(+), 12 deletions(-)
 create mode 100644 include/tables_csum.h

We will need the SMBIOS generation function on ARM as well going forward, so let's move it into a non arch specific location.

Signed-off-by Alexander Graf <[email protected]>

---
 arch/x86/Kconfig                           | 27 ------------------------
 arch/x86/lib/Makefile                      |  1 -
 arch/x86/lib/tables.c                      |  2 +-
 {arch/x86/include/asm => include}/smbios.h |  0
 lib/Kconfig                                | 33 ++++++++++++++++++++++++++++++
 lib/Makefile                               |  1 +
 {arch/x86/lib => lib}/smbios.c             |  4 ++--
 7 files changed, 37 insertions(+), 31 deletions(-)
 rename {arch/x86/include/asm => include}/smbios.h (100%)
 rename {arch/x86/lib => lib}/smbios.c (99%)

The SMBIOS generation code passes pointers as u32. That causes the compiler to warn on casts to pointers. This patch moves all address pointers to uintptr_t instead.

Technically u32 would be enough for the current SMBIOS2 style tables, but we may want to extend the code to SMBIOS3 in the future which is 64bit address capable.

Signed-off-by Alexander Graf <[email protected]>

---
 arch/x86/lib/tables.c |  7 ++++++-
 include/smbios.h      |  4 ++--
 lib/smbios.c          | 16 ++++++++--------
 3 files changed, 16 insertions(+), 11 deletions(-)

We can pass SMBIOS easily as EFI configuration table to an EFI payload. This patch adds enablement for that case.

While at it, we also enable SMBIOS generation for ARM systems, since they support EFI_LOADER.

Signed-off-by Alexander Graf <[email protected]>

---
 cmd/bootefi.c        |  3 +++
 include/efi_api.h    |  4 ++++
 include/efi_loader.h |  2 ++
 include/smbios.h     |  1 +
 lib/Kconfig          |  4 ++--
 lib/smbios.c         | 36 ++++++++++++++++++++++++++++++++++++
 6 files changed, 48 insertions(+), 2 deletions(-)

cmd/bootefi.c +3 -0

index 53a6ee3..e241b7d 100644
@@ -205,6 +205,9 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt)
        if (!memcmp(bootefi_device_path[0].str, "N\0e\0t", 6))
                loaded_image_info.device_handle = nethandle;
 #endif
+#ifdef CONFIG_GENERATE_SMBIOS_TABLE
+       efi_smbios_register();
+#endif
 

static int smbios_write_type32(uintptr_t *current, int handle) {

cmd/bootefi.c +2 -0

@@ -216,7 +227,9 @@ static smbios_write_type smbios_write_funcs[] = {
        smbios_write_type1,
        smbios_write_type2,
        smbios_write_type3,
+#ifdef CONFIG_X86
        smbios_write_type4,
+#endif
        smbios_write_type32,
        smbios_write_type127
 };

@@ -267,3 +280,26 @@ uintptr_t write_smbios_table(uintptr_t addr)
 

cmd/bootefi.c +6 -0

+       /* Reserve 4kb for SMBIOS */
+       uint64_t pages = 1;
+       int memtype = EFI_RUNTIME_SERVICES_DATA;
+
+       if (efi_allocate_pages(1, memtype, pages, &dmi) != EFI_SUCCESS)
+               return;

We can pass SMBIOS easily as EFI configuration table to an EFI payload. This patch adds enablement for that case.

While at it, we also enable SMBIOS generation for ARM systems, since they support EFI_LOADER.

Signed-off-by Alexander Graf <[email protected]>

---

v1 -> v2:

- fix whitespace

---
 cmd/bootefi.c        |  3 +++
 include/efi_api.h    |  4 ++++
 include/efi_loader.h |  2 ++
 include/smbios.h     |  1 +
 lib/Kconfig          |  4 ++--
 lib/smbios.c         | 36 ++++++++++++++++++++++++++++++++++++
 6 files changed, 48 insertions(+), 2 deletions(-)

We can pass SMBIOS easily as EFI configuration table to an EFI payload. This patch adds enablement for that case.

While at it, we also enable SMBIOS generation for ARM systems, since they support EFI_LOADER.

Signed-off-by Alexander Graf <[email protected]>

---
 cmd/bootefi.c        |  3 +++
 include/efi_api.h    |  4 ++++
 include/efi_loader.h |  2 ++
 include/smbios.h     |  1 +
 lib/Kconfig          |  4 ++--
 lib/smbios.c         | 36 ++++++++++++++++++++++++++++++++++++
 6 files changed, 48 insertions(+), 2 deletions(-)

cmd/bootefi.c +3 -0

index 53a6ee3..e241b7d 100644
@@ -205,6 +205,9 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt)
        if (!memcmp(bootefi_device_path[0].str, "N\0e\0t", 6))
                loaded_image_info.device_handle = nethandle;
 #endif
+#ifdef CONFIG_GENERATE_SMBIOS_TABLE
+       efi_smbios_register();
+#endif
 
        /* Initialize EFI runtime services */
        efi_reset_system_init();

include/efi_api.h +4 -0

index f572b88..bdb600e 100644
@@ -201,6 +201,10 @@ struct efi_runtime_services {
        EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, \
                 0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0)
 
+#define SMBIOS_TABLE_GUID \
+       EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3,  \
+                0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
+
 struct efi_configuration_table
 {
        efi_guid_t guid;

include/efi_loader.h +2 -0

index ac8b77a..b0e8a7f 100644
@@ -85,6 +85,8 @@ int efi_disk_register(void);
 int efi_gop_register(void);
 /* Called by bootefi to make the network interface available */
 int efi_net_register(void **handle);
+/* Called by bootefi to make SMBIOS tables available */
+void efi_smbios_register(void);
 
 /* Called by networking code to memorize the dhcp ack package */
 void efi_net_set_dhcp_ack(void *pkt, int len);

include/smbios.h +1 -0

index 5962d4c..fb6396a 100644
@@ -55,6 +55,7 @@ struct __packed smbios_entry {
 #define BIOS_CHARACTERISTICS_SELECTABLE_BOOT   (1 << 16)
 
 #define BIOS_CHARACTERISTICS_EXT1_ACPI         (1 << 0)
+#define BIOS_CHARACTERISTICS_EXT1_UEFI         (1 << 3)
 #define BIOS_CHARACTERISTICS_EXT2_TARGET       (1 << 2)
 
 struct __packed smbios_type0 {

lib/Kconfig +2 -2

index 5a14530..d7f75fe 100644
@@ -150,12 +150,12 @@ config SPL_OF_LIBFDT
          version of the device tree.
 
 menu "System tables"
-       depends on !EFI && !SYS_COREBOOT
+       depends on (!EFI && !SYS_COREBOOT) || (ARM && EFI_LOADER)
 
 config GENERATE_SMBIOS_TABLE
        bool "Generate an SMBIOS (System Management BIOS) table"
        default y
-       depends on X86
+       depends on X86 || EFI_LOADER
        help
          The System Management BIOS (SMBIOS) specification addresses how
          motherboard and system vendors present management information about

lib/smbios.c +11 -0

index 8dfd486..b9aa741 100644
@@ -7,10 +7,13 @@
  */
 
 #include <common.h>
+#include <efi_loader.h>
 #include <smbios.h>
 #include <tables_csum.h>
 #include <version.h>
+#ifdef CONFIG_X86
 #include <asm/cpu.h>
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 

@@ -79,14 +82,20 @@ static int smbios_write_type0(uintptr_t *current, int handle)
        t->vendor = smbios_add_string(t->eos, "U-Boot");
        t->bios_ver = smbios_add_string(t->eos, PLAIN_VERSION);
        t->bios_release_date = smbios_add_string(t->eos, U_BOOT_DMI_DATE);
+#ifdef CONFIG_ROM_SIZE
        t->bios_rom_size = (CONFIG_ROM_SIZE / 65536) - 1;
+#endif
        t->bios_characteristics = BIOS_CHARACTERISTICS_PCI_SUPPORTED |
                                  BIOS_CHARACTERISTICS_SELECTABLE_BOOT |
                                  BIOS_CHARACTERISTICS_UPGRADEABLE;
 #ifdef CONFIG_GENERATE_ACPI_TABLE
        t->bios_characteristics_ext1 = BIOS_CHARACTERISTICS_EXT1_ACPI;
 #endif
+#ifdef CONFIG_EFI_LOADER
+       t->bios_characteristics_ext1 |= BIOS_CHARACTERISTICS_EXT1_UEFI;
+#endif
        t->bios_characteristics_ext2 = BIOS_CHARACTERISTICS_EXT2_TARGET;
+
        t->bios_major_release = 0xff;
        t->bios_minor_release = 0xff;
        t->ec_major_release = 0xff;

@@ -152,6 +161,7 @@ static int smbios_write_type3(uintptr_t *current, int handle)
        return len;
 }
 
+#ifdef CONFIG_X86
 static int smbios_write_type4(uintptr_t *current, int handle)
 {
        struct smbios_type4 *t = (struct smbios_type4 *)*current;

@@ -184,6 +194,7 @@ static int smbios_write_type4(uintptr_t *current, int handle)
 
        return len;
 }
+#endif
 
 static int smbios_write_type32(uintptr_t *current, int handle)
 {

lib/smbios.c +21 -1

+
+void efi_smbios_register(void)
+{
+       static efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
+       /* Map within the low 32 bits, to allow for 32bit SMBIOS tables */
+        uint64_t dmi = 0xffffffff;
+       /* Reserve 4kb for SMBIOS */
+       uint64_t pages = 1;
+       int memtype = EFI_RUNTIME_SERVICES_DATA;
+
+       if (efi_allocate_pages(1, memtype, pages, &dmi) != EFI_SUCCESS)
+               return;
+
+       /* Generate SMBIOS tables */
+       write_smbios_table(dmi);
+
+       /* And expose them to our EFI payload */
+       efi_install_configuration_table(&smbios_guid, (void*)dmi);
+}
+
+#endif
--

2.6.6

Hi Alex,

Quoted 142 lines · Alexander Graf

We can pass SMBIOS easily as EFI configuration table to an EFI payload. This patch adds enablement for that case.

While at it, we also enable SMBIOS generation for ARM systems, since they support EFI_LOADER.

Signed-off-by Alexander Graf <[email protected]>

---
 cmd/bootefi.c        |  3 +++
 include/efi_api.h    |  4 ++++
 include/efi_loader.h |  2 ++
 include/smbios.h     |  1 +
 lib/Kconfig          |  4 ++--
 lib/smbios.c         | 36 ++++++++++++++++++++++++++++++++++++
 6 files changed, 48 insertions(+), 2 deletions(-)

cmd/bootefi.c +3 -0

index 53a6ee3..e241b7d 100644
@@ -205,6 +205,9 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt)
        if (!memcmp(bootefi_device_path[0].str, "N\0e\0t", 6))
                loaded_image_info.device_handle = nethandle;
 #endif
+#ifdef CONFIG_GENERATE_SMBIOS_TABLE
+       efi_smbios_register();
+#endif
 
        /* Initialize EFI runtime services */
        efi_reset_system_init();

include/efi_api.h +4 -0

index f572b88..bdb600e 100644
@@ -201,6 +201,10 @@ struct efi_runtime_services {
        EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, \
                 0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0)
 
+#define SMBIOS_TABLE_GUID \
+       EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3,  \
+                0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
+
 struct efi_configuration_table
 {
        efi_guid_t guid;

include/efi_loader.h +2 -0

index ac8b77a..b0e8a7f 100644
@@ -85,6 +85,8 @@ int efi_disk_register(void);
 int efi_gop_register(void);
 /* Called by bootefi to make the network interface available */
 int efi_net_register(void **handle);
+/* Called by bootefi to make SMBIOS tables available */
+void efi_smbios_register(void);
 
 /* Called by networking code to memorize the dhcp ack package */
 void efi_net_set_dhcp_ack(void *pkt, int len);

include/smbios.h +1 -0

index 5962d4c..fb6396a 100644
@@ -55,6 +55,7 @@ struct __packed smbios_entry {
 #define BIOS_CHARACTERISTICS_SELECTABLE_BOOT   (1 << 16)
 
 #define BIOS_CHARACTERISTICS_EXT1_ACPI         (1 << 0)
+#define BIOS_CHARACTERISTICS_EXT1_UEFI         (1 << 3)
 #define BIOS_CHARACTERISTICS_EXT2_TARGET       (1 << 2)
 
 struct __packed smbios_type0 {

lib/Kconfig +2 -2

index 5a14530..d7f75fe 100644
@@ -150,12 +150,12 @@ config SPL_OF_LIBFDT
          version of the device tree.
 
 menu "System tables"
-       depends on !EFI && !SYS_COREBOOT
+       depends on (!EFI && !SYS_COREBOOT) || (ARM && EFI_LOADER)
 
 config GENERATE_SMBIOS_TABLE
        bool "Generate an SMBIOS (System Management BIOS) table"
        default y
-       depends on X86
+       depends on X86 || EFI_LOADER
        help
          The System Management BIOS (SMBIOS) specification addresses how
          motherboard and system vendors present management information about

lib/smbios.c +11 -0

index 8dfd486..b9aa741 100644
@@ -7,10 +7,13 @@
  */
 
 #include <common.h>
+#include <efi_loader.h>
 #include <smbios.h>
 #include <tables_csum.h>
 #include <version.h>
+#ifdef CONFIG_X86
 #include <asm/cpu.h>
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 

@@ -79,14 +82,20 @@ static int smbios_write_type0(uintptr_t *current, int handle)
        t->vendor = smbios_add_string(t->eos, "U-Boot");
        t->bios_ver = smbios_add_string(t->eos, PLAIN_VERSION);
        t->bios_release_date = smbios_add_string(t->eos, U_BOOT_DMI_DATE);
+#ifdef CONFIG_ROM_SIZE
        t->bios_rom_size = (CONFIG_ROM_SIZE / 65536) - 1;
+#endif
        t->bios_characteristics = BIOS_CHARACTERISTICS_PCI_SUPPORTED |
                                  BIOS_CHARACTERISTICS_SELECTABLE_BOOT |
                                  BIOS_CHARACTERISTICS_UPGRADEABLE;
 #ifdef CONFIG_GENERATE_ACPI_TABLE
        t->bios_characteristics_ext1 = BIOS_CHARACTERISTICS_EXT1_ACPI;
 #endif
+#ifdef CONFIG_EFI_LOADER
+       t->bios_characteristics_ext1 |= BIOS_CHARACTERISTICS_EXT1_UEFI;
+#endif
        t->bios_characteristics_ext2 = BIOS_CHARACTERISTICS_EXT2_TARGET;
+
        t->bios_major_release = 0xff;
        t->bios_minor_release = 0xff;
        t->ec_major_release = 0xff;

@@ -152,6 +161,7 @@ static int smbios_write_type3(uintptr_t *current, int handle)
        return len;
 }
 
+#ifdef CONFIG_X86
 static int smbios_write_type4(uintptr_t *current, int handle)
 {
        struct smbios_type4 *t = (struct smbios_type4 *)*current;

@@ -184,6 +194,7 @@ static int smbios_write_type4(uintptr_t *current, int handle)
 
        return len;
 }
+#endif
 

lib/smbios.c static smbios_write_type smbios_write_funcs[] = { · line 230

Quoted 7 lines

lib/smbios.c +1 -0

 static int smbios_write_type32(uintptr_t *current, int handle)
 {

@@ -216,7 +227,9 @@ static smbios_write_type smbios_write_funcs[] = {
        smbios_write_type1,
        smbios_write_type2,
        smbios_write_type3,
+#ifdef CONFIG_X86

This should become a parameter I think. Since you are making this into generic code, it should avoid arch-specific #ifdefs.

Quoted 8 lines

lib/smbios.c +1 -0

        smbios_write_type4,
+#endif
        smbios_write_type32,
        smbios_write_type127
 };

@@ -267,3 +280,26 @@ uintptr_t write_smbios_table(uintptr_t addr)
 

lib/smbios.c uintptr_t write_smbios_table(uintptr_t addr) · line 284

Quoted 4 lines

lib/smbios.c +2 -0

        return addr;
 }
+
+#ifdef CONFIG_EFI_LOADER

Can this function go into the efi_loader directory instead?

Quoted 23 lines

lib/smbios.c +21 -1

+
+void efi_smbios_register(void)
+{
+       static efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
+       /* Map within the low 32 bits, to allow for 32bit SMBIOS tables */
+        uint64_t dmi = 0xffffffff;
+       /* Reserve 4kb for SMBIOS */
+       uint64_t pages = 1;
+       int memtype = EFI_RUNTIME_SERVICES_DATA;
+
+       if (efi_allocate_pages(1, memtype, pages, &dmi) != EFI_SUCCESS)
+               return;
+
+       /* Generate SMBIOS tables */
+       write_smbios_table(dmi);
+
+       /* And expose them to our EFI payload */
+       efi_install_configuration_table(&smbios_guid, (void*)dmi);
+}
+
+#endif
--

Quoted 2 lines

2.6.6

Regards,
Simon

Quoted 145 lines · Simon Glass

Hi Alex,

Quoted 142 lines · Alexander Graf

We can pass SMBIOS easily as EFI configuration table to an EFI payload. This patch adds enablement for that case.

While at it, we also enable SMBIOS generation for ARM systems, since they support EFI_LOADER.

Signed-off-by Alexander Graf <[email protected]>

---
 cmd/bootefi.c        |  3 +++
 include/efi_api.h    |  4 ++++
 include/efi_loader.h |  2 ++
 include/smbios.h     |  1 +
 lib/Kconfig          |  4 ++--
 lib/smbios.c         | 36 ++++++++++++++++++++++++++++++++++++
 6 files changed, 48 insertions(+), 2 deletions(-)

cmd/bootefi.c +3 -0

index 53a6ee3..e241b7d 100644
@@ -205,6 +205,9 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt)
        if (!memcmp(bootefi_device_path[0].str, "N\0e\0t", 6))
                loaded_image_info.device_handle = nethandle;
 #endif
+#ifdef CONFIG_GENERATE_SMBIOS_TABLE
+       efi_smbios_register();
+#endif
 
        /* Initialize EFI runtime services */
        efi_reset_system_init();

include/efi_api.h +4 -0

index f572b88..bdb600e 100644
@@ -201,6 +201,10 @@ struct efi_runtime_services {
        EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, \
                 0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0)
 
+#define SMBIOS_TABLE_GUID \
+       EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3,  \
+                0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
+
 struct efi_configuration_table
 {
        efi_guid_t guid;

include/efi_loader.h +2 -0

index ac8b77a..b0e8a7f 100644
@@ -85,6 +85,8 @@ int efi_disk_register(void);
 int efi_gop_register(void);
 /* Called by bootefi to make the network interface available */
 int efi_net_register(void **handle);
+/* Called by bootefi to make SMBIOS tables available */
+void efi_smbios_register(void);
 
 /* Called by networking code to memorize the dhcp ack package */
 void efi_net_set_dhcp_ack(void *pkt, int len);

include/smbios.h +1 -0

index 5962d4c..fb6396a 100644
@@ -55,6 +55,7 @@ struct __packed smbios_entry {
 #define BIOS_CHARACTERISTICS_SELECTABLE_BOOT   (1 << 16)
 
 #define BIOS_CHARACTERISTICS_EXT1_ACPI         (1 << 0)
+#define BIOS_CHARACTERISTICS_EXT1_UEFI         (1 << 3)
 #define BIOS_CHARACTERISTICS_EXT2_TARGET       (1 << 2)
 
 struct __packed smbios_type0 {

lib/Kconfig +2 -2

index 5a14530..d7f75fe 100644
@@ -150,12 +150,12 @@ config SPL_OF_LIBFDT
          version of the device tree.
 
 menu "System tables"
-       depends on !EFI && !SYS_COREBOOT
+       depends on (!EFI && !SYS_COREBOOT) || (ARM && EFI_LOADER)
 
 config GENERATE_SMBIOS_TABLE
        bool "Generate an SMBIOS (System Management BIOS) table"
        default y
-       depends on X86
+       depends on X86 || EFI_LOADER
        help
          The System Management BIOS (SMBIOS) specification addresses how
          motherboard and system vendors present management information about

lib/smbios.c +11 -0

index 8dfd486..b9aa741 100644
@@ -7,10 +7,13 @@
  */
 
 #include <common.h>
+#include <efi_loader.h>
 #include <smbios.h>
 #include <tables_csum.h>
 #include <version.h>
+#ifdef CONFIG_X86
 #include <asm/cpu.h>
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 

@@ -79,14 +82,20 @@ static int smbios_write_type0(uintptr_t *current, int handle)
        t->vendor = smbios_add_string(t->eos, "U-Boot");
        t->bios_ver = smbios_add_string(t->eos, PLAIN_VERSION);
        t->bios_release_date = smbios_add_string(t->eos, U_BOOT_DMI_DATE);
+#ifdef CONFIG_ROM_SIZE
        t->bios_rom_size = (CONFIG_ROM_SIZE / 65536) - 1;
+#endif
        t->bios_characteristics = BIOS_CHARACTERISTICS_PCI_SUPPORTED |
                                  BIOS_CHARACTERISTICS_SELECTABLE_BOOT |
                                  BIOS_CHARACTERISTICS_UPGRADEABLE;
 #ifdef CONFIG_GENERATE_ACPI_TABLE
        t->bios_characteristics_ext1 = BIOS_CHARACTERISTICS_EXT1_ACPI;
 #endif
+#ifdef CONFIG_EFI_LOADER
+       t->bios_characteristics_ext1 |= BIOS_CHARACTERISTICS_EXT1_UEFI;
+#endif
        t->bios_characteristics_ext2 = BIOS_CHARACTERISTICS_EXT2_TARGET;
+
        t->bios_major_release = 0xff;
        t->bios_minor_release = 0xff;
        t->ec_major_release = 0xff;

@@ -152,6 +161,7 @@ static int smbios_write_type3(uintptr_t *current, int handle)
        return len;
 }
 
+#ifdef CONFIG_X86
 static int smbios_write_type4(uintptr_t *current, int handle)
 {
        struct smbios_type4 *t = (struct smbios_type4 *)*current;

@@ -184,6 +194,7 @@ static int smbios_write_type4(uintptr_t *current, int handle)
 
        return len;
 }
+#endif
 

Quoted 10 lines

lib/smbios.c static smbios_write_type smbios_write_funcs[] = { · line 230

Quoted 7 lines

lib/smbios.c +1 -0

 static int smbios_write_type32(uintptr_t *current, int handle)
 {

@@ -216,7 +227,9 @@ static smbios_write_type smbios_write_funcs[] = {
        smbios_write_type1,
        smbios_write_type2,
        smbios_write_type3,
+#ifdef CONFIG_X86

This should become a parameter I think. Since you are making this into generic code, it should avoid arch-specific #ifdefs.

The type4 table really contains x86 cpu specific information, so I figured an #ifdef CONFIG_X86 makes the most sense here.

Looking at

https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.0.0.pdf

I guess you *could* put one in that addresses ARM as well. Looking at example output from a ThunderX system, that seems to be what other vendors do:

Handle 0x0004, DMI type 4, 48 bytes
Processor Information
Socket Designation: CPU 0
Type: Central Processor
Family: Other
Manufacturer: www.cavium.com
ID: 00 00 00 00 00 00 00 00
Version: 2.0
Voltage: 3.3 V
External Clock: 156 MHz
Max Speed: 2000 MHz
Current Speed: 2000 MHz
Status: Populated, Enabled
Upgrade: Other
L1 Cache Handle: 0x0080
L2 Cache Handle: 0x0082
L3 Cache Handle: 0x0007
Serial Number: 1.0
Asset Tag: 1.0
Part Number: [...]
Core Count: 48
Core Enabled: 48
Thread Count: 1
Characteristics: None

So what we really need is a rename for smbios_write_type4 to smbios_write_type4_x86 which then is still surrounded by the #ifdef CONFIG_X86. We could just simply add another one for arm if we want to ;).

Quoted 9 lines

Quoted 9 lines

lib/smbios.c +1 -0

        smbios_write_type4,
+#endif
        smbios_write_type32,
        smbios_write_type127
 };

@@ -267,3 +280,26 @@ uintptr_t write_smbios_table(uintptr_t addr)
 

Quoted 6 lines

lib/smbios.c uintptr_t write_smbios_table(uintptr_t addr) · line 284

Quoted 4 lines

lib/smbios.c +2 -0

        return addr;
 }
+
+#ifdef CONFIG_EFI_LOADER

Can this function go into the efi_loader directory instead?

I guess we could have a small file in the efi_loader directory that bridges the gap between the smbios lib and the generation, yeah.

Alex

Hi Alex,

Quoted 193 lines · Alexander Graf

Quoted 145 lines · Simon Glass

Hi Alex,

Quoted 142 lines · Alexander Graf

We can pass SMBIOS easily as EFI configuration table to an EFI payload. This patch adds enablement for that case.

While at it, we also enable SMBIOS generation for ARM systems, since they support EFI_LOADER.

Signed-off-by Alexander Graf <[email protected]>

---
  cmd/bootefi.c        |  3 +++
  include/efi_api.h    |  4 ++++
  include/efi_loader.h |  2 ++
  include/smbios.h     |  1 +
  lib/Kconfig          |  4 ++--
  lib/smbios.c         | 36 ++++++++++++++++++++++++++++++++++++
  6 files changed, 48 insertions(+), 2 deletions(-)

cmd/bootefi.c +3 -0

index 53a6ee3..e241b7d 100644
@@ -205,6 +205,9 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt)
         if (!memcmp(bootefi_device_path[0].str, "N\0e\0t", 6))
                 loaded_image_info.device_handle = nethandle;
  #endif
+#ifdef CONFIG_GENERATE_SMBIOS_TABLE
+       efi_smbios_register();
+#endif
 
         /* Initialize EFI runtime services */
         efi_reset_system_init();

include/efi_api.h +4 -0

index f572b88..bdb600e 100644
@@ -201,6 +201,10 @@ struct efi_runtime_services {
         EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, \
                  0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0)
 
+#define SMBIOS_TABLE_GUID \
+       EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3,  \
+                0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
+
  struct efi_configuration_table
  {
         efi_guid_t guid;

include/efi_loader.h +2 -0

index ac8b77a..b0e8a7f 100644
@@ -85,6 +85,8 @@ int efi_disk_register(void);
  int efi_gop_register(void);
  /* Called by bootefi to make the network interface available */
  int efi_net_register(void **handle);
+/* Called by bootefi to make SMBIOS tables available */
+void efi_smbios_register(void);
 
  /* Called by networking code to memorize the dhcp ack package */
  void efi_net_set_dhcp_ack(void *pkt, int len);

include/smbios.h +1 -0

index 5962d4c..fb6396a 100644
@@ -55,6 +55,7 @@ struct __packed smbios_entry {
  #define BIOS_CHARACTERISTICS_SELECTABLE_BOOT   (1 << 16)
 
  #define BIOS_CHARACTERISTICS_EXT1_ACPI         (1 << 0)
+#define BIOS_CHARACTERISTICS_EXT1_UEFI         (1 << 3)
  #define BIOS_CHARACTERISTICS_EXT2_TARGET       (1 << 2)
 
  struct __packed smbios_type0 {

lib/Kconfig +2 -2

index 5a14530..d7f75fe 100644
@@ -150,12 +150,12 @@ config SPL_OF_LIBFDT
           version of the device tree.
 
  menu "System tables"
-       depends on !EFI && !SYS_COREBOOT
+       depends on (!EFI && !SYS_COREBOOT) || (ARM && EFI_LOADER)
 
  config GENERATE_SMBIOS_TABLE
         bool "Generate an SMBIOS (System Management BIOS) table"
         default y
-       depends on X86
+       depends on X86 || EFI_LOADER
         help
           The System Management BIOS (SMBIOS) specification addresses how
           motherboard and system vendors present management information about

lib/smbios.c +11 -0

index 8dfd486..b9aa741 100644
@@ -7,10 +7,13 @@
   */
 
  #include <common.h>
+#include <efi_loader.h>
  #include <smbios.h>
  #include <tables_csum.h>
  #include <version.h>
+#ifdef CONFIG_X86
  #include <asm/cpu.h>
+#endif
 
  DECLARE_GLOBAL_DATA_PTR;
 

@@ -79,14 +82,20 @@ static int smbios_write_type0(uintptr_t *current, int handle)
         t->vendor = smbios_add_string(t->eos, "U-Boot");
         t->bios_ver = smbios_add_string(t->eos, PLAIN_VERSION);
         t->bios_release_date = smbios_add_string(t->eos, U_BOOT_DMI_DATE);
+#ifdef CONFIG_ROM_SIZE
         t->bios_rom_size = (CONFIG_ROM_SIZE / 65536) - 1;
+#endif
         t->bios_characteristics = BIOS_CHARACTERISTICS_PCI_SUPPORTED |
                                   BIOS_CHARACTERISTICS_SELECTABLE_BOOT |
                                   BIOS_CHARACTERISTICS_UPGRADEABLE;
  #ifdef CONFIG_GENERATE_ACPI_TABLE
         t->bios_characteristics_ext1 = BIOS_CHARACTERISTICS_EXT1_ACPI;
  #endif
+#ifdef CONFIG_EFI_LOADER
+       t->bios_characteristics_ext1 |= BIOS_CHARACTERISTICS_EXT1_UEFI;
+#endif
         t->bios_characteristics_ext2 = BIOS_CHARACTERISTICS_EXT2_TARGET;
+
         t->bios_major_release = 0xff;
         t->bios_minor_release = 0xff;
         t->ec_major_release = 0xff;

@@ -152,6 +161,7 @@ static int smbios_write_type3(uintptr_t *current, int handle)
         return len;
  }
 
+#ifdef CONFIG_X86
  static int smbios_write_type4(uintptr_t *current, int handle)
  {
         struct smbios_type4 *t = (struct smbios_type4 *)*current;

@@ -184,6 +194,7 @@ static int smbios_write_type4(uintptr_t *current, int handle)
 
         return len;
  }
+#endif
 

Quoted 9 lines

lib/smbios.c static smbios_write_type smbios_write_funcs[] = { · line 230

Quoted 7 lines

lib/smbios.c +1 -0

  static int smbios_write_type32(uintptr_t *current, int handle)
  {

@@ -216,7 +227,9 @@ static smbios_write_type smbios_write_funcs[] = {
         smbios_write_type1,
         smbios_write_type2,
         smbios_write_type3,
+#ifdef CONFIG_X86

This should become a parameter I think. Since you are making this into generic code, it should avoid arch-specific #ifdefs.

The type4 table really contains x86 cpu specific information, so I figured an #ifdef CONFIG_X86 makes the most sense here.

Looking at

https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.0.0.pdf

I guess you *could* put one in that addresses ARM as well. Looking at example output from a ThunderX system, that seems to be what other vendors do:

Handle 0x0004, DMI type 4, 48 bytes
Processor Information
Socket Designation: CPU 0
Type: Central Processor
Family: Other
Manufacturer: www.cavium.com
ID: 00 00 00 00 00 00 00 00
Version: 2.0
Voltage: 3.3 V
External Clock: 156 MHz
Max Speed: 2000 MHz
Current Speed: 2000 MHz
Status: Populated, Enabled
Upgrade: Other
L1 Cache Handle: 0x0080
L2 Cache Handle: 0x0082
L3 Cache Handle: 0x0007
Serial Number: 1.0
Asset Tag: 1.0
Part Number: [...]
Core Count: 48
Core Enabled: 48
Thread Count: 1
Characteristics: None

Quoted 3 lines

So what we really need is a rename for smbios_write_type4 to smbios_write_type4_x86 which then is still surrounded by the #ifdef CONFIG_X86. We could just simply add another one for arm if we want to ;).

From what I can see, the problem is the cpu_get_name() call. Is that
right? If so, that could move to the CPU uclass and use cpu_get_info() (with the name added as a new field) or perhaps a new cpu_get_name() call.

Quoted 219 lines · Simon Glass

Hi Alex,

Quoted 210 lines · Alexander Graf

Quoted 158 lines · Simon Glass

Hi Alex,

Quoted 154 lines · Alexander Graf

We can pass SMBIOS easily as EFI configuration table to an EFI payload. This
patch adds enablement for that case.

While at it, we also enable SMBIOS generation for ARM systems, since they support
EFI_LOADER.

Signed-off-by Alexander Graf <[email protected]>

---
  cmd/bootefi.c        |  3 +++
  include/efi_api.h    |  4 ++++
  include/efi_loader.h |  2 ++
  include/smbios.h     |  1 +
  lib/Kconfig          |  4 ++--
  lib/smbios.c         | 36 ++++++++++++++++++++++++++++++++++++
  6 files changed, 48 insertions(+), 2 deletions(-)

cmd/bootefi.c +3 -0

index 53a6ee3..e241b7d 100644
@@ -205,6 +205,9 @@ static unsigned long do_bootefi_exec(void *efi,
 void *fdt)
         if (!memcmp(bootefi_device_path[0].str, "N\0e\0t", 6))
                 loaded_image_info.device_handle = nethandle;
  #endif
+#ifdef CONFIG_GENERATE_SMBIOS_TABLE
+       efi_smbios_register();
+#endif
 
         /* Initialize EFI runtime services */

         efi_reset_system_init();

include/efi_api.h +4 -0

index f572b88..bdb600e 100644
@@ -201,6 +201,10 @@ struct efi_runtime_services {
         EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, \
                  0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0)
 
+#define SMBIOS_TABLE_GUID \
+       EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3,  \
+                0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
+
  struct efi_configuration_table
  {
         efi_guid_t guid;

include/efi_loader.h +2 -0

index ac8b77a..b0e8a7f 100644
@@ -85,6 +85,8 @@ int efi_disk_register(void);
  int efi_gop_register(void);
  /* Called by bootefi to make the network interface available */
  int efi_net_register(void **handle);
+/* Called by bootefi to make SMBIOS tables available */
+void efi_smbios_register(void);
 
  /* Called by networking code to memorize the dhcp ack package */
  void efi_net_set_dhcp_ack(void *pkt, int len);

include/smbios.h +1 -0

index 5962d4c..fb6396a 100644
@@ -55,6 +55,7 @@ struct __packed smbios_entry {
  #define BIOS_CHARACTERISTICS_SELECTABLE_BOOT   (1 << 16)
 
  #define BIOS_CHARACTERISTICS_EXT1_ACPI         (1 << 0)
+#define BIOS_CHARACTERISTICS_EXT1_UEFI         (1 << 3)
  #define BIOS_CHARACTERISTICS_EXT2_TARGET       (1 << 2)
 
  struct __packed smbios_type0 {

lib/Kconfig +2 -2

index 5a14530..d7f75fe 100644
@@ -150,12 +150,12 @@ config SPL_OF_LIBFDT
           version of the device tree.
 
  menu "System tables"
-       depends on !EFI && !SYS_COREBOOT
+       depends on (!EFI && !SYS_COREBOOT) || (ARM && EFI_LOADER)
 
  config GENERATE_SMBIOS_TABLE
         bool "Generate an SMBIOS (System Management BIOS) table"
         default y
-       depends on X86
+       depends on X86 || EFI_LOADER
         help
           The System Management BIOS (SMBIOS) specification addresses

how
motherboard and system vendors present management
information about

lib/smbios.c +5 -0

index 8dfd486..b9aa741 100644
@@ -7,10 +7,13 @@
   */
 
  #include <common.h>
+#include <efi_loader.h>
  #include <smbios.h>
  #include <tables_csum.h>
  #include <version.h>
+#ifdef CONFIG_X86
  #include <asm/cpu.h>
+#endif
 
  DECLARE_GLOBAL_DATA_PTR;
 

@@ -79,14 +82,20 @@ static int smbios_write_type0(uintptr_t *current,
 int handle)
         t->vendor = smbios_add_string(t->eos, "U-Boot");
         t->bios_ver = smbios_add_string(t->eos, PLAIN_VERSION);
         t->bios_release_date = smbios_add_string(t->eos,
 U_BOOT_DMI_DATE);
+#ifdef CONFIG_ROM_SIZE
         t->bios_rom_size = (CONFIG_ROM_SIZE / 65536) - 1;
+#endif
         t->bios_characteristics = BIOS_CHARACTERISTICS_PCI_SUPPORTED |
                                   BIOS_CHARACTERISTICS_SELECTABLE_BOOT

|

                                   BIOS_CHARACTERISTICS_UPGRADEABLE;
  #ifdef CONFIG_GENERATE_ACPI_TABLE
         t->bios_characteristics_ext1 = BIOS_CHARACTERISTICS_EXT1_ACPI;

#endif

lib/smbios.c +3 -0

+#ifdef CONFIG_EFI_LOADER
+       t->bios_characteristics_ext1 |= BIOS_CHARACTERISTICS_EXT1_UEFI;
+#endif
         t->bios_characteristics_ext2 =

BIOS_CHARACTERISTICS_EXT2_TARGET;

lib/smbios.c +2 -0

+
         t->bios_major_release = 0xff;
         t->bios_minor_release = 0xff;
         t->ec_major_release = 0xff;

@@ -152,6 +161,7 @@ static int smbios_write_type3(uintptr_t *current,
 int handle)
         return len;
  }
 
+#ifdef CONFIG_X86
  static int smbios_write_type4(uintptr_t *current, int handle)
  {

         struct smbios_type4 *t = (struct smbios_type4 *)*current;

lib/smbios.c +1 -0

@@ -184,6 +194,7 @@ static int smbios_write_type4(uintptr_t *current,
 int handle)
 
         return len;
  }
+#endif
 

Quoted 10 lines

lib/smbios.c static smbios_write_type smbios_write_funcs[] = { · line 230

Quoted 7 lines

lib/smbios.c +0 -0

  static int smbios_write_type32(uintptr_t *current, int handle)

  {

lib/smbios.c +1 -0

@@ -216,7 +227,9 @@ static smbios_write_type smbios_write_funcs[] = {
         smbios_write_type1,
         smbios_write_type2,
         smbios_write_type3,
+#ifdef CONFIG_X86

This should become a parameter I think. Since you are making this into generic code, it should avoid arch-specific #ifdefs.

The type4 table really contains x86 cpu specific information, so I figured an #ifdef CONFIG_X86 makes the most sense here.

Looking at

https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.0.0.pdf

I guess you *could* put one in that addresses ARM as well. Looking at example output from a ThunderX system, that seems to be what other vendors do:

Handle 0x0004, DMI type 4, 48 bytes
Processor Information
Socket Designation: CPU 0
Type: Central Processor
Family: Other
Manufacturer: www.cavium.com
ID: 00 00 00 00 00 00 00 00
Version: 2.0
Voltage: 3.3 V
External Clock: 156 MHz
Max Speed: 2000 MHz
Current Speed: 2000 MHz
Status: Populated, Enabled
Upgrade: Other
L1 Cache Handle: 0x0080
L2 Cache Handle: 0x0082
L3 Cache Handle: 0x0007
Serial Number: 1.0
Asset Tag: 1.0
Part Number: [...]
Core Count: 48
Core Enabled: 48
Thread Count: 1
Characteristics: None

Quoted 4 lines

So what we really need is a rename for smbios_write_type4 to smbios_write_type4_x86 which then is still surrounded by the #ifdef CONFIG_X86. We could just simply add another one for arm if we want to ;).

Quoted 4 lines

From what I can see, the problem is the cpu_get_name() call. Is that
right? If so, that could move to the CPU uclass and use cpu_get_info() (with the name added as a new field) or perhaps a new cpu_get_name() call.

I see what you're aiming for, but I just fail to see how we could properly abstract away CPU specific information - and I don't think it's terribly useful either. I've refactored the code to be slightly more pretty now, but I really don't think that we should depend on CONFIG_CPU or introduce new

calls for every bit:

static void smbios_write_type4_arch(struct smbios_type4 *t)

{
        u16 processor_family = SMBIOS_PROCESSOR_FAMILY_UNKNOWN;
        const char *vendor = "Unknown";
        char *name = "Unknown";

#ifdef CONFIG_X86
        char processor_name[CPU_MAX_NAME_LEN];
        struct cpuid_result res;

        processor_family = gd->arch.x86;
        vendor = cpu_vendor_name(gd->arch.x86_vendor);
        res = cpuid(1);
        t->processor_id[0] = res.eax;
        t->processor_id[1] = res.edx;
        name = cpu_get_name(processor_name);
#elif defined(CONFIG_ARM)
        processor_family = SMBIOS_PROCESSOR_FAMILY_OTHER;
        vendor = "ARM";

#endif

        t->processor_family = processor_family;
        t->processor_manufacturer = smbios_add_string(t->eos, vendor);
        t->processor_version = smbios_add_string(t->eos, name);
}

Alex

If the system has a valid "serial#" environment variable set (which boards that can find it out programatically set automatically), use that as input for the serial number field in the SMBIOS tables.

Signed-off-by Alexander Graf <[email protected]>

---
 lib/smbios.c | 3 +++
 1 file changed, 3 insertions(+)

If the system has a valid "serial#" environment variable set (which boards that can find it out programatically set automatically), use that as input for the serial number and UUID fields in the SMBIOS tables.

Signed-off-by Alexander Graf <[email protected]>

---

v1 -> v2:

- Also populate UUID

---
 lib/smbios.c | 5 +++++
 1 file changed, 5 insertions(+)

Quoted 10 lines · Alexander Graf

If the system has a valid "serial#" environment variable set (which boards that can find it out programatically set automatically), use that as input for the serial number and UUID fields in the SMBIOS tables.

Signed-off-by Alexander Graf <[email protected]>

---

v1 -> v2:

Quoted 5 lines

- Also populate UUID

---
 lib/smbios.c | 5 +++++
 1 file changed, 5 insertions(+)

Reviewed-by Bin Meng <[email protected]>

We generate a few tables on x86 today that really can be used on ARM just the same. One such example is the SMBIOS table, which people use with tools like "dmidecode" to identify which hardware they are running on.

We're slowly growing needs to collect serial numbers from various devices on ARM and SMBIOS seems the natural choice. So this patch set moves the current SMBIOS generation into generic code and adds serial number exposure to it.

I have verified that I get a correct serial number printed in dmidecode on the RPi3.

Alexander Graf (7):
x86: Move table csum into separate header
x86: Move smbios generation into arch independent directory
efi_loader: Expose efi_install_configuration_table
smbios: Allow compilation on 64bit systems
smbios: Expose in efi_loader as table
efi_loader: Fix efi_install_configuration_table
smbios: Provide serial number

 arch/x86/Kconfig                           | 27 --------------
 arch/x86/include/asm/tables.h              |  2 +
 arch/x86/lib/Makefile                      |  1 -
 arch/x86/lib/tables.c                      | 21 ++++-------
 cmd/bootefi.c                              |  3 ++
 include/efi_api.h                          |  4 ++
 include/efi_loader.h                       |  4 ++
 {arch/x86/include/asm => include}/smbios.h |  5 ++-
 include/tables_csum.h                      | 22 +++++++++++
 lib/Kconfig                                | 33 +++++++++++++++++
 lib/Makefile                               |  1 +
 lib/efi_loader/efi_boottime.c              | 24 +++++++-----
 {arch/x86/lib => lib}/smbios.c             | 59 +++++++++++++++++++++++++-----
 13 files changed, 142 insertions(+), 64 deletions(-)
 rename {arch/x86/include/asm => include}/smbios.h (96%)
 create mode 100644 include/tables_csum.h
 rename {arch/x86/lib => lib}/smbios.c (82%)

--
2.6.6

Hi Alexander,

Quoted 4 lines · Alexander Graf

We generate a few tables on x86 today that really can be used on ARM just the same. One such example is the SMBIOS table, which people use with tools like "dmidecode" to identify which hardware they are running on.

Quoted 4 lines

We're slowly growing needs to collect serial numbers from various devices on ARM and SMBIOS seems the natural choice. So this patch set moves the current SMBIOS generation into generic code and adds serial number exposure to it.

Shouldn't we use device tree? Why would an ARM device use SMBIOS?

Am 08.08.2016 um 23:44 schrieb Simon Glass <[email protected]>:

Hi Alexander,

Quoted 5 lines · Alexander Graf

We generate a few tables on x86 today that really can be used on ARM just the same. One such example is the SMBIOS table, which people use with tools like "dmidecode" to identify which hardware they are running on.

Quoted 4 lines

We're slowly growing needs to collect serial numbers from various devices on ARM and SMBIOS seems the natural choice. So this patch set moves the current SMBIOS generation into generic code and adds serial number exposure to it.

Shouldn't we use device tree? Why would an ARM device use SMBIOS?

Quoted 16 lines

Am 08.08.2016 um 23:44 schrieb Simon Glass <[email protected]>:

Hi Alexander,

Quoted 9 lines · Alexander Graf

We generate a few tables on x86 today that really can be used on ARM just the same. One such example is the SMBIOS table, which people use with tools like "dmidecode" to identify which hardware they are running on.

We're slowly growing needs to collect serial numbers from various devices on ARM and SMBIOS seems the natural choice. So this patch set moves the current SMBIOS generation into generic code and adds serial number exposure to it.

Quoted 1 line

Shouldn't we use device tree? Why would an ARM device use SMBIOS?

Mostly because SBBR dictates it and every ARM server platform out there provides SMBIOS tables ;).

Also, both describe very different things. At least I have never seen things like "The chassy of this server has 2 power connectors and is blue" in device tree.

Hi Alexander,

Quoted 14 lines · Alexander Graf

Quoted 14 lines

Am 08.08.2016 um 23:44 schrieb Simon Glass <[email protected]>:

Hi Alexander,

Quoted 9 lines · Alexander Graf

We generate a few tables on x86 today that really can be used on ARM just the same. One such example is the SMBIOS table, which people use with tools like "dmidecode" to identify which hardware they are running on.

We're slowly growing needs to collect serial numbers from various devices on ARM and SMBIOS seems the natural choice. So this patch set moves the current SMBIOS generation into generic code and adds serial number exposure to it.

Quoted 4 lines

Quoted 1 line

Shouldn't we use device tree? Why would an ARM device use SMBIOS?

Mostly because SBBR dictates it and every ARM server platform out there provides SMBIOS tables ;).

Also, both describe very different things. At least I have never seen things like "The chassy of this server has 2 power connectors and is blue" in device tree.

So there is no DT binding for this information? Does this mean that U-Boot on ARM needs to pass information through just 'sitting in RAM somewhere' like x86?

Quoted 24 lines · Simon Glass

Hi Alexander,

Quoted 20 lines · Alexander Graf

Quoted 11 lines

Am 08.08.2016 um 23:44 schrieb Simon Glass <[email protected]>:

Hi Alexander,

Quoted 5 lines · Alexander Graf

We generate a few tables on x86 today that really can be used on ARM just the same. One such example is the SMBIOS table, which people use with tools like "dmidecode" to identify which hardware they are running on.

Quoted 6 lines

Quoted 4 lines

We're slowly growing needs to collect serial numbers from various devices on ARM and SMBIOS seems the natural choice. So this patch set moves the current SMBIOS generation into generic code and adds serial number exposure to it.

Shouldn't we use device tree? Why would an ARM device use SMBIOS?

Mostly because SBBR dictates it and every ARM server platform out there provides SMBIOS tables ;).

Quoted 5 lines

Quoted 1 line

Also, both describe very different things. At least I have never seen things like "The chassy of this server has 2 power connectors and is blue" in device tree.

So there is no DT binding for this information? Does this mean that U-Boot on ARM needs to pass information through just 'sitting in RAM somewhere' like x86?

I don't think there's a non-EFI way on ARM to pass this through at all, correct. That's nothing new though - things like KASLR also depend on EFI.

Hi Alexander,

Quoted 26 lines · Alexander Graf

Quoted 24 lines · Simon Glass

Hi Alexander,

Quoted 20 lines · Alexander Graf

Quoted 11 lines

Am 08.08.2016 um 23:44 schrieb Simon Glass <[email protected]>:

Hi Alexander,

Quoted 5 lines · Alexander Graf

We generate a few tables on x86 today that really can be used on ARM just the same. One such example is the SMBIOS table, which people use with tools like "dmidecode" to identify which hardware they are running on.

Quoted 6 lines

Quoted 4 lines

We're slowly growing needs to collect serial numbers from various devices on ARM and SMBIOS seems the natural choice. So this patch set moves the current SMBIOS generation into generic code and adds serial number exposure to it.

Shouldn't we use device tree? Why would an ARM device use SMBIOS?

Mostly because SBBR dictates it and every ARM server platform out there provides SMBIOS tables ;).

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

Also, both describe very different things. At least I have never seen things like "The chassy of this server has 2 power connectors and is blue" in device tree.

So there is no DT binding for this information? Does this mean that U-Boot on ARM needs to pass information through just 'sitting in RAM somewhere' like x86?

I don't think there's a non-EFI way on ARM to pass this through at all, correct. That's nothing new though - things like KASLR also depend on EFI.

That feels like it could just be done in U-Boot. The proliferation of bootloader stuff in Linux bugs me. It's the lowest-common-denominator problem. To me it seems that UEFI and U-Boot should implement these features, and then Linux doesn't need to.

Anyway I do understand where you are going. Is it possible to provide EFI tables to Linux but not EFI boot/run-time services?

Quoted 46 lines · Simon Glass

Hi Alexander,

Quoted 26 lines · Alexander Graf

Quoted 24 lines · Simon Glass

Hi Alexander,

Quoted 20 lines · Alexander Graf

Quoted 11 lines

Am 08.08.2016 um 23:44 schrieb Simon Glass <[email protected]>:

Hi Alexander,

Quoted 5 lines · Alexander Graf

We generate a few tables on x86 today that really can be used on ARM just the same. One such example is the SMBIOS table, which people use with tools like "dmidecode" to identify which hardware they are running on.

Quoted 6 lines

Quoted 4 lines

We're slowly growing needs to collect serial numbers from various devices on ARM and SMBIOS seems the natural choice. So this patch set moves the current SMBIOS generation into generic code and adds serial number exposure to it.

Shouldn't we use device tree? Why would an ARM device use SMBIOS?

Mostly because SBBR dictates it and every ARM server platform out there provides SMBIOS tables ;).

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

Also, both describe very different things. At least I have never seen things like "The chassy of this server has 2 power connectors and is blue" in device tree.

So there is no DT binding for this information? Does this mean that U-Boot on ARM needs to pass information through just 'sitting in RAM somewhere' like x86?

I don't think there's a non-EFI way on ARM to pass this through at all, correct. That's nothing new though - things like KASLR also depend on EFI.

That feels like it could just be done in U-Boot. The proliferation of bootloader stuff in Linux bugs me. It's the lowest-common-denominator problem. To me it seems that UEFI and U-Boot should implement these features, and then Linux doesn't need to.

Quoted 2 lines

Anyway I do understand where you are going. Is it possible to provide EFI tables to Linux but not EFI boot/run-time services?

I?m not aware of any way to do that today unfortunately. I don?t see why you couldn?t add a device tree property that points to random memory locations for tables though.

As a more fundamental question though, will we really care about the non-EFI boot path 5 or 10 years from now? It doesn?t add much complexity and allows for less divergence between classic embedded and server systems. Since Linux itself is a uEFI binary, you can simply replace ?booti? with ?bootefi? in most boot cases and shouldn?t even see much of a difference.

I don?t think that the non-EFI boot path will disappear, but turns more and more into a second class citizen because a lot of work is happening in the server space which requires EFI.

But yes, please be my guest and suggest device tree properties to the Linux device tree list that allow exposure of tables (I?m not sure whether anything beyond SMBIOS makes sense for a dt based system) to Linux on non-EFI boot.

Hi Alex,

Quoted 46 lines · Alexander Graf

Quoted 46 lines · Simon Glass

Hi Alexander,

Quoted 26 lines · Alexander Graf

Quoted 24 lines · Simon Glass

Hi Alexander,

Quoted 20 lines · Alexander Graf

Quoted 11 lines

Am 08.08.2016 um 23:44 schrieb Simon Glass <[email protected]>:

Hi Alexander,

Quoted 5 lines · Alexander Graf

We generate a few tables on x86 today that really can be used on ARM just the same. One such example is the SMBIOS table, which people use with tools like "dmidecode" to identify which hardware they are running on.

Quoted 6 lines

Quoted 4 lines

We're slowly growing needs to collect serial numbers from various devices on ARM and SMBIOS seems the natural choice. So this patch set moves the current SMBIOS generation into generic code and adds serial number exposure to it.

Shouldn't we use device tree? Why would an ARM device use SMBIOS?

Mostly because SBBR dictates it and every ARM server platform out there provides SMBIOS tables ;).

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

Also, both describe very different things. At least I have never seen things like "The chassy of this server has 2 power connectors and is blue" in device tree.

So there is no DT binding for this information? Does this mean that U-Boot on ARM needs to pass information through just 'sitting in RAM somewhere' like x86?

I don't think there's a non-EFI way on ARM to pass this through at all, correct. That's nothing new though - things like KASLR also depend on EFI.

That feels like it could just be done in U-Boot. The proliferation of bootloader stuff in Linux bugs me. It's the lowest-common-denominator problem. To me it seems that UEFI and U-Boot should implement these features, and then Linux doesn't need to.

Quoted 4 lines

Quoted 2 lines

Anyway I do understand where you are going. Is it possible to provide EFI tables to Linux but not EFI boot/run-time services?

I?m not aware of any way to do that today unfortunately. I don?t see why you couldn?t add a device tree property that points to random memory locations for tables though.

I was more thinking of whether this is defined in the device tree, or only exists as a binary table in SMBIOS? I probably know the answer :-)

Quoted 2 lines

As a more fundamental question though, will we really care about the non-EFI boot path 5 or 10 years from now? It doesn?t add much complexity and allows for less divergence between classic embedded and server systems. Since Linux itself is a uEFI binary, you can simply replace ?booti? with ?bootefi? in most boot cases and shouldn?t even see much of a difference.

Linux can certainly be built as an EFI binary. I can't predict the

future, but I'm not sure that 'classic embedded' (i.e. most devices in the world) want to become more like server systems. We'll see.

Quoted 3 lines

I don?t think that the non-EFI boot path will disappear, but turns more and more into a second class citizen because a lot of work is happening in the server space which requires EFI.

OK, well let's see. Most of my objection to EFI is the complexity/size.obfuscation of the code. Maybe someone should work on that, or are you suggesting that UEFI dies and people use U-Boot with the EFI interface?

Quoted 3 lines

But yes, please be my guest and suggest device tree properties to the Linux device tree list that allow exposure of tables (I?m not sure whether anything beyond SMBIOS makes sense for a dt based system) to Linux on non-EFI boot.

If I get a server system one day I might do that. I don't have one yet.