[PATCH v5 02/26] doc: Add documentation about devicetree usage

Tue Nov 2 15:53:48 CET 2021

Hi François,

On Fri, 29 Oct 2021 at 11:07, François Ozog <francois.ozog at linaro.org> wrote:
>
> Hi Simon
>
> (I keep getting messages about delivery problems so I don't know what
> went through or not)
>
>

I got this one, anyway.

> On Wed, 27 Oct 2021 at 21:52, Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Ilias,
> >
> > On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas
> > <ilias.apalodimas at linaro.org> wrote:
> > >
> > > On Wed, 27 Oct 2021 at 21:33, Simon Glass <sjg at chromium.org> wrote:
> > > >
> > > > Hi François,
> > > >
> > > > On Wed, 27 Oct 2021 at 09:38, François Ozog <francois.ozog at linaro.org> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Wed, 27 Oct 2021 at 16:13, Simon Glass <sjg at chromium.org> wrote:
> > > > >>
> > > > >> Hi François,
> > > > >>
> > > > >> On Tue, 26 Oct 2021 at 09:57, François Ozog <francois.ozog at linaro.org> wrote:
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On Tue, 26 Oct 2021 at 17:27, Simon Glass <sjg at chromium.org> wrote:
> > > > >> >>
> > > > >> >> Hi François,
> > > > >> >>
> > > > >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog <francois.ozog at linaro.org> wrote:
> > > > >> >> >
> > > > >> >> > Hi Simon,
> > > > >> >> >
> > > > >> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg at chromium.org> wrote:
> > > > >> >> >>
> > > > >> >> >> At present some of the ideas and techniques behind devicetree in U-Boot
> > > > >> >> >> are assumed, implied or unsaid. Add some documentation to cover how
> > > > >> >> >> devicetree is build, how it can be modified and the rules about using
> > > > >> >> >> the various CONFIG_OF_... options.
> > > > >> >> >>
> > > > >>
> > > > >> [..]
> > > > >>
> > > > >> >> >> +Why not have two devicetrees?
> > > > >> >> >> +-----------------------------
> > > > >> >> >> +
> > > > >> >> >> +Setting aside the argument for restricting U-Boot from having its own nodes and
> > > > >> >> >> +properties, another idea proposed is to have two devicetrees, one for the
> > > > >> >> >> +U-Boot-specific bits (here called `special`) and one for everything else (here
> > > > >> >> >> +called `linux`).
> > > > >> >> >> +
> > > > >> >> >> +On the positive side, it might quieten the discussion alluded to in the section
> > > > >> >> >> +above. But there are many negatives to consider and many open questions to
> > > > >> >> >> +resolve.
> > > > >> >> >> +
> > > > >> >> >> +- **Bindings** - Presumably the special devicetree would have its own bindings.
> > > > >> >> >> +  It would not be necessary to put a `u-boot,` prefix on anything. People coming
> > > > >> >> >> +  across the devicetree source would wonder how it fits in with the Linux
> > > > >> >> >> +  devicetree.
> > > > >> >> >> +
> > > > >> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This
> > > > >> >> >> +  would need to be expanded to support two trees. Features which need to access
> > > > >> >> >> +  both (such as a device driver which reads the special devicetree to get some
> > > > >> >> >> +  configuration info) could become quite confusing to read and write.
> > > > >> >> >> +
> > > > >> >> >> +- **Merging** - Can the two devicetree be merged if a platform desires it? If
> > > > >> >> >> +  so, how is this managed in tooling? Does it happen during the build, in which
> > > > >> >> >> +  case they are not really separate at all. Or does U-Boot merge them at
> > > > >> >> >> +  runtime, in which case this adds time and memory?
> > > > >> >> >> +
> > > > >> >> >> +- **Efficiency** - A second device tree adds more code and more code paths. It
> > > > >> >> >> +  requires that both be made available to the code in U-Boot, e.g. via a
> > > > >> >> >> +  separate pointer or argument or API. Overall the separation would certainly
> > > > >> >> >> +  not speed up U-Boot, nor decrease its size.
> > > > >> >> >> +
> > > > >> >> >> +- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for
> > > > >> >> >> +  U-Boot for a particular board. Would we use these same files for the special
> > > > >> >> >> +  devicetree?
> > > > >> >> >> +
> > > > >> >> >> +- **Complexity** - Two devicetrees complicates the build system since it must
> > > > >> >> >> +  build and package them both. Errors must be reported in such a way that it
> > > > >> >> >> +  is obvious which one is failing.
> > > > >> >> >> +
> > > > >> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model
> > > > >> >> >> +  are currently placed in the nodes they relate to. How would these tags
> > > > >> >> >> +  reference a node that is in a separate devicetree? What extra validation would
> > > > >> >> >> +  be needed?
> > > > >> >> >> +
> > > > >> >> >> +- **Storage** - How would the two devicetrees be stored in the image? At present
> > > > >> >> >> +  we simply concatenate the U-Boot binary and the devicetree. We could add the
> > > > >> >> >> +  special devicetree before the Linux one, so two are concatenated, but it is
> > > > >> >> >> +  not pretty. We could use binman to support more complex arrangements, but only
> > > > >> >> >> +  some boards use this at present, so it would be a big change.
> > > > >> >> >> +
> > > > >> >> >> +- **API** - How would another project provide two devicetree files to U-Boot at
> > > > >> >> >> +  runtime? Presumably this would just be too painful. But if it doesn't, it
> > > > >> >> >> +  would be unable to configure run-time features of U-Boot during the boot.
> > > > >> >> >> +
> > > > >> >> >> +- **Confusion** - No other project has two devicetrees. U-Boot would be in the
> > > > >> >> >> +  unfortunate position of having to describe this fact to new users, along with
> > > > >> >> >> +  the (arguably contrived) reason for the arrangement.
> > > > >> >> >> +
> > > > >> >> >
> > > > >> >> > False:
> > > > >> >> > 1) projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes.
> > > > >> >>
> > > > >> >> Can you provided a link and I can update this.
> > > > >> >
> > > > >> > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> > > > >> > Bindings:
> > > > >> > for FCONF: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_properties.html
> > > > >> > for FF-A: https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
> > > > >> > For chain-of-trust: https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.html
> > > > >> >
> > > > >> > For some code:
> > > > >> > https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fiptool/tbbr_config.c
> > > > >> > From there you can wander and see how dynamic config sections of the FIP can contain component specific DTs.
> > > > >> > U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
> > > > >>
> > > > >> OK I can mention that TF-A supports multiple devicetrees if you like,
> > > > >> but I'm not sure we are talking about the same thing.
> > > > >>
> > > > > If I take a possible scenario: OP-TEE to deal with 3 different device trees:
> > > > > - the one that will be passed to the OS and for which it may want to do some fixups
> > > > > - the one that it is using to run (it may have secure devices that are entirely not visible to any normal world OS)
> > > > > - the one that it gets from the FIP and contains runtime configuration parameters, accessed through FCONF library)
> > > > >
> > > > >>
> > > > >> U-Boot also supports multiple devicetrees in the build - e.g. SPL and
> > > > >> U-Boot proper. With binman you can create several copies of them for
> > > > >> use with A/B boot, for example. But only one is used as a control DTB
> > > > >> by a particular U-Boot phase at a time. Do you see what I mean?
> > > > >>
> > > > >> >>
> > > > >> >> > 2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system
> > > > >> >> > As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT.
> > > > >> >> > If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
> > > > >> >>
> > > > >> >> I have gone to great efforts to document things here, as they work in
> > > > >> >> U-Boot today. As you know, U-Boot supports separate control and active
> > > > >> >> devicetrees.
> > > > >> >
> > > > >> > I don't know what is an active device tree. Is it the device tree to be passed to OS?
> > > > >>
> > > > >> Yes that's right.
> > > > >>
> > > > >> >>
> > > > >> >> But if you are wanting to change to multiple control
> > > > >> >> trees within U-Boot, I'd say the answer is "no, thank you".
> > > > >> >
> > > > >> > I see only one control DT.
> > > > >>
> > > > >> OK good.
> > > > >>
> > > > >> > There is a possibility to store it securely in NT_FW_CONFIG section of a FIP. it also has associated signature plus hash mechanisms to attest authenticity of  it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes).
> > > > >>
> > > > >> What does NT mean? I suppose FW means firmware.
> > > > >
> > > > > Non Trusted; it means normal world as opposed to secure world.
> > > > > It feels unfortunate to say non trusted while it is trusted but running outside secure world ;-)
> > > >
> > > > OK, good, so long as it doesn't mean Windows NT I am happy.
> > > >
> > > > >>
> > > > >>
> > > > >> It doesn't really matter where it is stored, so long as U-Boot can access it.
> > > > >>
> > > > >> > You can certain have a similar mechanism for binman.
> > > > >>
> > > > >> Note that binman is a packaging tool. Perhaps you should add FIP
> > > > >> support to it if FIP is going to be required too now?
> > > > >>
> > > > > There may be a need for a FIP explanation. I'll check with other guys to propose text.
> > > >
> > > > I mean add an entry type to binman for FIP. It supports CBFS already,
> > > > for example.
> > > >
> > > > >
> > > > >>
> > > > >> What I would like, to package up the firmware for ANY board, after all
> > > > >> the building is done in various projects:
> > > > >>
> > > > >> binman -b <board>
> > > > >>
> > > > > FIP deals with a number of firmwares like the SCP and MCP ones running on other micro-controllers of a board.
> > > > > So in a sense it is an arm targeted tool.
> > > > > If you want to package firmware for arm boards with binman you will have to deal with those firmwares as well as secure world and its trusted services as secure partitions that are being developed (including when virtualization is in operation in the secure world).
> > > > > So in a word, trying to do this is a big undertaking, but you can try.
> > > >
> > > > Binman supports adding firmware for microcontrollers. For example, see here:
> > > >
> > > > https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/dts/flashmap-16mb-x86-rw.dtsi#L64
> > > >
> > > > That is a Chrome OS EC binary, one of three in the image.
> > > >
> > > > This is not ARM-specific. That image is actually for x86 Apollo Lake.
> > > >
> > > > > In a short term future (see Alibaba and Marvell announcements) you will have to deal with Arm v9 realms and associated firmware.
> > > >
> > > > Why me? Perhaps Linaro could take this on instead of working in a
> > > > separate tool and domain? You guys could really pull things together
> > > > and reduce the fragmentation, if you took it on.
> > > >
> > > > Honestly it is hard enough to even get Linaro people to write a test
> > > > for code they have written. What gives?
> > >
> > > That's completely inaccurate.  We've added selftests for *every*
> > > single feature we've sent for EFI up to now.  Functionality wise the
> > > past 2 years we've added
> > > - EFI variables
> > > - EFI secure boot
> > > - capsule updates
> > > - initrd loading
> > > - efi TCG protocol
> > > - ESRT tables
> > > - RNG protocol
> > >
> > > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests
> > > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi()
> > > 1170fee695197 efi_selftest: fix variables test for GetNextVariableName()
> > > ce62b0f8f45f1 test/py: Fix efidebug related tests
> > > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule
> > > de489d82e3189 test: test the ESRT creation
> > > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test
> > > e1174c566a61c test/py: efi_secboot: add test for intermediate certificates
> > > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
> > >
> > > and I am pretty sure I am forgetting more on functionality and selftests.
> > >
> > > So basically we've either contributed  new selftests for *everything*
> > > we've or fixed the existing ones.  The only thing that's not merged is
> > > the TCG selftests which are on upstream review.
> >
> > Er, I didn't say or mean that no tests were written, just that there
> > is too much push-back on it. Heinrich put a huge amount of effort into
> > the tests and basically created a strong base for it. Congrats and
> > huge kudos to him. As to Linaro, no offence intended, and it is great
> > that all these tests have been added. Thank you for your efforts and
> > it is very helpful. But I think you miss my point. Or perhaps you
> > don't even agree with it? I sent an email about this on one patch just
> > a day or two ago.
> >
> > As to the leadership side (my bigger point), Linaro is leading us all
> > down this fragmented path, with TF-A, FIP, more and more binaries and
> > larger firmware diagrams. Or do you disagree with that too?
> You seem to picture the role of the firmware to *only* to boot an operating
> system. I would be surprised to teach you that secure world is a world
> of its own
> that need to be orchestrated and hosts business related applications that stay
> available after U-Boot has disappeared from memory
> (OK with UEFI runtime services it stills occupies some space but
>  it should be mostly inactive as Linux own devices - let's not comment
> on this particular aspect).
> As U-Boot has no code for that world, creating another code base would
> actually create fragmentation.
> The mindset I sense from your comments reminds me when relational databases
> reached the market. People wanted to fit their business as
> "relational", killing other
> flavors of databases. It took at least a decade to get back to reason
> and think that
> more than one technology is needed with columnar databases,
> unstructured databases,
> KV databases...
> U-Boot is a "jewel" for what it does. Let's not try to expand it in areas where
> it is not meant to be and create fragmentation.
> >
> > I'm sorry if you find this a bit sharp. But someone needs to be
> > pointing these things out. I don't know who else is doing so. ARM
> > firmware has got noticeably more complicated and fragmented in the
> > last five years, hasn't it? What can Linaro do to address that?
> Linaro very creation was to avoid fragmentation in the arm ecosystem and I
> think we can be proud of what has been accomplished from Linus Torvalds
> comment on the state of kernel for arm.
> We are on a journey to do the same for the firmware.
> The first part was on the secure world firmware (that, again, do a lot of stuff
> for the secure world and happen to also load U-Boot).
> The second part is on the contract between U-Boot and the OS, hence our
> contributions in U-Boot.
>  I am
> > very happy to help and provide part of the solution, but it needs a
> > shared vision.
> This vision is entirely explained in Arm Cassini project with more firmware
> related details in SystemReady and further more details for embedded world
> in EBBR.
> You asked me what was the problem we are trying to solve:
> <session from FOSDEM 2021>
> "“A BSP is a badly-patched fork of an ancient U-Boot, a badly-patched
> fork of an ancient Linux, and a badly-patched fork of an ancient
> Yocto”
>  “… that, plus often a prehistoric compiler”
> </session from FOSDEM 2021>
> Adding features in U-Boot is only part of the solution: we need to
> have a process
> to keep boards bootable over time and that simplifies the firmware supply chain.
> I understand you don't like the choices, but that is an ecosystem
> choice, not my choice, not Linaro choice, and hopefully you will join
> us in making it happen.

I believe I am involved, at least. I do make time to engage on a call
most weeks. As you say, we don't agree on all the choices. I think the
areas of concern I have are devicetree (several issues which I hope we
are making progress on), proliferation of binaries and complexity of
packaging.

>
> >
> > It's not even just a Linaro/ARM problem. On the x86 side it is fast
> > becoming a living nightmare.
> >
> > Perhaps the problem here is just the pandemic response and the
> > inability for people to get into a room and brainstorm / collaborate /
> > hack on ideas?
> I could not agree more. Mail exchanges tend to self inflate...
> I remember a BoF in a Connect with 20 people around the table talking
> about firmware update
> and finding a way to make anti-bricking standard across boards (see
> yet another effort of defragmentation:-)
> People started the session with "impossible" in mind, and we came out
> with a plan.
> Now we are close to have it. If we could be on the drawing board, I am
> sure you would immediately
> understand and make a better version of our authentication scheme for
> those updates..
> ..and pull the relevant patchset ;-)
> (sorry I could not resist pulling your leg at the end)
>  I know you have made big efforts to engage, Ilias. We
> > have spoken many times and I'm sure f2f would be easier.

OK, well let's hope it all works out. Rome wasn't built in a day. It
is an important goal.

Regards,
Simon