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