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

[François Ozog]

Hi Simon,

Le mer. 27 oct. 2021 à 20:33, Simon Glass <sjg at chromium.org> a écrit :

> 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.
>
Well, what happens in the secure world is getting pretty complex. TFA
solves it elegantly so there is no incentive in maintaining a separate code
base to do the same.
If I picture things in different way, I would say that it the past pre
U-Boot proper was representing 20 and U-Boot proper 80. In new schemes, pre
U-Boot can be said 80 and U-Boot proper 20.

>
> Honestly it is hard enough to even get Linaro people to write a test
> for code they have written. What gives?
>
> >>
> >> >>
> >> >> If there
> >> >> is a use case for that, please can you be specific about what we
> >> >> cannot do with a combined devicetree?
>
> Regards,
> SImon
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog