- boot-architecture - lists.linaro.org

EBBR chapter 2.4.1. EFI Conformance Profile Table

by Heinrich Schuchardt

Hello Ilias, hello Vincent, I am currently reviewing EBBR v2.4.0-pre1. I guess a compliant software present all four of the GUIDs so that a client looking for a certain compliance level will hit a match. Currently U-Boot only presents the EFI_CONFORMANCE_PROFILE_EBBR_2_1_GUID. We should evaluate what is missing with respect to the other levels. What I am missing in the EBBR spec is a table with the requirements indicating in which version each requirement was added. Testing would also become easier if each requirement were numbered. Best regards Heinrich

2 weeks, 4 days

3
4
0 0

EBBR v2.4.0-pre1 available for review

by Vincent Stehlé

Dear EBBR contributors, Version 2.4.0-pre1 of the EBBR specification is now available for your review. [1] Please have a look and report any defect you find. We will gather feedbacks during our call of Jan 14 next year. [2] If no major issue is found, we should have an EBBR v2.4.0 release before end of January. I wish you some nice Christmas Holidays, Vincent Stehlé System Architect - Arm [1] https://github.com/ARM-software/ebbr/releases/tag/v2.4.0-pre1 [2] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

2 weeks, 4 days

1
0
0 0

Last EBBR call of 2025 today Dec 17

by Vincent Stehlé

Dear EBBR contributors, We will have our last EBBR call of 2025 today, Nov 19 at 14:00 UTC. [1] We have only one topic on the agenda[2], therefore this could be a short call: - Future EBBR v2.4.0 planning discussion 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-dec-17-aii7?lang=en

2 weeks, 5 days

1
1
0 0

Re: Proposal: Officially allow "incomplete" trees as a base

by Doug Anderson

Hi, On Wed, Dec 3, 2025 at 2:37 PM Doug Anderson <dianders(a)chromium.org> wrote: > > Hi, > > On Tue, Dec 2, 2025 at 3:16 PM Rob Herring <robh(a)kernel.org> wrote: > > > > > as a set of examples. I don't see a clear way to generate these from > > > a fragmented scheme. There's a similar problem with the board-level > > > compatible: > > > > > > compatible = "solidrun,cubox-i/dl", "fsl,imx6dl"; > > > compatible = "solidrun,hummingboard2/dl", "fsl,imx6dl"; > > > compatible = "solidrun,hummingboard/dl", "fsl,imx6dl"; > > > compatible = "solidrun,hummingboard2/q", "fsl,imx6q"; > > > > > > These don't include the SoM information. > > > > So we're back to needing to merge compatible even though Doug was > > willing to drop it. Or to put it another way, there's usecases for the > > base to be different SoC revisions and variants. So I don't think we > > should give up on solving that. > > I'm willing to take a crack at it. Before doing so, though, I think we > need to agree upon a definition of what the top-level "compatible" is > supposed to be. Otherwise, what exactly is our goal in trying to merge > "compatible" strings? We should have a goal of updating the official > documentation with whatever we decide. > > > I guess first, we should see what the spec says. The Devicetree > Specification v0.4 says this about the top-level compatible (which, it > should be noted, is documented _separtely_ from section 2.3.1 since > all of section 2.3 is only about device nodes): > > > Specifies a list of platform architectures with which this platform is compatible. This property can be used by operating systems in selecting platform specific code. The recommended form of the property value is: "manufacturer,model" For example: compatible = "fsl,mpc8572ds" > > That's not very detailed, but I guess we can start out looking at what > it _doesn't_ say. > > a) The spec doesn't say anything about the top-level compatible > uniquely identifying a specific hardware configuration. Nothing there > says "look at one of the strings in the list and you can tell exactly > what product you have in front of you". > > b) The spec doesn't specifically mention that one should include any > strings for a SoC / SoM / reference board. Indeed, the example given > shows an example "compatible" with just one string: "fsl,mpc8572ds". > Searching the interwebs, I find that this example "compatible" > probably refers to a Freescale "MPC8572 Development System", which is > a dev board with a "MPC8572" chip. Notably, the example "compatible" > didn't include the "MPC8572" chip. > > c) The spec doesn't seem to include a firm definition of what they > mean by the word "platform". In my mind, one could interpret the SoC > as a "platform". One could also interpret a SoM or a reference board > as a "platform". It's not necessarily clear. Since AI is the answer to > all things these days, I asked Gemini. I asked what "platform" meant > in the context of the DT spec and it (confidently) told me that "the > platform is the physical machine." ...but when I asked if one could > also consider the SoC the "platform", it told me that was "an > excellent clarifying question" and went on to say the SoC "is often > referred to as the base platform or the SoC-level platform." :-P > > > How does that help us? I guess I'd summarize that, from reading the > spec and more loosely interpreting the word "platform": > > a) The compatible string doesn't _need_ to include strings > representing the SoC, SoM, or baseboard, but it can. > > b) The compatible string is primarily there for use by the operating > system to select platform (board, reference board, SoM, or SoC) > specific code. > > > That still doesn't really tell us when we should / shouldn't include a > SoC / SoM / baseboard in the top-level "compatible". It also doesn't > tell us if we should include even more detailed levels. ...and by > "more detailed levels", I would perhaps say that each of these could > also be considered a "platform": > * google,trogdor-lazor-rev6-sku6 - An exact model of board. > * google,trogdor-lazor-rev6 - A platform that has several SKUs. > * google,trogdor-lazor - A platform that has several revisions and SKUs. > * google,trogdor - A reference platform that has several boards. > > > Perhaps we should lean into the statement "This property can be used > by operating systems in selecting platform specific code" to give us > guidance? The problem is that we somehow need to not just look at > current operating systems but, if we want to strive towards the goal > of shipping binary device trees, we need to consider future operating > system code that hasn't yet been written. That sounds impossible and > makes one think you should cram as much info into the compatible > string as possible, but... > > ...actually, we only need to put information into the compatible > string if there's not an easy way for the operating system to get the > information elsewhere, right? If the information is found elsewhere in > the device tree or if the operating system can probe the information > itself, then there's really no _need_ to put it in the top-level > "compatible" and we'll never end up painting ourselves into a corner. > We could still put the information there just to make it convenient, > but it's not really needed. Does this make sense? > > I would further argue that, in order to be useful, any given > "platform" should document its expectations and we need to be > consistent across anyone using that platform. To make it concrete, if > the Qualcomm SC7180 platform documents that "qcom,sc7180" belongs in > the top-level compatible string then all device trees including sc7180 > should have that string. This _doesn't_ mean that on some future > platform (like qcom,sc9999) we couldn't make a different decision. > Maybe on "qcom,sc9999" we've decided to put SoC details as some > properties under the "soc@0" node. Now the operating system can find > the details about which SoC is present from the "soc@0" node and > therefore we don't need to represent it in the top-level compatible > string. > > > Assuming that all makes sense, maybe the way to document the top-level > compatible string: > > -- > > Specifies a list of "platform architectures" with which this platform > is compatible. A "platform architecture" can be at any level, from the > specific board to the class of board to the reference platform to the > SoM to the SoC. A given "platform architecture" should always be > consistently included or not-included by all final device trees using > it. If the "qcom,sc7180" SoC platform is defined to be included, it > should be consistently included by any device trees with this SoC. The > criteria for whether to represent a "platform architecture" in the > top-level compatible string is the difficulty of the operating system > obtaining the information in some other way (including from other DT > properties or from probing). In general, the top-level "compatible" > used by operating systems in selecting platform specific code. The > recommended form of the property value is: "manufacturer,model" > > Examples: > > compatible = "fsl,mpc8572ds"; > - Select code related to the Freescale MPC8572 Development System > > No platform is included for the CPU since ("fsl,mpc8572") isn't > consistently listed as a platform. > > compatible = "google,snow-rev4", "google,snow", "samsung,exynos5250", > "samsung,exynos5" > - Select code related to google,snow-rev4. > - Select code related to google,snow. > - Select code related to samsung,exynos5250. > - Select code related to samsung,exynos5. > > In this example, the idea is that all exynos5 boards would have > "samsung,exynos5" so code that needed to run on "exynos5" could > consistently test for that "compatible" string. Similarly, all > exynos5250 boards would have "samsung,exynos5250" and all snow boards > would have "google,snow" > > -- > > What do folks think? > > Note that the current Chromebook stuff [1] we used on sc7180-trogdor > boards doesn't fit amazingly well into that definition, but it can > kinda squeeze in there. Essentially the sc7180-trogdor stuff is > designed around making it easy for the bootloader to find the right > device tree but doesn't provide anything terribly useful to the OS in > the top-level "compatible" string. At this point, I don't think I > would encourage others to adopt something similar. > > > If folks agree with the above interpretation, I think I'd end up back > to arguing _against_ the need to merge compatible strings. If we don't > need to put detailed SoC information into the top-level compatible > string then we don't need to merge. I think the most > flexible/futureproof would be to just define that for the SoC inside > Pixel 10 (and presumably all future Google Silicon) we'll put SoC > information under the "soc@0" node and thus there's no need to include > it in the top-level "compatible". That leaves us without a > "compatible" to put in the base "dtb", but maybe we can just put > compatible = "incomplete" or something like that? > > I suspect that even for Russell's purposes the information can either > be probed by the OS or put in places other than the top-level > compatible string. We might not want to change his existing > devicetrees in case some OS is relying on the existing compatible > strings, but for work going forward it feels like it would be a > solution... > > > [1] https://docs.kernel.org/arch/arm/google/chromebook-boot-flow.html It's me again. The pest. Adding a few people who piped up when I mentioned this at Plumbers (namely Bjorn and Geert)... Bjorn mentioned that, in general, it's hard to know what device / devicetree people are using when they report bugs. Presumably if we made the top-level compatible less representative of the overall system, this problem would be made worse? While this is true, to me it isn't necessarily a blocker (though feel free to object). Specifically: * The device tree doesn't fully describe all hardware anyway. While we might use a "SKU" variant to choose between one MIPI panel or another, Chromebooks _don't_ use SKU variants to choose between one eDP panel or another because eDP panels can be probed. We also might use a "SKU" variant to choose between two MIPI webcams but not two USB webcams for the same reason. * We've already accepted the idea of "hardware probers" that can run at boot anyway and those don't adjust SKU numbers. grep the source for "fail-needs-probe". Someone pointed out that if you really need the device tree it could be captured in bug reports. This seems reasonable to me. I also really liked the idea of keeping some sort of log somewhere in the device tree every time an overlay is applied, though I tend to agree with others that filenames of device tree files shouldn't be ABI. Geert talked about the top-level compatible as being the "last resort" to fix any issue. That matches my understanding above from reading the docs and seeing how it was used. Geert: I would be curious what you thought about my arguments above. In general, I'm still hoping to figure out next steps. I believe this problem is important enough that we shouldn't just drop it due to silence, so I'll continue being my usual noisy self and keep pestering. -Doug

3 weeks

1
0
0 0

No EBBR call today Dec 3?

by Vincent Stehlé

Dear EBBR stakeholders, We have currently no agenda for today's EBBR call. [1] If you have a topic to discuss today, please let us know before 11am UTC, otherwise we will adjourn the call. Best regards, Vincent Stehlé System Architect - Arm [1] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

1 month

1
1
0 0

Proposal: Officially allow "incomplete" trees as a base

by Doug Anderson

This is a continuation of the discussion that started in reply to my patch adding basic device trees for Pixel 10 phones [1]. Problem statement: ------------------ We would like an officially accepted scheme that lets us more efficiently ship compiled device trees for a handful of related products by breaking the device trees up into a common "base" device tree and then applying "overlay" device trees atop the base to make a full and complete device tree. To make it more concrete, we'd like to build a "base" device tree that describes a SoC and then have the overlays be enough to make a full description of a board. In theory, one could also imagine wanting to expand this to 3 or more levels (perhaps SoC, baseboard, derived boards), though this is not planned at this time. The primary reason for wanting to break device trees like this is efficiency of the shipped binary device trees. A large portion of a final device tree just describes the SoC. We save space in the final compiled device trees if they don't need to contain as much duplicated information. A secondary reason for wanting to break device trees like this is to more nicely handle when a board has a socketed SoC that can be replaced with a finite (and small) number of different SoCs (usually revisions of the same SoC). Even if this secondary reason is considered invalid or too difficult, the primary reason still describes a compelling need. In order to make this proposal work, it's expected that a bootloader will understand the scheme and will know how to combine the overlay atop the base before passing a complete device tree to the main OS. Current state of the art (downstream): -------------------------------------- In Android, we do a pretty good job of solving the stated problem using device tree overlays. We describe the SoCs in "dts" files and compile them into "dtb"s. We describe boards in "dtso" files and compile them into "dtbo" files. A bootloader can handle identifying the correct base and overlay (the scheme for doing this is a separate but related topic) and applying the overlay atop the base "dtb". This solution is fully implemented downstream for Android phones and is well documented [2]. The issues I'm aware of with the current state of the art are: 1. In order for the base device tree to pass schema validation on its own we'd need to document the top-level compatible strings in the device tree. It is the opinion of at least some device tree maintainers that a SoC doesn't qualify as a top-level compatible string. This prevents the device trees from landing in an officially sanctioned location. 2. It is also possible we may fail schema validation for the base SoC tree if the schema marks a property as "required" but that property needs to be filled out by the board (perhaps a "-supply" is marked as "required", since most "-supply" properties are filled in by the board. I'm not sure this is a big issue, but it's something to think about. 3. It's unclear if there is any official "ABI" promised here once we've compiled and validated the base device tree on its own. Will people assume that they can have out-of-tree overlays derived from the base SoC tree and that those out-of-tree overlays will continue to work across changes / cleanups to the base? NOTE: this is a pre-existing question for existing device tree overlay usage, but the sheer quantity of nodes/properties that a board would be expected to overlay/modify in the base make the problem more prominent. 4. We want the final device tree's top-level compatible to be all the compatible strings from the board followed by all of the compatible strings for the SoC. When the board's overlay is applied to the base SoC tree, though, the board's top-level compatible fully replaces the compatible from the base SoC tree. This can be solved today for non-socketed boards by just duplicating the SoC compatible strings in the board overlays. We can't solve this today for socketed boards, though we can simply make sure that no software drivers rely on the specific SoC compatible string being present and thus we can ignore the problem. None of the above problems are big enough to have prevented widespread use of this scheme in downstream Android. Current state of the art (upstream): ------------------------------------ Upstream if we have a pile of related boards, we do allow deduplicating things at a source-code level with "dtsi" files. We can have a SoC "dtsi" file and that file is included by all boards that use that SoC. When it comes time to validate or ship things, though, we only work with full devices trees. This means that we ship duplicated information. Proposal: --------- 1. Allow the top-level compatible string of an "incomplete" device tree to be documented so it can be validated on its own by tools. It's understood that this SoC is not a board by itself and we'd never boot a full OS with this device tree without adding an overlay that changes the top-level compatible. Add a top-level property to the device tree (perhaps "incomplete-compatible;") to indicate that the tree is not complete without an overlay. 2. If it turns out to be needed (hopefully it's not), allow some type of syntax in yaml files that allows a property to be marked as "required" in a "complete" device tree but not in an "incomplete" device tree. Alternatively, we could discourage marking properties as "required" if they're expected to be filled in by a board. 3. Define that there is no promised ABI between "incomplete" device trees and anything not stored with them. Specifically, all valid combinations of "incomplete" device trees with overlays to complete them should be enumerated together with the "incomplete" device tree. 4. When applying an overlay to a device tree that's "incomplete", the top level overlay will be merged instead of replaced. Example for 2 levels: base (incomplete) compatible: "socvendor,mysoc-rev1", "socvendor,mysoc"; overlay compatible: "boardvendor,myboard-rev1", "boardvendor,myboard"; merged compatible: "boardvendor,myboard-rev1", "boardvendor,myboard", "socvendor,mysoc-rev1", "socvendor,mysoc"; Possible example if we support 3 levels: SoC (incomplete) compatible: "socvendor,mysoc-rev1", "socvendor,mysoc" overlay1 (incomplete) compatible: "referencevendor,referencecodename"; overlay2 compatible: "boardvendor,myboard-rev1", "boardvendor,myboard" merged compatible: "boardvendor,myboard-rev1", "boardvendor,myboard", "referencevendor,reference-codename", "socvendor,mysoc-rev1", "socvendor,mysoc"; Obviously in the 3-level scheme we need to know the order that overlays are applied, but that's true for overlays today anyway. The above proposal takes the current downstream "state of the art" and addresses the known issues, solving the original problem statement. Other thoughts: --------------- If you don't like the proposal, I'd be interested in knowing if you have other ideas for solving the original problem statement, or if you simply think the problem we're trying to solve here is an invalid one. I'm happy to post up another revision of my Pixel 10 device trees following this proof of concept (or other ones). My v1 was _very_ close to this, but didn't have the "incomplete-compatible;" property and didn't implement top-level compatible merging. [1] https://lore.kernel.org/r/20251111112158.1.I72a0b72562b85d02fee424fed939fea… [2] https://source.android.com/docs/core/architecture/dto/partitions

1 month

7
22
0 0

EBBR call today Nov 19

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.

1 month, 2 weeks

1
0
0 0

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

1 month, 2 weeks

1
0
0 0

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

2 months

1
0
0 0

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

2 months

2
2
0 0

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…

2 months

1
1
0 0

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 >

2 months

2
1
0 0

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

2 months

1
0
0 0

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 >

2 months

1
0
0 0

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 >

2 months

1
1
0 0

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.

2 months, 1 week

2
1
0 0

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

by Ard Biesheuvel

(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? Introducing a non-standard mechanism means that others will now have to maintain it and coexist with it, rather than simply using the existing code which already fully supports what you are trying to accomplish (both on the bootloader and the kernel side) IOW, in my opinion, simply enabling CMD_BOOTEFI for your bootloader is a much better choice here. I'm not a u-boot expert but as I understand it, loading/authenticating the image and booting it in EFI mode are two separate things, and so the secure boot path would change very little. > > > Because there's no UEFI configuration table available in this boot mode, we need > > > an alternative mechanism to pass the SMBIOS table address to the kernel. The > > > /chosen node seemed like the most straightforward way for the bootloader to > > > communicate this non-discoverable information. > > > > > > I wasn't aware of the EBBR discussions covering this. I've added the > > > boot-architecture and arm.ebbr-discuss lists to the Cc. If there's a preferred > > > EBBR-compliant way to handle this for non-UEFI boots, I'm happy to adapt > > > the approach. > > > > > > > For the record, I don't see a huge problem with accepting SMBIOS > > tables in this manner, but it would be better if a description of this > > method was contributed to the DMTF spec, which currently states that > > the only way to discover SMBIOS tables on non-x86 systems is via the > > SMBIOS/SMBIOS3 EFI configuration tables. Doing so should prevent other > > folks from inventing their own methods for their own vertically > > integrated systems. (Other OSes exist, and from a boot arch PoV, we > > try to avoid these Linux-only shortcuts) > > > > However, the DT method should *only* be used when not booting via > > UEFI, to avoid future surprises, and to ensure that existing OSes > > (including older Linux) can always find the SMBIOS tables when booting > > via UEFI. > > > > Also, I would suggest to pull the entire entrypoint into DT, rather > > than the address in memory of either/both entrypoint(s). Both just > > carry some version fields, and the address of the actual SMBIOS data > > in memory, and the only difference between SMBIOS and SMBIOS3 is the > > size of the address field (32 vs 64 bits) > I understand the points raised about UEFI taking precedence and the > preference for standardization (DMTF). If this DT method is accepted > as a fallback only for non-UEFI boots like this one, the kernel implementation > will respect that precedence. > > Regarding the alternative to place the full SMBIOS entry point structure into > a DT property (as a byte array) instead of just its memory address. Both > approaches seem feasible from the U-Boot side. I opted initially for passing > the address to reuse the existing kernel functions (dmi_smbios3_present and > dmi_present) which already handle mapping and validation of the entry point > read from memory (as done for the EFI case). > Actually, it appears that dmidecode expects the entrypoint data in /sys/firmware/dmi/tables/smbios_entry_point, and so you will need to populate that file in any case, and so pulling it into the DT node is not as useful. But having both SMBIOS and SMBIOS3 is pointless, so please only bother with the latter.

2 months, 2 weeks

1
0
0 0

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

by Ard Biesheuvel

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? > Because there's no UEFI configuration table available in this boot mode, we need > an alternative mechanism to pass the SMBIOS table address to the kernel. The > /chosen node seemed like the most straightforward way for the bootloader to > communicate this non-discoverable information. > > I wasn't aware of the EBBR discussions covering this. I've added the > boot-architecture and arm.ebbr-discuss lists to the Cc. If there's a preferred > EBBR-compliant way to handle this for non-UEFI boots, I'm happy to adapt > the approach. > For the record, I don't see a huge problem with accepting SMBIOS tables in this manner, but it would be better if a description of this method was contributed to the DMTF spec, which currently states that the only way to discover SMBIOS tables on non-x86 systems is via the SMBIOS/SMBIOS3 EFI configuration tables. Doing so should prevent other folks from inventing their own methods for their own vertically integrated systems. (Other OSes exist, and from a boot arch PoV, we try to avoid these Linux-only shortcuts) However, the DT method should *only* be used when not booting via UEFI, to avoid future surprises, and to ensure that existing OSes (including older Linux) can always find the SMBIOS tables when booting via UEFI. Also, I would suggest to pull the entire entrypoint into DT, rather than the address in memory of either/both entrypoint(s). Both just carry some version fields, and the address of the actual SMBIOS data in memory, and the only difference between SMBIOS and SMBIOS3 is the size of the address field (32 vs 64 bits)

2 months, 2 weeks

1
0
0 0

EBBR call today Oct 22

by Vincent Stehlé

Dear EBBR contributors, We will have our EBBR call today, Oct 22 at 14:00 BST (13:00 UTC). [1] We have two pull requests on the agenda [2]: - Pull request #142: SCMI requirements - Pull request #148: Fix bibliography alignment for PDF and HTML 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-oct-22-ahgu?lang=en #142: https://github.com/ARM-software/ebbr/pull/142 #148: https://github.com/ARM-software/ebbr/pull/148

2 months, 2 weeks

2
2
0 0

EBBR call today Oct 8

by Vincent Stehlé

Dear EBBR contributors, We will have our EBBR call today, Oct 8 at 14:00 BST (13:00 UTC). [1] We have mostly one pull request on the agenda [2]: - Pull request #142: SCMI requirements This is less important but if time permits, we can also discuss this second pull request: - Pull request #148: Fix bibliography alignment for PDF and HTML 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-oct-8-ah7i?lang=en #142: https://github.com/ARM-software/ebbr/pull/142 #148: https://github.com/ARM-software/ebbr/pull/148

2 months, 4 weeks

1
0
0 0

DT relevance

by ff

Dear fellow firmware aficionados, Static ACPI has been adopted by Mercedes and other silicon vendors to: - meet the safety requirements - stay away from DT lifecycle issues - leverage chiplet and CXL bindings - truly multi-host/hypervisor (or even secure/no-secure should people want it) as bindings are defined in an ad-hoc forum (not by an OS community) DT community leaders and enthusiasts, I believe discussion on the bigger picture related to DT relevance in the long run may be needed as I believe many embedded solutions will follow Mercedes example. Constructively yours, François-Frédéric PS: static ACPI can be handled by a simple parser, do not execute any ACPI byte code, is findable by EFI tables, code base is even smaller than libfdt.

3 months

5
11
0 0

EBBR call today Sep 24

by Vincent Stehlé

Dear EBBR contributors, We will have our EBBR call today, Sep 24 at 14:00 BST (13:00 UTC). [1] We have a single topic on the agenda [2]: - Pull request #142: SCMI requirements (was: "Conditionally require SCMI 2.x, x >= 1 recommended") Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad. We will use this pad [3] for the meeting notes. 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-sep-24-agy7?lang=en #142: https://github.com/ARM-software/ebbr/pull/142

3 months, 2 weeks

1
0
0 0

EBBR call today Sep 10

by Vincent Stehlé

Dear EBBR contributors, We will have our EBBR call today, Sep 10 at 14:00 BST (13:00 UTC). [1] We have a single topic on the agenda for now [2]: - Pull request #144: PFDI requirements Heinrich, do you want to add your pull request as well? - Pull request #147: chapter3: raise RISC-V SBI requirement In all cases, feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad. We will use this pad [3] for the meeting notes. 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-sep-10-agou?lang=en #144: https://github.com/ARM-software/ebbr/pull/144 #147: https://github.com/ARM-software/ebbr/pull/147

3 months, 3 weeks

2
1
0 0

Fwd: [devicetree-org/dt-schema] schemas: chosen: document devicetree-path property (PR #167)

by Rob Herring

Posting to boot-architecture list for more visibility. ---------- Forwarded message --------- From: Casey Connolly <notifications(a)github.com> Date: Mon, Jun 30, 2025 at 12:33 PM Subject: [devicetree-org/dt-schema] schemas: chosen: document devicetree-path property (PR #167) To: devicetree-org/dt-schema <dt-schema(a)noreply.github.com> Cc: Subscribed <subscribed(a)noreply.github.com> Background With more and more laptops, dev boards, and other products shipping with both an EFI capable bootloader and relying on devicetree, there is an increasing problem with trying to ensure that a devicetree is loaded and that it will work with the kernel/OS version being booted. This is less of an issue on vertically integrated embedded platforms, but with ARM SystemReady gaining prevalence and the abundance of cheap dev boards there is a growing desire to boot generic OS installer/disk images on these devices. In some cases the platform doesn't see many devicetree changes and works well with a range of kernel versions, the board can just provide it's own devicetree in firmware and it will work just fine. However there are many platforms where this is not the case, unintentional breaking changes can be made to drivers or DT, or new features being enabled can break compatibility with older kernels. In these cases, the best way to maximise the chance that the generic OS image will boot is if it can load the devicetree blob which was installed alongside the kernel (something most mainstream distros do). To enable this there has to be a consistent way to determine which dtb (and overlays) were embedded into the firmware provided devicetree. This new property enables exactly this usecase by making it possible to embed the information into the dtb itself at build time. A proposed implementation of this for U-Boot is available here 1. The devicetree paths are all appended to some versioned prefix (typically the kernel version) which would be known by the OS loader when you choose a version to boot. Prior effort Previous attempts have been made to work around the issue of DTB loading, U-Boot attempts to search some well-known (unversioned) paths on the ESP using it's internal fdtfile variable (which has to be constructed in a platform specific way, see below). This has mixed results and doesn't work on distros like Fedora and Debian which install dtbs to version-specific subdirectories. On the EFI laptop side (where they don't provide any DTB) the dtbloader EFI driver effectively implements the same logic as U-Boot, guessing generic paths and using an internal unreliable map of SMBIOS hardware IDs to file paths, this has been the go-to for many folks for a while now but it's clear that it doesn't scale and that distros won't be keep to ship it. It gets more complicated when you consider secureboot as well which would require signing the driver. File path as API This proposed solution does have a potential stumbling block, as it effectively cements the idea that the dtb path is API. I believe this is a bridge that was already crossed long ago when extlinux and later GRUB and systemd-boot gained a way to specify a devicetree blob to load, since all distros use the upstream file naming, any renames already potentially cause devices to become unbootable after a kernel upgrade... That being said, it's clear that the current way files are named is often arbitrary and definitely inconsistent. I would propose a solution like enforcing a way to convert between the root compatible property and the file path, this provides consistency and removes the need to store this arbitrary additional data needed to locate the dtb on the ESP during boot. An ugly attempt to best-effort this conversion for Qualcomm boards today can be found at 2. Why not store this data elsewhere? There are quite a few benefits to putting this in the DTB itself. It makes it possible to have a generic bootloader binary which gets the DTB in an implementation-specific way, it avoids having to hard-code the data. On devices that have an EFI which doesn't provide a DTB, a driver can be installed once on the ESP which installs a stub DT just containing these properties, so that the OS loader can use them. It isn't EFI specific, extlinux or other boot methods can make use of this. This is metadata which belongs with the DTB, it can be inserted at build time or at runtime, or even augmented to add additional overlays at runtime should the implementation require that. All in all, a generic mechanism for bootloaders and OS loaders to load a dtb and overlays from the ESP (or other arbitrary storage mechanism) is needed, and there doesn't seem to be another place to put it. Why not FIT? The FIT format has it's uses in embedded applications, but the only way it could be applied here would be to use it as the way to index /all/ of the available DTBs, in a generic ARM64 Fedora or Debian image there are thousands of these. In addition, while matching by compatible property may work for the base DTB, it doesn't work for overlays. And of course, using FIT for this would require changing how DTBs are installed and packaged, this would be hugely disruptive and introduce a myriad of additional problems. cc @poettering @apalos ________________________________ You can view, comment on, or merge this pull request online at: https://github.com/devicetree-org/dt-schema/pull/167 Commit Summary bb9677f schemas: chosen: document devicetree-path property File Changes (1 file) M dtschema/schemas/chosen.yaml (22) Patch Links: https://github.com/devicetree-org/dt-schema/pull/167.patch https://github.com/devicetree-org/dt-schema/pull/167.diff — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: <devicetree-org/dt-schema/pull/167(a)github.com>

3 months, 4 weeks

7
17
0 0

Call for Participation: Embedded & IoT micro-conference at Linux Plumbers 2025

by Jan Lübbe

We are happy to announce that the Embedded & IoT micro-conference was again accepted for Linux Plumbers this year. Hosted in beautiful Tokyo, Japan December 11-13. https://lpc.events/event/19/contributions/2005/ Topics cover all things embedded and IoT. Boot time to kernel size, low power communication, telemetry and also RTOS. Devicetree and build system have their own MC and we can move sessions between them as needed. As with all MC's at Plumbers we are not looking for talks, but rather discussing current problems and working towards their solution. If your proposal has a specific stakeholder (maintainer, developer, company) that would be needed for a fruitful discussion, please mention it in your submission. The CfP is open now and will run until October 3rd. Please do not wait until the end with your submissions as we are going to accept good proposals even before the end, so the MC might be filled up before October 3rd. Jan & Stefan

4 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture