- boot-architecture - lists.linaro.org

Re: [PATCH 00/21] Qualcomm generic board support

by Sumit Garg

Hi Tom, On Sun, 10 Dec 2023 at 03:33, Tom Rini <trini(a)konsulko.com> wrote: > > On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: > > [snip] > > But currently u-boot doesn't have a proper way to validate those DTS > > against DT bindings (maintained in Linux kernel). Although there are > > Devicetree schema tools available here [2], there isn't a versioned > > release package of DT bindings which one should use to validate DTS > > files. > > I will have more / other things to say but I want to chime in here. That > U-Boot cannot validate the DTS files is a bug, not a feature. I would > very much appreciate if someone(s) with time and skills to do so would > re-sync us with the kernel Kbuild again so that we can both stay in sync > again and have the validation targets / functionality available here > too. > Agree, the Kbuild changes to add dtbs_check was the first thing I implemented after importing devicetree-rebasing repo in u-boot (see commit [1] for details). Usage with PR [2] included: While building any u-boot target, just add make target: "dtbs_check" and you will see the DT schema checks being performed. Steps: $ make <target>_defconfig $ make -j`nproc` dtbs_check Currently there are a lot of incompatibility warnings I have seen for the platforms I built. This shows how much difficult it has been to keep DT in sync with upstream DT bindings. TBH, this was the only motivation for me to get into discussion with DT bindings maintainers for a separate repo. But since with devicetree-rebasing, we get devictree files bundled along and then I got into reusing them for building DTBs in u-boot. This has the other benefit of reducing maintainer's pain to keep DT in sync with Linux kernel major releases (see amlogic platforms to be the first migrator [3]). [1] https://github.com/u-boot/u-boot/pull/451/commits/7ea2dc2477992a603fa881d0d… [2] https://github.com/u-boot/u-boot/pull/451 [3] https://github.com/u-boot/u-boot/pull/451/commits/38c2ac62e9134604d1a56179d… -Sumit > -- > Tom

1 year, 10 months

2
1
0 0

Re: [PATCH 00/21] Qualcomm generic board support

by ff

Le 7 déc. 2023 à 21:31, Conor Dooley <conor(a)kernel.org> a écrit : What on earth has happened here with quoting? Please fix your mail client man, this mail is a mess to read. Conor: Hopefully I have now fixed MacOS Mail configuration… For all: please accept my apologies on past inconveniences. On Thu, Dec 07, 2023 at 08:24:01PM +0000, ff wrote: Le 7 déc. 2023 à 19:51, Rob Herring <robh+dt(a)kernel.org> a écrit : On Thu, Dec 7, 2023 at 2:08 AM ff <ff(a)shokubai.tech> wrote: Le 6 déc. 2023 à 21:42, Rob Herring <robh+dt(a)kernel.org> a écrit : On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg <sumit.garg(a)linaro.org> wrote: On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> wrote: On 05/12/2023 10:45, Sumit Garg wrote: + U-boot custodians list On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> wrote: On 05/12/2023 08:13, Sumit Garg wrote: @DT bindings maintainers, Given the ease of maintenance of DT bindings within Linux kernel source tree, I don't have a specific objection there. But can we ease DTS testing for firmware/bootloader projects by providing a versioned release package for DT bindings? Or if someone else has a better idea here please feel free to chime in. This doesn't work for you?: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebas… Thanks, this is certainly a good step which I wasn't aware of. Further simplification can be done to decouple devicetree source files from DT bindings. Why? I suppose you are already aware that Linux DTS files are a subset of what could be supported by devicetree schemas. There can be firmware/bootloader specific properties (one example being [1]) which Linux kernel can simply ignore. Will you be willing to add all of those DT properties to Linux DTS files and maintain them? We already added them and we already maintain them. DTS describes the hardware, not the OS-subset of the hardware. Let look at some numbers if your statement is justified or not for the example I gave: u-boot$ git grep -nr bootph-* arch/arm* | wc -l 4079 linux$ git grep -nr bootph-* arch/arm* | wc -l 267 I have no control over whether anyone has submitted the other 3812 instances. It looks like there is always going to be a catch up game regarding DT properties which either Linux kernel or u-boot or any other firmware/bootloader project don't care about. As long as dts files in u-boot are manually sync'ed, yes. That is the problem and it doesn't matter if we have a standalone repository or not. If you want to move in that direction, start automating what u-boot imports. You need to do that for bindings if you want to run validation, so why not dts files too? However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting Both DT bindings and DTS should be common. I don't see the difference. If we really care about DTS to be common then the contribution model has to change where there is a single repo hosting DT bindings and DTS. All other projects whether it is Linux kernel or u-boot or any other OS/firmware/bootloader are just consuming DTS files from that single repo. Really, only the kernel and u-boot matter. No, I don't mean I don't care about other projects, but those are the 2 with the widest h/w support by far and which have a major effort to sync copies of dts files in both projects. The rest are just noise in terms of this problem. I suppose this is something that Linux DT maintainers have objected to in the past for ease of maintenance. I am not sure if you folks are willing to change that stance. The issue is no one steps up to help maintain such a repository while there is lots of review and maintainer work on what goes into the kernel tree. I'm happy to direct my binding review attention to wherever the majority of the bindings go. But the work on the DTS side is mostly SoC tree maintainers and sub-maintainers. Assume for a minute we have this standalone repo. What happens next? We start with an empty repo and then merge and move platforms 1 by 1? What about leveraging SystemReady-IR compliant board maintainers and start with a core of motivated people ? I think there are 2 ATM. Synquacer and i.MX8 variants. Based on https://www.arm.com/architecture/system-architectures/systemready-certifica… roughly 30 boards. Synquacer only has a DT in u-boot, so not really anything to do there. I'm pretty sure the certified DTBs for i.MX8 don't match what's in u-boot or the kernel tree. Hopefully, it's just a subset, but still, there's a gap. I don't know that there is motivation there either. Note that SystemReady currently only requires every node with 'compatible' have a schema. It does not yet require no schema warnings. If we went with a 1 by 1 approach, I would push that platforms have to be free of warnings. How many years will that take? Should all platforms following that organization be a goal? You mean should all platforms be moved? Absolutely. I don't think we want to solve the problem of having DTS files in 2 places by creating a 3rd place. I think this bit here is the only thing you actually wrote: Actually, if we limit he DTS in the third place for SystemReady-IR, there should be no DTB in the Linux distribution. It would be the equivalent as ACPI boards . So is it still an issue ? A reference to the the third repo may be hinted in a text file. SystemReady is only for one architecture, why would using it as the centralised point for devicetree files make sense? SystemReady is an Arm certification but built on EBBR which is the important part and also adopted by RISC-V. So when I said SystemReady, one should read EBBR. EBBR is promoting a DT life cycle that is in line with having an out of OS/Firmware repos definitions. I don't really think 1 by 1 is the right approach. I was just enumerating how this could work. It's not that useful to say we need a standalone repo without working thru the logistics of how exactly that will work. Rob

1 year, 11 months

1
0
0 0

Re: [PATCH 00/21] Qualcomm generic board support

by Sumit Garg

On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> wrote: > > On 05/12/2023 10:45, Sumit Garg wrote: > > + U-boot custodians list > > > > On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski > > <krzysztof.kozlowski(a)linaro.org> wrote: > >> > >> On 05/12/2023 08:13, Sumit Garg wrote: > >>>>> @DT bindings maintainers, > >>>>> > >>>>> Given the ease of maintenance of DT bindings within Linux kernel > >>>>> source tree, I don't have a specific objection there. But can we ease > >>>>> DTS testing for firmware/bootloader projects by providing a versioned > >>>>> release package for DT bindings? Or if someone else has a better idea > >>>>> here please feel free to chime in. > >>>> > >>>> This doesn't work for you?: > >>>> > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebas… > >>> > >>> Thanks, this is certainly a good step which I wasn't aware of. Further > >>> simplification can be done to decouple devicetree source files from DT > >>> bindings. > >> > >> Why? > > > > I suppose you are already aware that Linux DTS files are a subset of > > what could be supported by devicetree schemas. There can be > > firmware/bootloader specific properties (one example being [1]) which > > Linux kernel can simply ignore. Will you be willing to add all of > > those DT properties to Linux DTS files and maintain them? > > We already added them and we already maintain them. DTS describes the > hardware, not the OS-subset of the hardware. Let look at some numbers if your statement is justified or not for the example I gave: u-boot$ git grep -nr bootph-* arch/arm* | wc -l 4079 linux$ git grep -nr bootph-* arch/arm* | wc -l 267 It looks like there is always going to be a catch up game regarding DT properties which either Linux kernel or u-boot or any other firmware/bootloader project don't care about. > > > > > However, DT bindings are something which should be common, the > > hardware description of a device should be universal. IMO, splitting > > Both DT bindings and DTS should be common. I don't see the difference. If we really care about DTS to be common then the contribution model has to change where there is a single repo hosting DT bindings and DTS. All other projects whether it is Linux kernel or u-boot or any other OS/firmware/bootloader are just consuming DTS files from that single repo. I suppose this is something that Linux DT maintainers have objected to in the past for ease of maintenance. I am not sure if you folks are willing to change that stance. > > > DT bindings alone would ease the compliance process for u-boot drivers > > in quite similar manner to Linux drivers. > > > > [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/boot… > > > >> > >>> AFAIK, DT bindings should be forwards and backwards > >>> compatible. > >> > >> The same with DTS. > >> > >>> So if you pick up DTS or DTB from any project tree > >>> (upstream kernel or stable kernel or u-boot) then DT schema validation > >>> would ensure that corresponding DTS or DTB doesn't regress the DT > >>> bindings. > >> > >> And why is this argument to decouple DTS from bindings? > >> > > > > See above. > > It's not really explained there. You can pick up DTS from any project > and validate it against the repo Rob mentioned or against kernel. > Whether DTS is in that repo or not, does not matter for your validation. > It is similar to your earlier argument to use the whole mainline kernel repo. What is the real benefit to keep DT bindings and DTS together when every project has to maintain a copy of DTS in its own source tree? It will be just a source of confusion for developers: - One DTS coming from devicetree-rebasing repo - One DTS coming from local project -Sumit

1 year, 11 months

3
5
0 0

Re: [PATCH 00/21] Qualcomm generic board support

by Sumit Garg

+ U-boot custodians list On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> wrote: > > On 05/12/2023 08:13, Sumit Garg wrote: > >>> @DT bindings maintainers, > >>> > >>> Given the ease of maintenance of DT bindings within Linux kernel > >>> source tree, I don't have a specific objection there. But can we ease > >>> DTS testing for firmware/bootloader projects by providing a versioned > >>> release package for DT bindings? Or if someone else has a better idea > >>> here please feel free to chime in. > >> > >> This doesn't work for you?: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebas… > > > > Thanks, this is certainly a good step which I wasn't aware of. Further > > simplification can be done to decouple devicetree source files from DT > > bindings. > > Why? I suppose you are already aware that Linux DTS files are a subset of what could be supported by devicetree schemas. There can be firmware/bootloader specific properties (one example being [1]) which Linux kernel can simply ignore. Will you be willing to add all of those DT properties to Linux DTS files and maintain them? However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting DT bindings alone would ease the compliance process for u-boot drivers in quite similar manner to Linux drivers. [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/boot… > > > AFAIK, DT bindings should be forwards and backwards > > compatible. > > The same with DTS. > > > So if you pick up DTS or DTB from any project tree > > (upstream kernel or stable kernel or u-boot) then DT schema validation > > would ensure that corresponding DTS or DTB doesn't regress the DT > > bindings. > > And why is this argument to decouple DTS from bindings? > See above. > > > > Ideally, it should be more user/CI friendly if DT bindings can be > > easily installed alongside devicetree schema tools [1]. > > > > [1] https://github.com/devicetree-org/dt-schema > > Does it mean you will work on this? I am happy to collaboratively work with DT bindings maintainers and the u-boot community once we can reach a consensus on the above. Basically the main motive here is to validate DTS files present in the u-boot tree and be able to reliably pass them to whichever Linux kernel version you are trying to boot. IOW, make Linux distros to reliably boot with devicetree supplied by u-boot. -Sumit > > Best regards, > Krzysztof >

1 year, 11 months

3
3
0 0

Re: [PATCH 00/21] Qualcomm generic board support

by Sumit Garg

+ Linux kernel DT bindings maintainers, EBBR ML On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini(a)konsulko.com> wrote: > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstrong(a)linaro.org> wrote: > > > > > > On 29/11/2023 16:34, Caleb Connolly wrote: > > > > > > > > > > > > On 23/11/2023 07:04, Sumit Garg wrote: > > > >> On Wed, 22 Nov 2023 at 21:34, Caleb Connolly <caleb.connolly(a)linaro.org> wrote: > > > >>> > > > >>> > > > >>> > > > >>> On 22/11/2023 14:27, Tom Rini wrote: > > > >>>> On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote: > > > >>>>> On Wed, 22 Nov 2023 at 19:31, Tom Rini <trini(a)konsulko.com> wrote: > > > >>>>>> > > > >>>>>> On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote: > > > >>>>>>> Hi Caleb, > > > >>>>>>> > > > >>>>>>> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly <caleb.connolly(a)linaro.org> wrote: > > > >>>>>> [snip] > > > >>>>>>>> == DT loading == > > > >>>>>>>> > > > >>>>>>>> Previously, boards used the FDT blob embedded into U-Boot (via > > > >>>>>>>> OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary > > > >>>>>>>> bootloader, so we can instead rely on the first-stage bootloader to > > > >>>>>>>> populate some useful FDT properties for us (notably the /memory node and > > > >>>>>>>> KASLR seed) and fetch the DTB that it provides. Combined with the memory > > > >>>>>>>> map changes above, this let's us entirely avoid configuring the memory > > > >>>>>>>> map explicitly. > > > >>>>>>> > > > >>>>>>> Since with this change, we don't need to embed FDT blob in the u-boot > > > >>>>>>> binary, so I was thinking if we really need to import DTs from Linux > > > >>>>>>> for different platforms and then play a catchup game? > > > >>> > > > >>> For now, yes. > > > >> > > > >> But why? Is there any value added by larger u-boot specific DT (most > > > >> of the nodes being unused by u-boot) than what currently u-boot > > > >> supports? The more important part is to get alignment with Linux DT > > > >> bindings. If you need to have memory/reserved-memory nodes in u-boot > > > >> DT for generalization purposes then you should import those particular > > > >> nodes only. > > > > > > > > I've been thinking about and hacking on this for the last week or so, > > > > sorry for the delayed reply here. > > > > > > > > The value is in preventing any of the existing bindings from regressing, > > > > That is actually best addressed in Linux by checking the DTS against > > yaml DT bindings. We don't have that testing available in u-boot and > > only depend on careful reviews. > > I would absolutely love for someone to make another attempt at updating > our kbuild infrastucture so that we can run the validation targets. > Given that EBBR requires [1] the platform (firmware/bootloader) and not OS to supply the devicetree, it becomes evident that firmware/bootloaders import DTS from Linux kernel (where it is maintained). But currently u-boot doesn't have a proper way to validate those DTS against DT bindings (maintained in Linux kernel). Although there are Devicetree schema tools available here [2], there isn't a versioned release package of DT bindings which one should use to validate DTS files. @DT bindings maintainers, Given the ease of maintenance of DT bindings within Linux kernel source tree, I don't have a specific objection there. But can we ease DTS testing for firmware/bootloader projects by providing a versioned release package for DT bindings? Or if someone else has a better idea here please feel free to chime in. [1] https://arm-software.github.io/ebbr/#guiding-principles [2] https://github.com/devicetree-org/dt-schema -Sumit > -- > Tom

1 year, 11 months

4
7
0 0

Further clarifications

by Jon Humphreys

Hi all. I've organized some of my requests for clarification below. I appreciate you helping me understand the spec. Where the spec needs clarification itself, I'll create a ticket to track. Basic (dumb) questions: ----------------------- - why is EBBR dictating the location of firmwares? The firmware locations are a contract with the boot ROM and subsequent stages, leading up to the OSloader. The OSloader hand-off interface is the real EBBR contract with an OS provider, I would think. My answer to this question had been that in order for the OS to update firmware, the firmware locations need to be standardized. But I've since learned that the firmware update mechanism should be abstracted via update capsules. So I am back to not understanding why the firmware locations aren't just a convention local to the board vendor. Firmware locations: ------------------- - the EBBR states that a dedicated partition is preferred for storing firmware. This seems to imply that all firmwares will be in a single location. This isn't true in many cases (eg, some partitions aren't large enough and subsequent stages are loaded from a different partition). Is there guidance (or should be guidance) in EBBR on how to handle these scenarios? - does the EBBR discourage placing firmware in the ESP, and if so, under what circumstances is it recommended (eg, trying to boot a stock OS image). See https://github.com/ARM-software/ebbr/issues/113 Device Tree: ------------ - The EBBR requires a device tree file (or ACPI table). It makes complete theoretical sense that the board firmware should supply the DTB, since it is (in theory) a description of the hardware, which obviously doesn't change. But the unfortunate reality is that the device tree is always changing to stay in sync with the kernel. My experience is that OS images ship with a corresponding device tree. But the device tree location is one example where the EBBR does not specify a convention. How can the EBBR handle this reality so that we can standardize where an OS vendor can place its version of the DTB? ESP --- - who is responsible for providing the ESP, the board firmware or the OS provider? The goal of SystemReady is to separate the software packaging between board firmware and OS images, so that we eliminate the need for OS vendors to produce board specific images. The current practice in embedded is to deliver a monolithic, self-contained image, and in this scenario, standards don't matter as much as it is all self-contained. As I try to image what embedded looks like where boards ship with firmware installed and OS providers only provide the OS image, I'm running into these questions like who provides the ESP, where is the DTB located, etc. thanks Jon

1 year, 11 months

4
5
0 0

[DT] Chosen node documentation

by ff

Hi, As I am working on Automotive Virtual Platform Speficition in the context of SOAFEE and there is a reference to « chosen » standardization in the document, I am verifying all external links. The file https://elixir.bootlin.com/linux/v5.19.17/source/Documentation/devicetree/b… has disappeared from the Doc tree since 6.0 There are no references to kaslr-seed, stdout-path or linux,usable-memory-range in the whole DT, including in the current 6.6 tree. There is a brief mention (probably not normative) of « chosen » is usage_model.rst but that’s all. Does anyone knows if that is intentional? Cheers FF

2 years

2
2
0 0

Clarification on firmware location on removable storage

by Jon Humphreys

Hi all. I need clarification on where firmware should be located when booting from removable shared storage. Statements in the intro of 4.2 seem to contradict later statements in 4.2.2 of the EBBR [1]. Section 4.2.2 states that to make it easier to use stock OS images on removable storage, firmware should be located on the ESP partition (so you don't have to create a dedicated firmware partition). > On removable media, firmware should be stored in the ESP under the > /FIRMWARE directory structure as described in Firmware Partition > Filesystem. However, prior in the 4.2 section, it states: > The sections below discuss the requirements when using both fixed and > removable storage. However, it should be noted that the recommended > behaviour of firmware should be identical regardless of storage type. > In both cases, the recommended boot sequence is to first search for > firmware in a dedicated firmware partition, and second search for > firmware in the ESP. Why would the boot sequence for shared storage look in two places if it is always in the ESP? Or does the statement in 4.2.2 only apply in the case of using a stock OS image? As a side question, I'm not sure of the practicality of recommending a boot sequence that looks in two places, at least for the very first firmware stages, as ROM usually is very simple and only looks in a single location. thanks Jon [1] https://arm-software.github.io/ebbr/

2 years

3
7
0 0

EBBR call today Sep 25

by Vincent Stehle

Hi, We will have an EBBR call[1] today, Sep 25, at 15h BST (14h UTC). On the agenda[2] we have a number of pull requests to review: - #[106]: Recommend usage of partition type GUIDs to find firmware (Heinrich) - #[107]: Arm sections changes (was support Armv8-R AArch64) - #[108]: Add smbios tables details (should we even require SMBIOS?) - #[109]: Add an extension for UEFI (and now DTSPEC) references - #[110]: Bump ACPI and PSCI versions Also, a discussion topic: - Secure boot with systemd-boot requires EFI_SECURITY_ARCH_PROTOCOL and EFI_SECURITY2_ARCH_PROTOCOL 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-25-a3fj [106]: https://github.com/ARM-software/ebbr/pull/106 [107]: https://github.com/ARM-software/ebbr/pull/107 [108]: https://github.com/ARM-software/ebbr/pull/108 [109]: https://github.com/ARM-software/ebbr/pull/109 [110]: https://github.com/ARM-software/ebbr/pull/110

2 years, 1 month

1
0
0 0

EBBR call today Sep 11

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Sep 11, at 15h BST (14h UTC). On the agenda[2] we have a number of pull requests to review: - #[106]: Recommend usage of partition type GUIDs to find firmware (Heinrich) - #[107]: Support Armv8-R AArch64 - #[108]: Add smbios tables details - #[109]: Add an extension for UEFI references Also some discussions topics have been proposed: - Secure boot with systemd-boot requires EFI_SECURITY_ARCH_PROTOCOL and EFI_SECURITY2_ARCH_PROTOCOL (Heinrich) - Info: upcoming BBR ECR #634 forbidding some SMCs after ExitBootServices - "Platform firmware must not implement any SMC calls from the SMCCC Vendor Specific EL3 Monitor range (FIDs 0x8700_0000—0x8700_FFFF and 0xC700_0000—0xC700_FFFF) after ExitBootServices." (info from Jose) - Should we specify which Devicetree nodes are allowed? (suggested by Sughosh) 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-11-a368 [106]: https://github.com/ARM-software/ebbr/pull/106 [107]: https://github.com/ARM-software/ebbr/pull/107 [108]: https://github.com/ARM-software/ebbr/pull/108 [109]: https://github.com/ARM-software/ebbr/pull/109

2 years, 1 month

3
2
0 0

Reminder: next EBBR call Sep 11

by Vincent Stehlé

Hi, This is a kind reminder that we will have our next EBBR call on Sep 11. Feel free to add to the agenda, directly on the wiki page[1] or by e-mail. I hope everybody had a nice summer break. Best regards, Vincent Stehlé System Architect - Arm [1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

2 years, 2 months

1
0
0 0

EBBR call today Jun 5

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Jun 5, at 15h UTC/BST. On the agenda[2] we have a pull request to review: - Pull request #[106]: Recommend usage of partition type GUIDs to find firmware (Heinrich) We could also go through the opened issues[3] if time permits. Feel free to add to the agenda, directly on the wiki page or by e-mail. We can use this pad[4] 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://github.com/ARM-software/ebbr/issues [4]: https://mensuel.framapad.org/p/ebbr-call-of-jun-5-a1cv [106]: https://github.com/ARM-software/ebbr/pull/106

2 years, 5 months

1
0
0 0

EBBR call today May 22

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, May 22, at 15h UTC/BST. On the agenda[2] we have two pull requests to review: - Pull request #[105]: Recommend the firmware update protocol - Pull request #[106]: Recommend usage of partition type GUIDs to find firmware (Heinrich) We could also go through the opened issues[3] if time permits. Feel free to add to the agenda, directly on the wiki page or by e-mail. We can use this pad[4] 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://github.com/ARM-software/ebbr/issues [4]: https://mensuel.framapad.org/p/ebbr-call-of-22-may-a13j [105]: https://github.com/ARM-software/ebbr/pull/105 [106]: https://github.com/ARM-software/ebbr/pull/106

2 years, 5 months

1
0
0 0

[RFC] Proposed location to host the firmware handoff specification.

by Jose Marinho

Hi, Arm worked to draft a firmware handoff [1] specification, evolving it based on community feedback. This activity followed the request of some members of the Arm ecosystem [2]. The spec (still at ALP – feedback/comments welcome!) standardizes how information is propagated between different firmware components during boot. The spec hopes to remove the reliance on bespoke/platform-specific information handoff mechanisms, thus reducing the code maintenance burden. The concept of entry types is present in the spec – these are data structure layouts that carry a specific type of data. New types are meant to be added, following the needs and use-cases of the different communities. Thus, these communities should be empowered to request new types! To enable community contributions, the specification must be hosted in a location that is friendly to change requests. We propose to host the spec in trustedfirmware.org (tf.org). Tf.org hosts several open-source projects and already has an open governance model. TF-A, and the associated community, rely on tf.org, and thus are already well equipped to maintain this specification and keep it up to date. Tf.org is agnostic of any downstream projects that would adopt this specification (e.g. U-boot, EDK2, etc.). We welcome the views of the communities and want to understand if there are any strong objections to what’s being proposed! If anyone has objections, we are happy to consider alternatives and associated trade-offs. Regards [1] https://developer.arm.com/documentation/den0135/latest [2] Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages - TF-A - lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…>

2 years, 6 months

7
23
0 0

Re: Recommendation for identifying partition with firmware to be loaded from SD-card

by Heinrich Schuchardt

On 5/4/23 13:39, Michal Simek wrote: > > > On 5/1/23 16:26, Heinrich Schuchardt wrote: >> Linux distributions are interested in providing a single image which >> enables a high number of boards to boot. This is simple if the boot >> firmware (EDK II or U-Boot) is installed on flash. >> >> For boards that expect to load a boot loader like U-Boot from an SD-card >> it is necessary that the firmware locations for different boards >> on the SD-card don't collide. >> >> When loading from SD-card or eMMC the sector at which the binary >> starts has to be identified. The following has been implemented: >> >> - start from hard coded sector number >> - load file from FAT file system >> - load from given partition number >> - load from partition with boot flag set (MBR partioning only) >> - load from partition with specific type GUID >> >> Loading by partition type GUID seems the most appropriate to avoid >> collisions between the firmware for different boards. >> >> Often firmware is separated into multiple parts due to firmware >> restrictions, e.g. U-Boot SPL and main U-Boot (e.g. as .itb file). >> >> Here the same considerations apply. Using a partition type GUID to >> identify further firmware parts to be loaded is best suited to >> avoid collisions. >> >> I would suggest to add a recommendation to the EBBR specification >> to use SoC specific partition type GUIDs to identify firmware to >> be loaded from SD-card. >> >> Please, provide your feedback. > > Isn't this very similar to effort which Andre presented at Fosdem 2019? > > https://archive.fosdem.org/2019/schedule/event/one_image_to_rule_them_all/a… > > Thanks, > Michal Thanks Michal for the pointer. We are talking about the same topic. The question that was not resolved up to now is how we can avoid conflicts between the U-Boot binaries of different SoCs stored on the same medium. This is where I propose to use GUID partition types. Best regards Heinrich

2 years, 6 months

1
0
0 0

Recommendation for identifying partition with firmware to be loaded from SD-card

by Heinrich Schuchardt

Linux distributions are interested in providing a single image which enables a high number of boards to boot. This is simple if the boot firmware (EDK II or U-Boot) is installed on flash. For boards that expect to load a boot loader like U-Boot from an SD-card it is necessary that the firmware locations for different boards on the SD-card don't collide. When loading from SD-card or eMMC the sector at which the binary starts has to be identified. The following has been implemented: - start from hard coded sector number - load file from FAT file system - load from given partition number - load from partition with boot flag set (MBR partioning only) - load from partition with specific type GUID Loading by partition type GUID seems the most appropriate to avoid collisions between the firmware for different boards. Often firmware is separated into multiple parts due to firmware restrictions, e.g. U-Boot SPL and main U-Boot (e.g. as .itb file). Here the same considerations apply. Using a partition type GUID to identify further firmware parts to be loaded is best suited to avoid collisions. I would suggest to add a recommendation to the EBBR specification to use SoC specific partition type GUIDs to identify firmware to be loaded from SD-card. Please, provide your feedback. Best regards Heinrich

2 years, 6 months

3
3
0 0

Re: [RISC-V][tech-os-a-see] Recommendation for identifying partition with firmware to be loaded from SD-card

by Heinrich Schuchardt

On 5/1/23 16:31, Aaron Durbin wrote: > Hi, > > On Mon, May 1, 2023 at 8:26 AM Heinrich Schuchardt > <heinrich.schuchardt(a)canonical.com > <mailto:heinrich.schuchardt@canonical.com>> wrote: > > Linux distributions are interested in providing a single image which > enables a high number of boards to boot. This is simple if the boot > firmware (EDK II or U-Boot) is installed on flash. > > For boards that expect to load a boot loader like U-Boot from an SD-card > it is necessary that the firmware locations for different boards > on the SD-card don't collide. > > When loading from SD-card or eMMC the sector at which the binary > starts has to be identified. The following has been implemented: > > - start from hard coded sector number > - load file from FAT file system > - load from given partition number > - load from partition with boot flag set (MBR partioning only) > - load from partition with specific type GUID > > Loading by partition type GUID seems the most appropriate to avoid > collisions between the firmware for different boards. > > Often firmware is separated into multiple parts due to firmware > restrictions, e.g. U-Boot SPL and main U-Boot (e.g. as .itb file). > > Here the same considerations apply. Using a partition type GUID to > identify further firmware parts to be loaded is best suited to > avoid collisions. > > I would suggest to add a recommendation to the EBBR specification > to use SoC specific partition type GUIDs to identify firmware to > be loaded from SD-card. > > > Who is loading the firmware that is identified by a GUID? And how does > that tie into Linux distros? I don't see anything wrong w/ the > recommendation, but I didn't completely follow which piece of software > is loading firmware and how the GUID reduces the problems. Also, is this > "SoC specific partition type GUID" unique per SoC? Or is it expected to > be a global GUID? Booting firmware starts at boot ROM which may either directly load a piece of software from SD-card or may load a piece of software from flash which in turn will load the next step boot loader from the SD-card. From the view of a distro it is best if each board uses a separate GUID. This allows to add multiple U-Boot versions (or other boot software) on the same SD-card. Best regards Heinrich

2 years, 6 months

1
0
0 0

EBBR call today Apr 24

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Apr 24, at 15h UTC/BST. On the agenda[2] we have one pull request review continuation: - Pull request #[105]: Recommend the firmware update protocol We could also go through the opened issues[3] if willing. Feel free to add to the agenda, directly on the wiki page or by e-mail. We can use this pad[4] 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://github.com/ARM-software/ebbr/issues [4]: https://mensuel.framapad.org/p/ebbr-call-of-apr-24-a0kw?lang=en [105]: https://github.com/ARM-software/ebbr/pull/105

2 years, 6 months

1
0
0 0

No EBBR call next Monday, Apr 10

by Vincent Stehlé

Hi, Next Monday, Apr 10, is Easter Monday and is a bank holiday in some countries. Let us therefore cancel the corresponding EBBR call, please. The next EBBR call will be held on Apr 24. Feel free to add to the agenda, directly on the wiki page[1] or by e-mail. Best regards, Vincent Stehlé System Architect - Arm [1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

2 years, 7 months

1
0
0 0

EBBR call today Mar 27

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Mar 27, at 15h UTC/BST. On the agenda[2] we have pull requests[3] reviews continuations: - Pull request #102: File Format For Storing EFI Variables (Heinrich) - Pull request #104: Make monotonic counter optional (was: Relax monotonic counter nonvolatility) - Pull request #105: Recommend the firmware update protocol Feel free to add to the agenda, directly on the wiki page or by e-mail. We can use this pad[4] 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://github.com/ARM-software/ebbr/pulls [4]: https://mensuel.framapad.org/p/ebbr-call-of-mar-27-a027

2 years, 7 months

1
0
0 0

EBBR call today Mar 13

by Vincent Stehlé

Hi, We will have an EBBR call[1] today at 15h UTC/BST. On the agenda for today[2] we have pull requests[3] reviews: - Pull request #102: File Format For Storing EFI Variables (Heinrich) - Pull request #104: Relax monotonic counter nonvolatility - Pull request #105: Recommend the firmware update protocol Feel free to add to the agenda, directly on the wiki page or by e-mail. We can use this pad[4] 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://github.com/ARM-software/ebbr/pulls [4]: https://mensuel.framapad.org/p/ebbr-call-of-mar-13-9zsw

2 years, 7 months

1
0
0 0

No DT call today or going forward

by Bill Mills

All, There will be no DT call today. In fact, I am going to cancel the series. Since Feb 1, Mondays don't work for me anymore. I have discussed this inside of Linaro and we don't feel a periodic DT call is needed at this time. I am keeping a copy of the invite list in case we want to schedule special meetings on specific topics. If you feel we need this call and wish to host it, please contact me on this list or directly. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

2 years, 8 months

1
0
0 0

EBBR call today Feb 27

by Vincent Stehlé

Hi, We will have an EBBR call[1] today at 15h UTC/BST. On the agenda[2]: - Review the pull requests[3]: + Pull request #102: File Format For Storing EFI Variables (Heinrich) + Pull request #103: Require capsule update "on disk" and corresponding variables Feel free to add to the agenda, directly on the wiki page or by e-mail. We can use this pad[4] 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://github.com/ARM-software/ebbr/pulls [4]: https://mensuel.framapad.org/p/ebbr-call-of-feb-27-9zjk

2 years, 8 months

1
0
0 0

No DT call on Feb 20

by Bill Mills

All, Monday Feb 20 is a US holiday. We won't have a meeting. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

2 years, 8 months

1
0
0 0

EBBR call today Feb 13

by Vincent Stehlé

Hi, We will have an EBBR call[1] today at 15h UTC/BST. On the agenda[2] today: - SetVariable() at runtime for boards that store EFI variables on an RPMB 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-feb-13-9za9?lang=en

2 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture