On Wed, Oct 27, 2021 at 05:38:28PM +0200, François Ozog wrote: > Hi Simon, > > On Wed, 27 Oct 2021 at 16:13, Simon Glass <s...@chromium.org> wrote: > > > Hi François, > > > > On Tue, 26 Oct 2021 at 09:57, François Ozog <francois.o...@linaro.org> > > wrote: > > > > > > > > > > > > On Tue, 26 Oct 2021 at 17:27, Simon Glass <s...@chromium.org> wrote: > > >> > > >> Hi François, > > >> > > >> On Tue, 26 Oct 2021 at 08:31, François Ozog <francois.o...@linaro.org> > > wrote: > > >> > > > >> > Hi Simon, > > >> > > > >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass <s...@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)
What relationship does this device tree that OP-TEE is using itself bear to the one is will pass to the OS? -- Tom
signature.asc
Description: PGP signature
