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

27 Oct 2021

      Hi Simon,
Le mer. 27 oct. 2021 à 20:33, Simon Glass sjg@chromium.org a écrit :
...
Hi François,
On Wed, 27 Oct 2021 at 09:38, François Ozog francois.ozog@linaro.org
wrote:
...
Hi Simon,
On Wed, 27 Oct 2021 at 16:13, Simon Glass sjg@chromium.org wrote:
...
Hi François,
On Tue, 26 Oct 2021 at 09:57, François Ozog francois.ozog@linaro.org
wrote:
...
...
...
On Tue, 26 Oct 2021 at 17:27, Simon Glass sjg@chromium.org wrote:
...
Hi François,
On Tue, 26 Oct 2021 at 08:31, François Ozog <
francois.ozog@linaro.org> wrote:
...
...
...
...
...
Hi Simon,
On Tue, 26 Oct 2021 at 02:25, Simon Glass sjg@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:

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.ht...
...
...
...
Bindings:
for FCONF:
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_pr...
...
...
...
for FF-A:
https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-b...
...
...
...
For chain-of-trust:
https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.ht...
...
...
...
For some code:
https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fipto...
...
...
...
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?
...
...
...

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...
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@linaro.org | Skype: ffozog