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

Reply via email to