Hi François, On Fri, 29 Oct 2021 at 11:07, François Ozog <francois.o...@linaro.org> wrote: > > Hi Simon > > (I keep getting messages about delivery problems so I don't know what > went through or not) > >
I got this one, anyway. > On Wed, 27 Oct 2021 at 21:52, Simon Glass <s...@chromium.org> wrote: > > > > Hi Ilias, > > > > On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas > > <ilias.apalodi...@linaro.org> wrote: > > > > > > 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. > > > > Er, I didn't say or mean that no tests were written, just that there > > is too much push-back on it. Heinrich put a huge amount of effort into > > the tests and basically created a strong base for it. Congrats and > > huge kudos to him. As to Linaro, no offence intended, and it is great > > that all these tests have been added. Thank you for your efforts and > > it is very helpful. But I think you miss my point. Or perhaps you > > don't even agree with it? I sent an email about this on one patch just > > a day or two ago. > > > > As to the leadership side (my bigger point), Linaro is leading us all > > down this fragmented path, with TF-A, FIP, more and more binaries and > > larger firmware diagrams. Or do you disagree with that too? > You seem to picture the role of the firmware to *only* to boot an operating > system. I would be surprised to teach you that secure world is a world > of its own > that need to be orchestrated and hosts business related applications that stay > available after U-Boot has disappeared from memory > (OK with UEFI runtime services it stills occupies some space but > it should be mostly inactive as Linux own devices - let's not comment > on this particular aspect). > As U-Boot has no code for that world, creating another code base would > actually create fragmentation. > The mindset I sense from your comments reminds me when relational databases > reached the market. People wanted to fit their business as > "relational", killing other > flavors of databases. It took at least a decade to get back to reason > and think that > more than one technology is needed with columnar databases, > unstructured databases, > KV databases... > U-Boot is a "jewel" for what it does. Let's not try to expand it in areas > where > it is not meant to be and create fragmentation. > > > > I'm sorry if you find this a bit sharp. But someone needs to be > > pointing these things out. I don't know who else is doing so. ARM > > firmware has got noticeably more complicated and fragmented in the > > last five years, hasn't it? What can Linaro do to address that? > Linaro very creation was to avoid fragmentation in the arm ecosystem and I > think we can be proud of what has been accomplished from Linus Torvalds > comment on the state of kernel for arm. > We are on a journey to do the same for the firmware. > The first part was on the secure world firmware (that, again, do a lot of > stuff > for the secure world and happen to also load U-Boot). > The second part is on the contract between U-Boot and the OS, hence our > contributions in U-Boot. > I am > > very happy to help and provide part of the solution, but it needs a > > shared vision. > This vision is entirely explained in Arm Cassini project with more firmware > related details in SystemReady and further more details for embedded world > in EBBR. > You asked me what was the problem we are trying to solve: > <session from FOSDEM 2021> > "“A BSP is a badly-patched fork of an ancient U-Boot, a badly-patched > fork of an ancient Linux, and a badly-patched fork of an ancient > Yocto” > “… that, plus often a prehistoric compiler” > </session from FOSDEM 2021> > Adding features in U-Boot is only part of the solution: we need to > have a process > to keep boards bootable over time and that simplifies the firmware supply > chain. > I understand you don't like the choices, but that is an ecosystem > choice, not my choice, not Linaro choice, and hopefully you will join > us in making it happen. I believe I am involved, at least. I do make time to engage on a call most weeks. As you say, we don't agree on all the choices. I think the areas of concern I have are devicetree (several issues which I hope we are making progress on), proliferation of binaries and complexity of packaging. > > > > > It's not even just a Linaro/ARM problem. On the x86 side it is fast > > becoming a living nightmare. > > > > Perhaps the problem here is just the pandemic response and the > > inability for people to get into a room and brainstorm / collaborate / > > hack on ideas? > I could not agree more. Mail exchanges tend to self inflate... > I remember a BoF in a Connect with 20 people around the table talking > about firmware update > and finding a way to make anti-bricking standard across boards (see > yet another effort of defragmentation:-) > People started the session with "impossible" in mind, and we came out > with a plan. > Now we are close to have it. If we could be on the drawing board, I am > sure you would immediately > understand and make a better version of our authentication scheme for > those updates.. > ..and pull the relevant patchset ;-) > (sorry I could not resist pulling your leg at the end) > I know you have made big efforts to engage, Ilias. We > > have spoken many times and I'm sure f2f would be easier. OK, well let's hope it all works out. Rome wasn't built in a day. It is an important goal. Regards, Simon
