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

Wed Oct 27 20:32:57 CEST 2021

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?

>>
>> >>
>> >> If there
>> >> is a use case for that, please can you be specific about what we
>> >> cannot do with a combined devicetree?

Regards,
SImon