On Wed, 27 Oct 2021 at 21:33, Simon Glass <s...@chromium.org> wrote: > > Hi François, > > On Wed, 27 Oct 2021 at 09:38, François Ozog <francois.o...@linaro.org> 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) > > - 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. Regards /Ilias
