- boot-architecture - lists.linaro.org

EBBR pre-release v2.3.0-pre1 available for review

by Vincent Stehlé

Hi, The EBBR pre-release v2.3.0-pre1 is now available for review. [1] Pdf comparisons are attached there for convenience. Please, have a look and report any issue found by e-mail or during our next call on Dec 18 [2]. If everything looks good and everybody agrees, we will release EBBR v2.3.0 soon after that. Thank you! Best regards, Vincent Stehlé System Architect - Arm [1]: https://github.com/ARM-software/ebbr/releases/tag/v2.3.0-pre1 [2]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

1 year, 4 months

2
2
0 0

EBBR call today Dec 4

by Vincent Stehlé

Dear EBBR contributors, We will have an EBBR call[1] today, Dec 4 at 14h00 UTC. We have two topics and a pull request on the agenda[2]: - #135: Prepare for v2.3.0 - HTTP Boot (Ilias) - Changing SetVirtualAddressMap() + ConvertPointer() to optional and not recommended (Ilias) We can 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-dec-4-abi8?lang=en #135 https://github.com/ARM-software/ebbr/pull/135

1 year, 4 months

4
7
0 0

No EBBR call today, Nov 20 and preparing v2.3.0?

by Vincent Stehlé

Hi, We have nothing on today's EBBR call's agenda [1]; we might therefore cancel it. If you have an urgent topic to discuss today, please let us know before 11am UTC, otherwise we will adjourn the call (sorry for the short notice). Also, given EBBR current stability, I am starting to think that it might be ripe for a release. Here is a summary of the most significant changes since v2.2.0: chapter2: require authenticated fmp capsules for fw update Update UEFI version to 2.10 A chapter2: add boot manager requirements (More changes omitted here.) I will post a pull-request to prepare a v2.3.0. Best regards, Vincent Stehlé System Architect - Arm [1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

1 year, 5 months

1
1
0 0

No EBBR call today, Nov 6?

by Vincent Stehlé

Hi, We have nothing on today's EBBR call's agenda [1]; we might thus cancel it. If you have an urgent 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 year, 5 months

1
1
0 0

EBBR call today Oct 23

by Vincent Stehlé

Dear EBBR contributors, We will have an EBBR call[1] today, Oct 23 at 14h00 BST (13h00 UTC; BST is active). Hopefully this slot will be better than the original one on Mondays. We have two pull requests on the agenda[2]: - #132 Boot Manager requirements - #134 Recommend psci node under firmware Feel free to add to the agenda, directly on the wiki page or by e-mail. We can 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-oct-23-aaq7?lang=en #132 https://github.com/ARM-software/ebbr/pull/132 #134 https://github.com/ARM-software/ebbr/pull/134

1 year, 5 months

1
0
0 0

Moving the EBBR call slot to Wednesdays, 14:00 UTC/BST

by Vincent Stehlé

Dear EBBR stakeholders, Thank you for completing the second poll [1]. We have looked at the results during our call of yesterday [2]. While there is no ideal slot allowing all people to attend, the Wednesday slots seem to allow more participants. We have thus decided to move the EBBR call to Wednesday, 14:00 UTC (following BST). Our next call will be on Oct. 23; see you there! Best regards, -- Vincent Stehlé System Architect - Arm [1] https://framadate.org/Wwf2GCiOsQywWfTg [2] https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2024.10.07

1 year, 6 months

1
0
0 0

EBBR call today, Oct 7

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Oct 7 at 14h30 BST (13h30 UTC; BST is active). We have two topics on the agenda[2]: - Discussion around Boot Manager (see #132, "Boot Manager requirements"). - Poll results and choosing a new schedule for the EBBR call (see second poll) Feel free to add to the agenda, directly on the wiki page or by e-mail. We can 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-oct-7-aafj?lang=en #132 https://github.com/ARM-software/ebbr/pull/132

1 year, 6 months

2
1
0 0

Second poll to find an even better schedule for the EBBR call

by Vincent Stehlé

Dear EBBR stakeholders, Thank you for having completed the poll, to try to find an even better schedule for our EBBR call. It appears that people have available slots on the afternoon of Monday, Wednesday and Friday. Here is a second (and hopefully last) poll, with 1/2 hour granularity: https://framadate.org/Wwf2GCiOsQywWfTg Could you please add your availabilities in there? Thank you! Best regards, Vincent Stehlé System Architect - Arm

1 year, 6 months

1
0
0 0

No EBBR call today, Sep 23?

by Vincent Stehlé

Hi, We have nothing on today's EBBR call's agenda [1]; we might as well cancel it. If you have an urgent topic to discuss today, please let us know before 1pm BST (12pm 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 year, 6 months

1
1
0 0

EBBR call today Sep 9

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Sep 9 at 15h30 BST (14h30 UTC; BST is active). We have only one pull requests on the agenda[2], therefore it might be a short call: - #132: Boot Manager requirements Feel free to add to the agenda, directly on the wiki page or by e-mail. We can 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-9-a9wv?lang=en [132] https://github.com/ARM-software/ebbr/pull/132

1 year, 7 months

1
0
0 0

EBBR next call and poll

by Vincent Stehlé

Dear EBBR stakeholders, I hope you all had a nice summer break. Our next EBBR call is approaching as it will take place next Monday, Aug 26 at 14h30 BST (13h30 UTC; BST is active). In the mean time, I would like to remind you that we have a poll[1] on-going, to try to find an even better schedule for our EBBR call. Thank you to those who added their availabilities already; for those of you, who have not yet completed this first poll, could you please do so? At the time of writing, we have a couple of pull requests on the agenda[2]: - #131: Update UEFI version to 2.10 A - #132: Boot Manager requirements This an attempt at fixing issue #130: Explicitly require boot manager, from Heinrich Please have a look, and feel free to add to the agenda, directly on the wiki page or by e-mail. Best regards, Vincent Stehlé System Architect - Arm [1] https://framadate.org/6jm8P3jHqAzmv8Xo [2] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [130] https://github.com/ARM-software/ebbr/issues/130 [131] https://github.com/ARM-software/ebbr/pull/131 [132] https://github.com/ARM-software/ebbr/pull/132

1 year, 7 months

2
2
0 0

Re: Re: Re: Firmware Partition Filesystem query

by Ghennadi Procopciuc

>> Could this section be updated in order to reduce the number of different >> interpretations? > > Yes, it can be clarified. As Daniel says, this section is only > intended for platforms where there is no other place to store > firmware. If the OS and the firmware need to share a logical block > device, and there is no way to protect the firmware bits, then this > section describes how they can co-exist. e.g., you don't want an OS > deployment to accidentally wipe out firmware. > > It is preferred and encouraged to have firmware contained entirely in > something separate from the main block storage. For example, in eMMC > boot areas (separate from the primary area), or on a separate device > entirely (SPI flash). I predict that a future version of EBBR will > require this and drop the shared storage option entirely because it is > necessary to protect against attacks against firmware (replacement or > deletion) > > g. > Thank you all contributing to this thread! While most of the points in this thread are self-explanatory and should not need a summary, I want to extract the main points to avoid misinterpretations: 1. Chapters '4.1 Partitioning of Shared Storage' and '4.2 Firmware Partition Filesystem' refer to cases when shared storage is used for OS and firmware images. In this case, the block device needs to be partitioned using GPT and the firmware binaries should be stored in a FAT partition. The folder organization for this partition is described in the '4.2.1 The firmware directory hierarchy' chapter. Ideally, the BootROM should be able to load images from a FAT partition. However, a feature release of the EBBR is likely to drop this option in the future. 2. For scenarios involving dedicated storage, the organization of the underlying storage for firmware falls outside the scope of the EBBR and can be arranged according to the SoC vendor's discretion. This can include options such as offset addressing, without GPT, with MRB, with or without a partition, based on the platform's requirements or limitations. Could you please confirm that this understanding is correct? > If I recall correctly, on the Arm platform, A-BL1 (BootROM) and A-BL2 > are responsible only for > loading the images. SCP_BL2 is loaded by BL2 into trusted SRAM and then > transferred to the SCP using the MHU protocol and I believe it is > followed this > way for other platforms also (?). > In summary, A-BL1(BootROM) and A-BL2 need to be aware of their next > stages to load those > images properly: > BootROM -> BL2 -> BL31 -> ... > | > v > SCP If the above summary points are valid, then in the case of a shared device, the BL2 should be able to load the next image(s) (either FIP or BL31) from a FAT partition, I suppose. Regards, Ghennadi

1 year, 9 months

1
0
0 0

Firmware Partition Filesystem query

by Ghennadi Procopciuc

Greetings everyone, I came across the following paragraph while reading the 'Firmware Partition Filesystem' chapter from EBBR v2.2.0 and I would like to clarify my understanding: Where possible, firmware images and data should be stored in a filesystem. Firmware can be stored either in a dedicated firmware partition, or in certain circumstances in the UEFI System Partition (ESP). Using a filesystem makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware for multiple platforms. Dedicated firmware partitions should be formatted with a FAT filesystem as defined in UEFI § 13.3 File System Format. Dedicated firmware partitions should use the same /FIRMWARE directory hierarchy. OS tools shall ignore dedicated firmware partitions, and shall not attempt to use a dedicated firmware partition as an ESP Questions: 1. Does the above paragraph mean that, if the device allows, all firmware binaries (TF-A, U-Boot, and some others) must be stored in a dedicated firmware partition formatted with a FAT filesystem and GUID Partition Table (GPT) disk layout? 2. If so, would this also mean that, where possible, the BootROM or a (first stage) bootloader running before TF-A should have GPT and FAT support embedded support to load one of the TF-A stages (BL1/BL2)? Regards, Ghennadi

1 year, 9 months

4
5
0 0

No EBBR call today?

by Vincent Stehlé

Hi, We have nothing on today's EBBR call's agenda [1]; I would thus be inclined to cancel it. If you have an urgent topic to discuss today, please let us know before 1pm 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 year, 9 months

1
1
0 0

Moving the EBBR call 1/2h earlier?

by Vincent Stehlé

Hi, The question of moving the EBBR call 1/2 hour earlier was raised during our last call [1]. Some people have colliding meetings now and it would make their lives easier. Also, this seemed practical for all the people present. Could all the EBBR attendees please tick their available hours on the following poll? https://framadate.org/FWI2Ff4Tmyz9yOfR Thank you in advance! If possible we will move the EBBR call to 14:30 UTC/BST starting with our next call on Jul 15. Best regards, Vincent Stehlé System Architect - Arm [1] https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2024.07.01

1 year, 9 months

1
1
0 0

EBBR call today Jul 1

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Jul 1 at 15h BST (14h UTC; BST is active). We have two pull requests on the agenda[2]: - #[119]: Require authenticated FMP firmware updates - #[129]: Deprecate spin tables Feel free to add to the agenda, directly on the wiki page or by e-mail. We can 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-jul-1-a8m7?lang=en [119] https://github.com/ARM-software/ebbr/pull/119 [129] https://github.com/ARM-software/ebbr/pull/129

1 year, 9 months

1
0
0 0

[PATCH RFC v3 0/9] dt-bindings: hwinfo: Introduce board-id

by Elliot Berman

Device manufacturers frequently ship multiple boards or SKUs under a single software package. These software packages will ship multiple devicetree blobs and require some mechanism to pick the correct DTB for the board the software package was deployed. Introduce a common definition for adding board identifiers to device trees. board-id provides a mechanism for bootloaders to select the appropriate DTB which is vendor/OEM-agnostic. This series is based off a talk I gave at EOSS NA 2024 [1]. There is some further discussion about how to do devicetree selection in the boot-architecture mailing list [2]. [1]: https://sched.co/1aBFy [2]: https://lists.linaro.org/archives/list/boot-architecture@lists.linaro.org/t… Quick summary ------------- This series introduces a new subnode in the root: / { board-id { some-hw-id = <value>; other-hw-id = <val1>, <val2>; }; }; Firmware provides a mechanism to fetch the values of "some-hw-id" and "other-hw-id" based on the property name. I'd like to leave exact mechanism data out of the scope of this proposal to keep this proposal flexible because it seems architecture specific, although I think we we should discuss possible approaches. A DTB matches if firmware can provide a matching value for every one of the properties under /board-id. In the above example, val1 and val2 are both valid values and firmware only provides the one that actually describes the board. It's expected that devicetree's board-id don't describe all the properties firmware could provide. For instance, a devicetree overlay may only care about "other-hw-id" and not "some-hw-id". Thus, it need only mention "other-hw-id" in its board-id node. Isn't that what the compatible property is for? ----------------------------------------------- The compatible property can be used for board matching, but requires bootloaders and/or firmware to maintain a database of possible strings to match against or implement complex compatible string matching. Compatible string matching becomes complicated when there are multiple versions of board: the device tree selector should recognize a DTB that cares to distinguish between v1/v2 and a DTB that doesn't make the distinction. An eeprom either needs to store the compatible strings that could match against the board or the bootloader needs to have vendor-specific decoding logic for the compatible string. Neither increasing eeprom storage nor adding vendor-specific decoding logic is desirable. How is this better than Qualcomm's qcom,msm-id/qcom,board-id? ------------------------------------------------------------- The selection process for devicetrees was Qualcomm-specific and not useful for other devices and bootloaders that were not developed by Qualcomm because a complex algorithm was used to implement. Board-ids provide a matching solution that can be implemented by bootloaders without introducing vendor-specific code. Qualcomm uses three devicetree properties: msm-id (interchangeably: soc-id), board-id, and pmic-id. This does not scale well for use casese which use identifiers, for example, to distinguish between a display panel. For a display panel, an approach could be to add a new property: display-id, but now bootloaders need to be updated to also read this property. We want to avoid requiring to update bootloaders with new hardware identifiers: a bootloader need only recognize the identifiers it can handle. Notes about the patches ----------------------- In my opinion, most of the patches in this series should be submitted to libfdt and/or dtschema project. I've made them apply on the kernel tree to be easier for other folks to pick them up and play with them. As the patches evolve, I can send them to the appropriate projects. Signed-off-by: Elliot Berman <quic_eberman(a)quicinc.com> --- Changes in v3: - Follow new "/board-id {}" approach, which uses key-value pairs - Add match algorithm in libfdt and some examples to demo how the selection could work in tools/board-id Changes in V2: - Addressed few comments related to board-id, and DDR type. - Link to V2: https://lore.kernel.org/all/a930a3d6-0846-a709-8fe9-44335fec92ca@quicinc.co… --- Amrit Anand (1): dt-bindings: arm: qcom: Update Devicetree identifiers Elliot Berman (8): libfdt: board-id: Implement board-id scoring dt-bindings: board: Introduce board-id fdt-select-board: Add test tool for selecting dtbs based on board-id dt-bindings: board: Document board-ids for Qualcomm devices arm64: boot: dts: sm8650: Add board-id arm64: boot: dts: qcom: Use phandles for thermal_zones arm64: boot: dts: qcom: sm8550: Split into overlays tools: board-id: Add test suite .../devicetree/bindings/board/board-id.yaml | 24 ++++ .../devicetree/bindings/board/qcom,board-id.yaml | 144 ++++++++++++++++++++ arch/arm64/boot/dts/qcom/Makefile | 4 + arch/arm64/boot/dts/qcom/pm8010.dtsi | 62 ++++----- arch/arm64/boot/dts/qcom/pm8550.dtsi | 32 ++--- arch/arm64/boot/dts/qcom/pm8550b.dtsi | 36 +++-- arch/arm64/boot/dts/qcom/pm8550ve.dtsi | 38 +++--- arch/arm64/boot/dts/qcom/pm8550vs.dtsi | 128 +++++++++-------- arch/arm64/boot/dts/qcom/pmr735d_a.dtsi | 38 +++--- arch/arm64/boot/dts/qcom/pmr735d_b.dtsi | 38 +++--- .../dts/qcom/{sm8550-mtp.dts => sm8550-mtp.dtso} | 24 +++- .../dts/qcom/{sm8550-qrd.dts => sm8550-qrd.dtso} | 22 ++- .../boot/dts/qcom/{sm8550.dtsi => sm8550.dts} | 10 +- arch/arm64/boot/dts/qcom/sm8650-mtp.dts | 6 + arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 6 + arch/arm64/boot/dts/qcom/sm8650.dtsi | 2 +- include/dt-bindings/arm/qcom,ids.h | 86 ++++++++++-- scripts/dtc/.gitignore | 1 + scripts/dtc/Makefile | 3 +- scripts/dtc/fdt-select-board.c | 126 +++++++++++++++++ scripts/dtc/libfdt/fdt_ro.c | 76 +++++++++++ scripts/dtc/libfdt/libfdt.h | 54 ++++++++ tools/board-id/test.py | 151 +++++++++++++++++++++ 23 files changed, 901 insertions(+), 210 deletions(-) --- base-commit: e8f897f4afef0031fe618a8e94127a0934896aba change-id: 20240112-board-ids-809ff0281ee5 Best regards, -- Elliot Berman <quic_eberman(a)quicinc.com>

1 year, 9 months

3
17
0 0

EBBR call today Jun 17

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Jun 17 at 15h BST (14h UTC; BST is active). We have no topic on the agenda[2], which means this could be a very short call. Meanwhile, I have put in flight two pull requests [108][119] for review. I feel this is too short notice to discuss their approval today; I have therefore pushed them to our call of July 1st instead. We could still have a look during the call today if people are interested, but we will not approve them today. Feel free to add to the agenda, directly on the wiki page or by e-mail. We can 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-june-17-a8cv [108] https://github.com/ARM-software/ebbr/pull/108 [119] https://github.com/ARM-software/ebbr/pull/119

1 year, 10 months

1
0
0 0

OS provided DT proposal

by Humphreys, Jonathan

Hi all. Several EBBR meetings ago, I introduced the need for allowing OS provided device trees [1]. Please find below the proposal I am delinquent on sending. Hopefully, we can discuss this in the next meeting. Thanks Jon [1] https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2024.02.12 Problem statement: ================== Device trees are in theory a pure description of the hardware, and since the hardware doesn't change, the device tree describing the hardware likewise never changes. With this, a device tree could then be burned into the hardware's ROM to be queried by software for hardware discovery. In practice, though, device trees evolve over time. They evolve for many reasons, including - support for previously unsupported hardware - device driver improvements that require additional hardware information - bug fixes Linux's device tree source is maintained with the kernel source, and kernel builds include building the device trees too. This ensures that the device tree matching the kernel's usage is always kept in sync. Often, embedded distros will include the matching device tree blobs. The EBBR mandates that the device tree blob is provided by the firmware. Thus it is likely that the device tree provided by the firmware and given to the operating system is not the matching device tree blob for that kernel. This can cause hardware to be missing, buggy, or non-functional. Proposal: ========= A key goal of the EBBR is to define the contract between the firmware and the OS so that the OS doesn't need to be built specifically for the hardware, and the firmware can boot any compliant OS. Thus, any solution that requires the OS to know specifics about the hardware beyond the EBBR contract would violate the EBBR goals. This precludes any solution where the OS, having the matching DTBs, would pick the DTB, because this requires the OS to know what hardware it is being run on. Likewise, any solution where the firmware is aware of the OS matching DTBs would require the firmware to be aware of the particular OS it is booting. What can be known: - The firmware knows what board it is running on, and thus knows what device tree to use. But it doesn't know what version of the device tree to use, because it doesn't know what OS is being booted. - The OS knows what version of DTBs matches it's kernel, but does not know which specific device tree to use. This proposal then has the firmware choose the device tree by name, or some other identifier that can be used to match the device tree for the board [1]. It has the OS-provided OS loader select the location of the matching versions of DTBs for it. The firmware would pass the device tree filename/id to the OS loader, instead of the DTB itself. The OS loader would determine the location of the matching DTBs based on the chosen OS to boot, load the matching DTB from that location, and pass to the kernel. Considerations: - often a DTB requires fixups. The EFI_DT_FIXUP_PROTOCOL could be utilized. - device tree overlays could be indicated with a scheme using the device tree ID passed to the OS loader - authenticating the DTB would be the responsibility of the OS distribution and handled in the same way as the kernel itself is authenticated. The OS is the entity responsible for signing the DTB, as it should be. This proposal should be in addition to supporting the standard way of passing in a firmware-provided DT, in cases where the OS doesn't provide or have a need to provide a matching DT. [1] Rather than using the device tree source filename, to have more flexibility, one can conceive an ID or compatible string that the OS could then scan the DTBs to find a match.

1 year, 10 months

18
38
0 0

EBBR v2.2.0 has been released

by Vincent Stehlé

Hi, I am happy to announce that v2.2.0 of the EBBR specification has now been released. [1] The following people (listed in alphabetical order) have participated to this EBBR release directly or indirectly, with patches, github issues, pull requests, reviews, comments, suggestions, or by attending the zoom calls: Ilias Apalodimas Joakim Bech Ard Biesheuvel Etienne Carrière Wei Chen Patrick Delaunay Samuel Dionne-Riel Samer El-Haj-Mahmoud Andreas Färber Ahmad Fatoum Sughosh Ganu Simon Glass Alexander Graf Rob Herring Jon Humphreys Jan Kiszka Jan Lübbe Jose Marinho Loïc Minier Weizhao Ouyang François-Frédéric Ozog Stephen Paulger Tom Rini Peter Robinson Heinrich Schuchardt Michal Simek Vincent Stehlé Daniel Thompson Ivan T. Ivanov Stuart Yoder A big thank you to all the EBBR contributors! Best regards, Vincent Stehlé System Architect - Arm [1]: https://github.com/ARM-software/ebbr/releases/tag/v2.2.0

1 year, 10 months

1
0
0 0

EBBR call today Jun 3

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Jun 3 at 15h BST (14h UTC; BST is active). We have one topic on the agenda[2]: - Decide if v2.2.0-pre1 is ok for release. Feel free to add to the agenda, directly on the wiki page or by e-mail. We can 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-jun-3-a83j

1 year, 10 months

1
0
0 0

Re: [PATCH RFC v3 2/9] dt-bindings: board: Introduce board-id

by Elliot Berman

On Sat, May 25, 2024 at 05:54:52PM +0100, Conor Dooley wrote: > On Wed, May 22, 2024 at 04:54:23PM -0700, Elliot Berman wrote: > > Device manufcturers frequently ship multiple boards or SKUs under a > > single softwre package. These software packages ship multiple devicetree > > blobs and require some mechanims to pick the correct DTB for the boards > > that use the software package. This patch introduces a common language > > for adding board identifiers to devicetrees. > > > > Signed-off-by: Elliot Berman <quic_eberman(a)quicinc.com> > > --- > > .../devicetree/bindings/board/board-id.yaml | 71 ++++++++++++++++++++++ > > 1 file changed, 71 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/board/board-id.yaml b/Documentation/devicetree/bindings/board/board-id.yaml > > new file mode 100644 > > index 000000000000..894c1e310cbd > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/board/board-id.yaml > > @@ -0,0 +1,71 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/board/board-id.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Board identifiers > > +description: | > > + This node contains a list of identifier values for the board(s) supported by > > + this devicetree. Identifier values are either N-tuples of integers or a > > + string. The number of items for an N-tuple identifer is determined by the > > + property name. String identifiers must be suffixed with "-string". > > + > > + Every identifier in the devicetree must have a matching value from the board > > + to be considered a valid devicetree for the board. In other words: if > > + multiple identifiers are present in the board-id and one identifier doesn't > > + match against the board, then the devicetree is not applicable. Note this is > > + not the case where the the board can provide more identifiers than the > > + devicetree describes: those additional identifers can be ignored. > > + > > + Identifiers in the devicetree can describe multiple possible valid values, > > + such as revision 1 and revision 2. > > + > > +maintainers: > > + - Elliot Berman <quic_eberman(a)quicinc.com> > > + > > +properties: > > + $nodename: > > + const: '/' > > + board-id: > > > Does this need to be > properties: > $nodename: > const: board-id > ? That's the pattern I see for all top level nodes. > > > + type: object > > + patternProperties: > > + "^.*(?<!-string)$": > > At least this regex now actually works :) > > > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > > + description: | > > + List of values that match boards this devicetree applies to. > > + A bootloader checks whether any of the values in this list > > + match against the board's value. > > + > > + The number of items per tuple is determined by the property name, > > + see the vendor-specific board-id bindings. > > + "^.*-string$": > > + $ref: /schemas/types.yaml#/definitions/string-array > > Your description above doesn't match a string-array, just a single > string. That said I'm far from sold on the "thou shalt have -string" > edict. If every vendor is expected to go and define their own set of > properties (and provide their own callback in your libfdt PoC) there's > little to no reason to inflict property naming on them, AFAICT all that > is gained is a being able to share > if (string) { > return fdt_stringlist_contains(prop->data, > fdt32_to_cpu(prop->len), > data); > } else { > // exact data comparison. data_len is the size of each entry > if (fdt32_to_cpu(prop->len) % data_len || data_len % 4) > return -FDT_ERR_BADVALUE; > > for (int i = 0; i < fdt32_to_cpu(prop->len); i += data_len) { > if (!memcmp(&prop->data[i], data, data_len)) > return 1; > } > > return 0; > } > in the libfdt PoC? I'd be expecting that a common mechanism would use > the same "callback" for boards shipped by both Qualcomm and > $other_vendor. Every vendor having different properties and only sharing > the board-id node name seems a wee bit like paying lip-service to a > common mechanism to me. What am I missing? One way I thought to get the real board-id values from firmware to OS loader is via DT itself. A firmware-provided DT provides the real board-id values. In this case, firmware doesn't have any way to say the board-id property is a string or a number, so I put that info in the DT property name. Another way I thought to get the real board-id values from firmware is via a UEFI protocol. In that case, we could easily share whether the value is a string or number and we can drop the "-string" suffix bit. Thanks, Elliot

1 year, 10 months

1
0
0 0

Re: [PATCH RFC v3 4/9] dt-bindings: arm: qcom: Update Devicetree identifiers

by Elliot Berman

On Sat, May 25, 2024 at 06:21:32PM +0100, Conor Dooley wrote: > On Tue, May 21, 2024 at 11:38:01AM -0700, Elliot Berman wrote: > > #define QCOM_BOARD_ID(a, major, minor) \ > > - (((major & 0xff) << 16) | ((minor & 0xff) << 8) | QCOM_BOARD_ID_##a) > > + (((major & 0xff) << 16) | ((minor & 0xff) << 8) | ((QCOM_BOARD_ID_##a) & 0xff)) > > I assume there's no devices that have a >8 bit QCOM_BOARD_ID that would > end up with a different value in their dtb due to this change? That's correct.

1 year, 10 months

1
0
0 0

Re: [PATCH RFC v3 0/9] dt-bindings: hwinfo: Introduce board-id

by Elliot Berman

On Mon, May 27, 2024 at 09:19:59AM +0200, Michal Simek wrote: > Hi, > > thanks for CCing me. > > On 5/24/24 17:51, Konrad Dybcio wrote: > > On 21.05.2024 9:00 PM, Dmitry Baryshkov wrote: > > > Hi Elliot, > > > > > > On Tue, 21 May 2024 at 21:41, Elliot Berman <quic_eberman(a)quicinc.com> wrote: > > > > > > > > Device manufacturers frequently ship multiple boards or SKUs under a > > > > single software package. These software packages will ship multiple > > > > devicetree blobs and require some mechanism to pick the correct DTB for > > > > the board the software package was deployed. Introduce a common > > > > definition for adding board identifiers to device trees. board-id > > > > provides a mechanism for bootloaders to select the appropriate DTB which > > > > is vendor/OEM-agnostic. > > > > > > This is a v3 of the RFC, however it is still a qcom-only series. Might > > > I suggest gaining an actual interest from any other hardware vendor > > > (in the form of the patches) before posting v4? Otherwise it might > > > still end up being a Qualcomm solution which is not supported and/or > > > used by other hardware vendors. > > > > AMD should be onboard [1]. > > > > Konrad > > > > [1] https://resources.linaro.org/en/resource/q7U3Rr7m3ZbZmXzYK7A9u3 > > I am trying to wrap my head around this and I have also looked at that EOSS > presentation. > I don't think I fully understand your case. > There are multiple components which you need to detect. SOC - I expect > reading by some regs, board - I expect you have any eeprom, OTP, adc, gpio, > etc way how to detect board ID and revision. > And then you mentioned displays - how do you detect them? We have a similar mechanism to what you mention below: we have a ROM which encodes information about the platform and that can be read by firmware/bootloader/OS. > > In our Kria platform we have eeproms on SOM and CC cards (or FMC/extension > cards) which we read and decode and based on information from it we are > composing "unique" string. And then we are having DTBs in FIT image where > description of configuration it taken as regular expression. That's why it > is up to you how you want to combine them. I don't think this is a fundamentally different approach from my proposal. Instead of composing a "unique" string and using regex to match, I'm proposing that the information (bytes) that are in your eeprom can be matched without going through regex/string conversion. Instead of firmware/bootloader doing a conversion to the strings, it provides the values via board-id. I have concerns about having bootloaders to contain a regex library -- probably easily addressed by standardizing what terms the regex processor needs to support. I'm also not sure if regex strings are an appropriate use of compatible strings. Using strings limits the usefulness of comaptible strings to the consumers of DTB, since the compatible string has to describe only the boards the DTB is applicable to, you can't mention compatible strings "this board is like" such as some generic SoC compatible. > Currently we are merging them offline and we are not applying any DT overlay > at run time but can be done (we are missing one missing piece in U-Boot for > it). > > In presentation you mentioned also that applying overlay can fail but not > sure how you can reach it. Because Linux kernel has the whole infrastructure > to cover all combinations with base DT + overlays. It means if you cover all > working combinations there you should see if they don't apply properly. Mostly, I was referring to a situation where firmware provides an overlay. Firmware doesn't know the DTB that OS has and I don't see any way to gaurantee that firmware knows how to fix up the OS DTB. > > Also do you really need to detect everything from firmware side? Or isn't it > enough to have just "some" devices and then load the rest where you are in > OS? > I think that's pretty much another way to go to have bare minimum > functionality provided by firmware and deal with the rest in OS. Agreed, although not all devices can be loaded once you are in the OS. All nondiscoverable devices would need to be desribed in the DT. Thanks, Elliot

1 year, 10 months

1
0
0 0

Re: [PATCH RFC v3 5/9] dt-bindings: board: Document board-ids for Qualcomm devices

by Elliot Berman

On Sat, May 25, 2024 at 06:08:46PM +0100, Conor Dooley wrote: > On Tue, May 21, 2024 at 11:38:02AM -0700, Elliot Berman wrote: > > + > > +allOf: > > + # either describe soc or soc-version; it's confusing to have both > > Why not just use the one that has the most information and discard the > others? If your dtb picker for this platform doesn't care about the soc > version, then just don't look at that cell? The dtb picker for the platform doesn't know whether to care about the SoC version/platform version/whatever. That's a property of the DTB itself and I don't think it makes much sense to bake that into the DTB picker which would otherwise be unaware of this. > > Likewise for platform and PMIC, why can't you ignore the cells you don't > care about, rather than having a new property for each variant? Nothing > in this patch explains why multiple variants are required rather than > just dealing with the most informational. > Sure, I will explain in future revision. - Elliot

1 year, 10 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture