boot-architecture

boot-architecture@lists.linaro.org

686 discussions

by Vincent Stehle

(This is a resend; sorry if you receive this e-mail twice.) Dear EBBR contributors, We will have our EBBR call today, Nov 19 at 14:00 UTC. [1] We have four pull requests on the agenda [2]: - Pull request #151: references: update RISC-V references - Pull request #152: Recommend firmware TRNG - Pull request #153: Add a note on SMCCC conduits - Pull request #154: Recommend the SOC_ID SMCCC call We will use this pad [3] for the meeting notes. Feel free to add topics to the agenda, directly on the wiki page, by e-mail or on the pad. Best regards, Vincent Stehlé System Architect - Arm [1] https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 [2] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [3] https://mensuel.framapad.org/p/ebbr-call-of-nov-19-ahzj?lang=en #151: https://github.com/ARM-software/ebbr/pull/151 #152: https://github.com/ARM-software/ebbr/pull/152 #153: https://github.com/ARM-software/ebbr/pull/153 #154: https://github.com/ARM-software/ebbr/pull/154 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

7 months, 2 weeks

EBBR call today Nov 19

by Vincent Stehlé

Dear EBBR contributors, We will have our EBBR call today, Nov 19 at 14:00 UTC. [1] We have four pull requests on the agenda [2]: - Pull request #151: references: update RISC-V references - Pull request #152: Recommend firmware TRNG - Pull request #153: Add a note on SMCCC conduits - Pull request #154: Recommend the SOC_ID SMCCC call We will use this pad [3] for the meeting notes. Feel free to add topics to the agenda, directly on the wiki page, by e-mail or on the pad. Best regards, Vincent Stehlé System Architect - Arm [1] https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 [2] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [3] https://mensuel.framapad.org/p/ebbr-call-of-nov-19-ahzj?lang=en #151: https://github.com/ARM-software/ebbr/pull/151 #152: https://github.com/ARM-software/ebbr/pull/152 #153: https://github.com/ARM-software/ebbr/pull/153 #154: https://github.com/ARM-software/ebbr/pull/154

7 months, 2 weeks

EBBR call today Nov 5

by Vincent Stehlé

Dear EBBR contributors, We will have our EBBR call today, Nov 5 at 14:00 UTC. [1] Note: BST is not observed anymore. The call will begin at 14:00 UTC. We have four pull requests on the agenda [2]: - Pull request #142: SCMI requirements - Pull request #148: Fix bibliography alignment for PDF and HTML - Pull request #149: chapter1: do not mention levels - Pull request #150: Clarify compatibility We will use this pad [3] for the meeting notes. Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad. Best regards, Vincent Stehlé System Architect - Arm [1] https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 [2] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [3] https://mensuel.framapad.org/p/ebbr-call-of-nov-5-ahq7?lang=en #142: https://github.com/ARM-software/ebbr/pull/142 #148: https://github.com/ARM-software/ebbr/pull/148 #149: https://github.com/ARM-software/ebbr/pull/149 #150: https://github.com/ARM-software/ebbr/pull/150

8 months

SMBIOS discovery for DT platforms booting without EFI

by Ard Biesheuvel

L.S., Adriana is proposing [0] a method for DT based platforms that boot without EFI to expose the SMBIOS tables via the /chosen DT node. There appears to be consensus between the stakeholders in the u-boot and linux communities that this is a reasonable thing to do, and it looks like this is going to be adopted soon. Adriana has kindly agreed to contributing the u-boot side implementation as well, so all the pieces will be there in terms of code. What is lacking is a contribution to the DMTF spec, which currently only permits the EFI config table method for non-x86 systems. So some wording should be added to paragraph 5.2.2 (SMBIOS 3.9 [1]) It currently reads On non-UEFI systems, the 64-bit SMBIOS Entry Point structure can be located by application software by searching for the anchor-string on paragraph (16-byte) boundaries within the physical memory address range 000F0000h to 000FFFFFh. Given that this makes sense only on x86 systems, I suggest we rephrase this along the lines of On non-UEFI systems, the 64-bit SMBIOS Entry Point structure can be located by application software - on x86 systems only, by searching for the anchor-string on paragraph (16-byte) boundaries within the physical memory address range 000F0000h to 000FFFFFh, - on DT based systems, by obtaining the physical memory address of the structure from the /chosen/smbios3-entrypoint property in the device tree. Maybe Rob can suggest a normative reference to be added to section 2? Thanks, Ard. [0] https://lore.kernel.org/all/CAERbo5z6BzHqQxXdxPxmxE_eDR7GGGbt3A8kB0gQiWFBE-… [1] https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.9.0.…

8 months

Re: [PATCH v4 1/2] dt-bindings: firmware: Add binding for SMBIOS /chosen properties

by Rob Herring

On Fri, Oct 31, 2025 at 5:10 AM adriana <adriana(a)arista.com> wrote: > > Signed-off-by: adriana <adriana(a)arista.com> > --- > .../firmware/linux,smbios3-entrypoint.yaml | 25 +++++++++++++++++++ > 1 file changed, 25 insertions(+) > create mode 100644 Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml > > diff --git a/Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml b/Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml > new file mode 100644 > index 000000000000..4d1521c685ff > --- /dev/null > +++ b/Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml > @@ -0,0 +1,25 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +# Copyright 2025 Arista Networks > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/firmware/linux,smbios3-entrypoint.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Memory location for SMBIOS entry point > + > +description: | > + This property is used in the /chosen node to pass the physical address > + of SMBIOS (System Management BIOS) or DMI (Desktop Management Interface) > + tables from firmware to the kernel. This is typically used on non-EFI. > + > +maintainers: > + - Adriana Nicolae <adriana(a)arista.com> > + - Rob Herring <robh+dt(a)kernel.org> > + > +properties: > + linux,smbios3-entrypoint: > + $ref: /schemas/types.yaml#/definitions/uint64 > + description: > + The 64-bit physical address of the SMBIOSv3 entry point structure. This needs to go in the chosen binding instead: https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/chos…

8 months

Re: [PATCH v4 0/2] DMI: Scan for DMI table from DTS info

by Ard Biesheuvel

On Fri, 31 Oct 2025 at 11:10, adriana <adriana(a)arista.com> wrote: > > Some bootloaders like U-boot, particularly for the ARM architecture, > provide SMBIOS/DMI tables at a specific memory address. However, these > systems often do not boot using a full UEFI environment, which means the > kernel's standard EFI DMI scanner cannot find these tables. > > This series adds support for the kernel to find these tables by > reading the associated property from the Device Tree /chosen node. The > bootloader can specify the physical addresses using the property > "linux,smbios3-entrypoint". > > The first patch introduces the device tree binding documentation for this > new ABI, and the second patch implements the driver logic in dmi_scan.c. > > Changes in v4: > - Renamed linux,smbios3-table.yaml file, removed mention of ARM/ARM64 > (Patch 1/2). > - Drop the second definition of dmi_scan_from_dt() and fold checking > for CONFIG_OF (Patch 2/2). > - Drop unnecessary goto on the success case (Patch 2/2). > - Replace magic number for entrypoint size with SMBIOS3_ENTRY_POINT_SIZE > definition (Patch 2/2). > > Changes in v3: > - Removed linux,smbios-table property, only keep the SMBIOSv3 property > (Patch 1/2). > - Search DT for linux,smbios3-table only, removed the code searching > for the previous property (Patch 2/2). > > Changes in v2: > - Add missing Device Tree binding documentation (Patch 1/2). > - Split the original patch into a 2-part series (binding + driver). > - (No functional changes to the driver code in patch 2/2). > > adriana (2): > dt-bindings: firmware: Add binding for SMBIOS /chosen properties > drivers: firmware: dmi_scan: Add support for reading SMBIOS from DT > For the series, Reviewed-by: Ard Biesheuvel <ardb(a)kernel.org> I can take the second patch, but bindings need to go in separately IIRC. Rob? > .../firmware/linux,smbios3-entrypoint.yaml | 25 +++++++++ > drivers/firmware/dmi_scan.c | 54 +++++++++++++++++++ > 2 files changed, 79 insertions(+) > create mode 100644 Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml > > -- > 2.51.0 >

8 months

Re: [PATCH v3 2/2] drivers: firmware: dmi_scan: Add support for reading SMBIOS from DT

by Ilias Apalodimas

Hi Adriana, On Fri, 31 Oct 2025 at 10:41, adriana <adriana(a)arista.com> wrote: > > From: Adriana Nicolae <adriana(a)arista.com> We'll need a description of why the change is needed here. [...] > > #ifndef SMBIOS_ENTRY_POINT_SCAN_START > #define SMBIOS_ENTRY_POINT_SCAN_START 0xF0000 > @@ -670,6 +673,54 @@ static int __init dmi_smbios3_present(const u8 *buf) > return 1; > } > > +#if IS_ENABLED(CONFIG_OF) > +/** > + * dmi_scan_from_dt - Find and parse DMI/SMBIOS tables from the Device Tree > + * > + * Checks if the bootloader has passed SMBIOS table addresses via the /chosen > + * node in the Device Tree. This follows the standard kernel DT bindings and > + * assumes a fixed 32-byte mapping for the entry point. > + * Returns true if a valid table is found and successfully parsed. > + */ > +static bool __init dmi_scan_from_dt(void) > +{ > + struct device_node *chosen; > + const __be64 *prop; > + char buf[32]; > + void __iomem *p; > + bool dmi_available = false; > + u64 addr; > + int len; > + > + chosen = of_find_node_by_path("/chosen"); > + if (!chosen) > + return false; > + > + prop = of_get_property(chosen, "linux,smbios3-table", &len); > + if (prop && len >= sizeof(u64)) { > + addr = be64_to_cpup(prop); > + > + p = dmi_early_remap(addr, 32); Please put '32' into a define that explains what it is > + if (p == NULL) I think if (!p) is preferred > + goto out; > + > + memcpy_fromio(buf, p, sizeof(buf)); > + dmi_early_unmap(p, 32); > + > + if (!dmi_smbios3_present(buf)) { > + dmi_available = true; > + goto out; > + } > + } > + > +out: > + of_node_put(chosen); > + return dmi_available; > +} > +#else > +static bool __init dmi_scan_from_dt(void) { return false; } > +#endif /* IS_ENABLED(CONFIG_OF) */ > + > static void __init dmi_scan_machine(void) > { > char __iomem *p, *q; > @@ -718,6 +769,13 @@ static void __init dmi_scan_machine(void) > dmi_available = 1; > return; > } > + } else if (IS_ENABLED(CONFIG_OF) && dmi_scan_from_dt()) { Can you fold the IS_ENABLED() in dmi_scan_from_dt() please? > + /* [...] Thanks /Ilias

8 months

Re: [PATCH v3 2/2] drivers: firmware: dmi_scan: Add support for reading SMBIOS from DT

by Ard Biesheuvel

Hello Adriana, On Fri, 31 Oct 2025 at 09:41, adriana <adriana(a)arista.com> wrote: > > From: Adriana Nicolae <adriana(a)arista.com> > > Signed-off-by: Adriana Nicolae <adriana(a)arista.com> > --- > drivers/firmware/dmi_scan.c | 58 +++++++++++++++++++++++++++++++++++++ > 1 file changed, 58 insertions(+) > > diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c > index 70d39adf50dc..acc0e18b8d0f 100644 > --- a/drivers/firmware/dmi_scan.c > +++ b/drivers/firmware/dmi_scan.c > @@ -10,6 +10,9 @@ > #include <linux/random.h> > #include <asm/dmi.h> > #include <linux/unaligned.h> > +#if IS_ENABLED(CONFIG_OF) > +#include <linux/of.h> > +#endif > > #ifndef SMBIOS_ENTRY_POINT_SCAN_START > #define SMBIOS_ENTRY_POINT_SCAN_START 0xF0000 > @@ -670,6 +673,54 @@ static int __init dmi_smbios3_present(const u8 *buf) > return 1; > } > > +#if IS_ENABLED(CONFIG_OF) > +/** > + * dmi_scan_from_dt - Find and parse DMI/SMBIOS tables from the Device Tree > + * > + * Checks if the bootloader has passed SMBIOS table addresses via the /chosen > + * node in the Device Tree. This follows the standard kernel DT bindings and > + * assumes a fixed 32-byte mapping for the entry point. Not sure what 'the standard kernel DT bindings' are, or what you mean by 'a fixed 32-byte mapping. You could just drop this sentence, I think, or otherwise, describe that the DT property gives us the physical address of the SMBIOS3 entrypoint structure. > + * Returns true if a valid table is found and successfully parsed. if a valid entry point is found > + */ > +static bool __init dmi_scan_from_dt(void) > +{ > + struct device_node *chosen; > + const __be64 *prop; > + char buf[32]; > + void __iomem *p; > + bool dmi_available = false; > + u64 addr; > + int len; > + > + chosen = of_find_node_by_path("/chosen"); > + if (!chosen) > + return false; > + > + prop = of_get_property(chosen, "linux,smbios3-table", &len); > + if (prop && len >= sizeof(u64)) { > + addr = be64_to_cpup(prop); > + > + p = dmi_early_remap(addr, 32); > + if (p == NULL) > + goto out; > + > + memcpy_fromio(buf, p, sizeof(buf)); > + dmi_early_unmap(p, 32); > + > + if (!dmi_smbios3_present(buf)) { > + dmi_available = true; > + goto out; > + } > + } > + > +out: > + of_node_put(chosen); > + return dmi_available; > +} > +#else > +static bool __init dmi_scan_from_dt(void) { return false; } > +#endif /* IS_ENABLED(CONFIG_OF) */ > + > static void __init dmi_scan_machine(void) > { > char __iomem *p, *q; > @@ -718,6 +769,13 @@ static void __init dmi_scan_machine(void) > dmi_available = 1; > return; > } > + } else if (IS_ENABLED(CONFIG_OF) && dmi_scan_from_dt()) { Please drop the IS_ENABLED() here, and fold it into dmi_scan_from_dt(), by doing if (!IS_ENABLED(CONFIG_OF)) return false; at the beginning. This removes the need to provide two different versions of dmi_scan_from_dt(). > + /* > + * If EFI is not present or failed, try getting SMBIOS > + * tables from the Device Tree. > + */ > + dmi_available = 1; > + return; > } else if (IS_ENABLED(CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK)) { > p = dmi_early_remap(SMBIOS_ENTRY_POINT_SCAN_START, 0x10000); > if (p == NULL) > -- > 2.51.0 >

8 months

Re: [PATCH v3 1/2] dt-bindings: firmware: Add binding for SMBIOS /chosen properties

by Ard Biesheuvel

On Fri, 31 Oct 2025 at 09:41, adriana <adriana(a)arista.com> wrote: > > From: Adriana Nicolae <adriana(a)arista.com> > > Signed-off-by: Adriana Nicolae <adriana(a)arista.com> > --- > .../bindings/firmware/linux,smbios-table.yaml | 26 +++++++++++++++++++ > 1 file changed, 26 insertions(+) > create mode 100644 Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml > > diff --git a/Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml b/Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml > new file mode 100644 > index 000000000000..b78d8ec6025f > --- /dev/null > +++ b/Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml > @@ -0,0 +1,26 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +# Copyright 2025 Arista Networks > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/firmware/linux,smbios-table.yaml# Should the file name reflect the property? I.e., linux,smbios3-table.yaml > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Memory location for SMBIOS table > + > +description: | > + This property is used in the /chosen node to pass the physical address > + of SMBIOS (System Management BIOS) or DMI (Desktop Management Interface) > + tables from firmware to the kernel. This is typically used on non-EFI > + platforms like ARM/ARM64. > + 'like ARM/ARM64' is both unnecessary and inaccurate, so better to drop it. > +maintainers: > + - Adriana Nicolae <adriana(a)arista.com> > + - Rob Herring <robh+dt(a)kernel.org> > + > +properties: > + linux,smbios3-table: > + $ref: /schemas/types.yaml#/definitions/uint64 > + description: > + The 64-bit physical address of the SMBIOSv3 entry point structure. > + > +additionalProperties: true > -- > 2.51.0 >

8 months

Re: [PATCH v2 0/2] DMI: Scan for DMI table from DTS info

by Ard Biesheuvel

On Thu, 23 Oct 2025 at 16:48, Adriana Nicolae <adriana(a)arista.com> wrote: > > On Thu, Oct 23, 2025 at 4:54 PM Ard Biesheuvel <ardb(a)kernel.org> wrote: > > > > (cc Ilias) > > > > On Thu, 23 Oct 2025 at 15:34, Adriana Nicolae <adriana(a)arista.com> wrote: > > > > > > On Thu, Oct 23, 2025 at 11:21 AM Ard Biesheuvel <ardb(a)kernel.org> wrote: > > > > > > > > On Thu, 23 Oct 2025 at 04:21, Adriana Nicolae <adriana(a)arista.com> wrote: > > > > > > > > > > On Wed, Oct 22, 2025 at 11:19 PM Rob Herring <robh(a)kernel.org> wrote: > > > > > > > > > > > > On Wed, Oct 22, 2025 at 04:45:25AM -0700, adriana wrote: > > > > > > > Some bootloaders like U-boot, particularly for the ARM architecture, > > > > > > > provide SMBIOS/DMI tables at a specific memory address. However, these > > > > > > > systems often do not boot using a full UEFI environment, which means the > > > > > > > kernel's standard EFI DMI scanner cannot find these tables. > > > > > > > > > > > > I thought u-boot is a pretty complete UEFI implementation now. If > > > > > > there's standard way for UEFI to provide this, then that's what we > > > > > > should be using. I know supporting this has been discussed in context of > > > > > > EBBR spec, but no one involved in that has been CC'ed here. > > > > > > > > > > Regarding the use of UEFI, the non UEFI boot is used on Broadcom iProc which > > > > > boots initially into a Hardware Security Module which validates U-boot and then > > > > > loads it. This specific path does not utilize U-Boot's UEFI > > > > > implementation or the > > > > > standard UEFI boot services to pass tables like SMBIOS. > > > > > > > > > > > > > What prevents this HSM validated copy of u-boot from loading the kernel via EFI? > > > The vendor's U-Boot configuration for this specific secure boot path > > > (involving the > > > HSM) explicitly disables the CMD_BOOTEFI option due to security > > > mitigations, only > > > a subset of U-boot commands are whitelisted. We could patch the U-boot > > > to include > > > that but it is preferable to follow the vendor's recommandations and > > > just patch U-boot > > > to fill that memory location with SMBIOS address or directly with the > > > entry point. > > > > And what security mitigations are deemed needed for the EFI code? You > > are aware that avoiding EFI boot means that the booting kernel keeps > > all memory protections disabled for longer than it would otherwise. Is > > this allowlisting based on simply minimizing the code footprint? > > > From the information I have, it might be just minimizing the footprint > but the vendor's U-Boot configuration for this specific path > explicitly disables the CMD_BOOTEFI option. While the vendor cites > security mitigations for this configuration, the specific details > could be a set of mitigation removing different boot methods and some > memory access commands. > > The core issue is that this non-EFI boot path is the vendor-validated > configuration. Enabling EFI would deviate from this setup, require > significant revalidation, and could impact vendor support. Modifying > U-Boot to populate the DT is a contained change without modifying the > U-boot vendor configuration. > I'm not sure I follow why changing U-Boot's code would not require revalidation if simply changing its build configuration without modifying the source code would require that. > Beyond our specific vendor constraints, this DT method might be used > by any other non-UEFI arm system needing to expose SMBIOS tables to > the kernel. > Fair point. So let's do this properly: get buy-in from the U-Boot folks and contribute your u-boot changes as well. And ideally, we'd get this into the DMTF spec but if you are not set up for that (I think you might need to be a member to be able to contribute), we can find some ARM folks who are.

8 months, 1 week

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture