| Message ID | 20211026002344.405160-3-sjg@chromium.org |
|---|---|
| State | Changes Requested |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | fdt: Make OF_BOARD a boolean option | expand |
Hi Simon, > + [...] > +This is why `CONFIG_OF_SEPARATE` should always be used when building U-Boot. > +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot ELF > +image as rodata, meaning that it is hard to find it and it cannot increase in > +size. > + > +When modifying the devicetree, the different cases to consider are as follows: > + > +- CONFIG_OF_SEPARATE > + This is easy, described above. Just change, replace or rebuild the > + devicetree so it suits your needs, then rerun binman or redo the `cat` > + operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb` > + > +- CONFIG_OF_EMBED > + This is tricky, since the devicetree cannot easily be located. If the EFL > + file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can be > + examined to find it. While it is possible to contract the file, it is not > + possible to expand the file since that would involve re-linking > + > +- CONFIG_OF_BOARD > + This is a board-specific situation, so needs to be considered on a > + case-by-case base. The devicetree must be modified so that the correct > + one is provided to U-Boot. How this is done depends entirely on the > + implementation of this option for the board. It might require injecting the > + changes into a different project somehow using tooling available there, or > + it might involve merging an overlay file at runtime to obtain the desired > + result. I thought this document was trying to describe the current situation in U-Boot. If so, the current CONFIG_OF_BOARD usage is far from what we have here. [...] Regards /Ilias
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. > > Signed-off-by: Simon Glass <sjg@chromium.org> > Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> > --- > This patch attracted quite a bit of discussion here: > > > https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-sjg@chromium.org/ > > I have not included the text suggested by François. While I agree that > it would be useful to have an introduction in this space, I do not agree > that we should have two devicetrees or that U-Boot should not have its own > things in the devicetree, so it is not clear to me what we should actually > write. > > The 'Devicetree Control in U-Boot' docs were recently merged and these > provide some base info, for now. > > Changes in v5: > - Bring into the OF_BOARD series > - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > - Refer to the 'control' DTB in the first paragraph > - Use QEMU instead of qemu > > Changes in v3: > - Clarify the 'bug' refered to at the top > - Reword 'This means that there' paragraph to explain U-Boot-specific > things > - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > > Changes in v2: > - Fix typos per Sean (thank you!) and a few others > - Add a 'Use of U-Boot /config node' section > - Drop mention of dm-verity since that actually uses the kernel cmdline > - Explain that OF_BOARD will still work after these changes (in > 'Once this bug is fixed...' paragraph) > - Expand a bit on the reason why the 'Current situation' is bad > - Clarify in a second place that Linux and U-Boot use the same devicetree > in 'To be clear, while U-Boot...' > - Expand on why we should have rules for other projects in > 'Devicetree in another project' > - Add a comment as to why devicetree in U-Boot is not 'bad design' > - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > - Rewrite 'Devicetree generated on-the-fly in another project' to cover > points raised on v1 > - Add 'Why does U-Boot have its nodes and properties?' > - Add 'Why not have two devicetrees?' > > doc/develop/devicetree/dt_update.rst | 556 +++++++++++++++++++++++++++ > doc/develop/devicetree/index.rst | 1 + > 2 files changed, 557 insertions(+) > create mode 100644 doc/develop/devicetree/dt_update.rst > > diff --git a/doc/develop/devicetree/dt_update.rst > b/doc/develop/devicetree/dt_update.rst > new file mode 100644 > index 00000000000..3d4902e3592 > --- /dev/null > +++ b/doc/develop/devicetree/dt_update.rst > @@ -0,0 +1,556 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > + > +Updating the devicetree > +======================= > + > +U-Boot uses devicetree for runtime configuration and storing required > blobs or > +any other information it needs to operate. This is called the 'control' > +devicetree since it controls U-Boot. It is possible to update the control > +devicetree separately from actually building U-Boot. This provides a good > degree > +of control and flexibility for firmware that uses U-Boot in conjunction > with > +other project. > + > +There are many reasons why it is useful to modify the devicetree after > building > +it: > + > +- Configuration can be changed, e.g. which UART to use > +- A serial number can be added > +- Public keys can be added to allow image verification > +- Console output can be changed (e.g. to select serial or vidconsole) > + > +This section describes how to work with devicetree to accomplish your > goals. > + > +See also :doc:`../devicetree/control` for a basic summary of the available > +features. > + > + > +Devicetree source > +----------------- > + > +Every board in U-Boot must include a devicetree sufficient to build and > boot > +that board on suitable hardware (or emulation). This is specified using > the > +`CONFIG DEFAULT_DEVICE_TREE` option. > + > + > +Current situation (October 2021) > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be > empty, > +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an > enormous > +amount of confusion and some wasted effort. This was not intended. > Support for > +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. > + > +Some of the problems created are: > + > +- It is not obvious that the devicetree is coming from another project > + > +- There is no way to see even a sample devicetree for these platform in > U-Boot, > + so it is hard to know what is going on, e.g. which devices are typically > + present > + > +- The other project may not provide a way to support U-Boot's > requirements for > + devicetree, such as the /config node. Note: On the U-Boot mailing > linst, this > + was only discovered after weeks of discussion and confusion > + > +- For QEMU specifically, consulting two QEMU source files is required, > for which > + there are no references in U-Boot documentation. The code is generating > a > + devicetree, but it is not clear what controls affect this generation. > + > +Specifically on the changes in U-Bootm `CONFIG_OF_BOARD` was added in > +rpi_patch_ for Raspberry Pi, which does have an in-tree devicetree, but > this > +feature has since been used for boards that don't > + > +Once this bug is fixed, CONFIG_OF_BOARD will override (at runtime) the > +evicetree suppled with U-Boot, but will otherwise use CONFIG_OF_SEPARATE > for the > +in-tree build. So these two will become options, moving out of the > 'choice' in > +`dts/Kconfig`. > + > +This means that there is a basic devicetree build in the U-Boot tree, for > +build-testing, consistency and documentation purposes, but at runtime > U-Boot can > +accept its devicetree from another source. The in-tree devicetree may > contain > +U-Boot-specific features (in u-boot*.dtsi files) and this may prove > useful for > +the other project, so it can ensure that U-Boot functions correctly and > supports > +all its expected features. > + > +To be clear, while U-Boot has its own copy of the devicetree source for > each > +board, this must match the Linux source, perhaps with some u-boot.dtsi > +additions. The intent here is not to create a separate binding, just to > provide > +a representative devicetree in U-Boot. > + > +Offending boards are: > + > +- rpi_4 and rpi_4_32b (other rpi boards do have an in-tree devicetree) > +- qemu_arm64 > +- qemu_arm > +- qemu-ppce500 > +- qemu-riscv32 > +- qemu-riscv32_smode > +- qemu-riscv64 > +- qemu-riscv64_smode > + > +All of these need to have a devicetree added in-tree. This is targeted to > be > +fixed in the 2022.01 release. > + > + > +Building the devicetree > +----------------------- > + > +U-Boot automatically builds the devicetree for a board, from the > +`arch/<arch>/dts` directory. The Makefile in those directories has rules > for > +building devicetree files. It is preferable to avoid target-specific > rules in > +those files: i.e. all boards for a particular SoC should be built at once, > +where practical. Apart from simplifying the Makefile, this helps to > efficiently > +(and immediately) ensure that changes in one board's DT do not break > others that > +are related. Building devicetrees is fast, so performance is seldom a > concern > +here. > + > + > +Overriding the default devicetree > +--------------------------------- > + > +When building U-Boot, the `DEVICE_TREE` environment variable allows the > +default devicetree file to be overridden at build time. This can be > useful if > +modifications have to be made to the in-tree devicetree file, for the > benefit > +of a downstream build system. Note that the in-tree devicetree must be > +sufficient to build and boot, so this is not a way to bypass that > requirement. > + > + > +Modifying the devicetree after building > +--------------------------------------- > + > +While it is generally painful and hacky to modify the code or rodata of a > +program after it is built, in many cases it is useful to do so, e.g. to > add > +configuration information like serial numbers, enabling/disabling > features, etc. > + > +Devicetree provides a very nice solution to these problems since it is > +structured data and it is relatively easy to change it, even in binary > form > +(see fdtput). > + > +U-Boot takes care that the devicetree is easily accessible after the build > +process. In fact it is placed in a separate file called `u-boot.dtb`. If > the > +build system wants to modify or replace that file, it can do so. Then all > that > +is needed is to run `binman update` to update the file inside the image. > If > +binman is not used, then `u-boot-nodtb.bin` and the new `u-boot.dtb` can > simply > +be concatenated to achieve the desired result. U-Boot happily copes with > the > +devicetree growing or shrinking. > + > +The `u-boot.bin` image contains both pieces. While it is possible to > locate the > +devicetree within the image using the signature at the start of the file, > this > +is a bit messy. > + > +This is why `CONFIG_OF_SEPARATE` should always be used when building > U-Boot. > +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the > U-Boot ELF > +image as rodata, meaning that it is hard to find it and it cannot > increase in > +size. > + > +When modifying the devicetree, the different cases to consider are as > follows: > + > +- CONFIG_OF_SEPARATE > + This is easy, described above. Just change, replace or rebuild the > + devicetree so it suits your needs, then rerun binman or redo the `cat` > + operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb` > + > +- CONFIG_OF_EMBED > + This is tricky, since the devicetree cannot easily be located. If the > EFL > + file is available, then the _dtb_dt_begin and __dtb_dt_end symbols > can be > + examined to find it. While it is possible to contract the file, it is > not > + possible to expand the file since that would involve re-linking > + > +- CONFIG_OF_BOARD > + This is a board-specific situation, so needs to be considered on a > + case-by-case base. The devicetree must be modified so that the correct > + one is provided to U-Boot. How this is done depends entirely on the > + implementation of this option for the board. It might require > injecting the > + changes into a different project somehow using tooling available > there, or > + it might involve merging an overlay file at runtime to obtain the > desired > + result. > + > + > +Use of U-Boot /config node > +-------------------------- > + > +A common problem with firmware is that many builds are needed to deal > with the > +slight variations between different, related models. For example, one > model may > +have a TPM and another may not. Devicetree provides an excellent solution > to > +this problem, in that the devicetree to actually use on a platform can be > +injected in the factory based on which model is being manufactured at the > time. > + > +A related problem causing build proliferation is dealing with the > differences > +between development firmware, developer-friendly firmware (e.g. with all > +security features present but with the ability to access the command > line), > +test firmware (which runs tests used in the factory), final production > firmware > +(before signing), signed firmware (where the signatures have been > inserted) and > +the like. Ideally all or most of these should use the same U-Boot build, > with > +just some options to determine the features available. For example, being > able > +to control whether the UART console or JTAG are available, on any image, > is a > +great debugging aid. > + > +When the firmware consists of multiple parts, it is helpful that all > operate > +the same way at runtime, regardless of how they were built. This can be > achieved > +by passing the runtime configuration (e.g. 'enable UART console) along > the chain > +through each firmware stage. It is frustrating to have to replicate a bug > on > +production firmware which does happen on developer firmware, because they > are > +completely different builds. > + > +The /config node provides useful functionality for this. It allows the > different > +controls to be 'factored out' of the U-Boot binary, so they can be > controlled > +separately from the initial source-code build. The node can be easily > updated by > +a build or factory tool and can control various features in U-Boot. It is > +similar in concept to a Kconfig option, except that it can be changed > after > +U-Boot is built. > + > +The /config node is similar in concept to the `/chosen node`_ except that > it is > +for passing information *into* firmware instead of from firmware to the > +Operating System. Also, while Linux has a (sometimes extremely long) > command > +line, U-Boot does not support this. The devicetree provides a more > structured > +approach in any case. > + > + > +Devicetree in another project > +----------------------------- > + > +In some cases U-Boot receive its devicetree at runtime from a program > that calls > +it. For example ARM's Trusted Firmware A (`TF-A`_) may have a devicetree > that it > +passes to U-Boot. This overrides any devicetree build by U-Boot. When > packaging > +the firmware, the U-Boot devicetree may in fact be left out if it can be > +guaranteed that it will receive one from another project. > + > +In this case, the devicetree in the other project must track U-Boot's use > of > +device tree, for the following reasons: > + > +- U-Boot only has one devicetree. See `Why not have two devicetrees?`_. > +- For a consistent firmware build, decisions made in early stages should > be > + communicated to later ones at runtime. For example, if the serial > console is > + enabled in an early stage, it should be enabled in U-Boot too. > +- U-Boot is quite capable of managing its own copy of the devicetree. If > + another project wants to bypass this (often for good reason), it is > reasonable > + that it should take on the (fairly small) requirements that U-Boot > features > + that rely on devicetree are still available > +- The point here is not that *U-Boot needs this extra node*, or *U-Boot > needs > + to have this public key*. These features are present in U-Boot in > service of > + the entire firmware system. If the U-Boot features are used, but cannot > be > + supported in the normal way, then there is pressure to implement these > + features in other ways. In the end, we would have a different mechanism > for > + every other project that uses U-Boot. This introduces duplicate ways of > doing > + the same thing, needlessly increases the complexity of the U-Boot > source code, > + forces authors to consider parallel implementations when writing new > features, > + makes U-Boot harder to test, complicates documentation and confuses the > + runtime flow of U-Boot. If every board did things its own way rather > than > + contributing to the common code, U-Boot would lose a lot of its > cross-platform > + value. > + > +The above does not indicate *bad design* within U-Boot. Devicetree is a > core > +component of U-Boot and U-Boot makes use of it to the full. It solves a > myriad > +of problems that would otherwise need their own special C struct, binary > format, > +special property, tooling for viewing and updating, etc. > + > +Specifically, the other project must provide a way to add configuration > and > +other information to the devicetree for use by U-Boot, such as the > /config node. > +Note that the U-Boot in-tree devicetree source must be sufficient to > build and > +boot, so this is not a way to bypass that requirement. > + > +If binman is used, the devicetree source in U-Boot must contain the binman > +definition so that a valid image can be build. This helps people discover > what > +other firmware components are needed and seek out appropriate > documentation. > + > +If verified boot is used, the project must provide a way to inject a > public key, > +certificate or other material into the U-Boot devicetree so that it is > available > +to U-Boot at runtime. See `Signing with U-Boot devicetree`_. This may be > +through tooling in the project itself or by making use of U-Boot's > tooling. > + > + > +Devicetree generated on-the-fly in another project > +-------------------------------------------------- > + > +In some rare cases, another project may wish to create a devicetree for > U-Boot > +entirely on-the-fly, then pass it to U-Boot at runtime. The only known > example > +of this at the time of writing (2021) is QEMU, for ARM (`QEMU ARM`_) and > +RISC-V (`QEMU RISC-V`_). > + > +In effect, when the board boots, U-Boot is *downstream* of the other > project. > +It is entirely reliant on that project for its correct operation. > + > +This does not mean to imply that the other project is creating its own, > +incompatible devicetree. In fact QEMU generates a valid devicetree which > is > +suitable for both U-Boot and Linux. It is quite normal for a devicetree > to be > +present in flash and be made available to U-Boot at runtime. What matters > is > +where the devicetree comes from. If the other project builds a devicetree > for > +U-Boot then it needs to support adding the things needed by U-Boot > features. > +Without them, for example: > + > +- U-Boot may not boot because too many devices are enabled before > relocation > +- U-Boot may not have access to the developer or production public keys > used for > + signing > +- U-Boot may not support controlling whether the console is enabled > +- U-Boot may not be know which MMC device to boot from > +- U-Boot may not be able to find other firmware components that it needs > to load > + > +Normally, supporting U-Boot's features is trivial, since the devicetree > compiler > +(dtc) can compile the source, including any U-Boot pieces. So the burden > is > +extremely low. > + > +In this case, the devicetree in the other project must track U-Boot's use > of > +device tree, so that it remains compatible. See `Devicetree in another > project`_ > +for reasons why. > + > +If a particular version of the project is needed for a particular version > of > +U-Boot, that must be documented in both projects. > + > +Further, it must provide a way to add configuration and other information > to > +the devicetree for use by U-Boot, such as the `/config` node and the tags > used > +by driver model. Note that the U-Boot in-tree devicetree must be > sufficient to > +build and boot, so this is not a way to bypass that requirement. > + > +More specifically, tooling or command-line arguments must provide a way to > +add a `/config` node or items within that node, so that U-Boot can > receive a > +suitable configuration. It must provide a way of adding `u-boot,dm-...` > tags for > +correct operation of driver model. These options can then be used as part > of the > +build process, which puts the firmware image together. For binman, a way > must be > +provided to add the binman definition into the devicetree in the same way. > + > +One way to do this is to allow a .dtsi file to be merged in with the > generated > +devicetree. > + > +Note that the burden goes both ways. If a new feature is added to U-Boot > which > +needs support in another project, then the author of the U-Boot patch > must add > +any required support to the other project. > + > + > +Passing the devicetree through to Linux > +--------------------------------------- > + > +Ideally U-Boot and Linux use the same devicetree source, even though it is > +hosted in separate projects. U-Boot adds some extra pieces, such as the > +`config/` node and tags like `u-boot,dm-spl`. Linux adds some extra > pieces, such > +as `linux,default-trigger` and `linux,code`. This should not interfere > with > +each other. > + > +In principle it is possible for U-Boot's control devicetree to be passed > to > +Linux. This is, after all, one of the goals of devicetree and the original > +Open Firmware project, to have the firmware provide the hardware > description to > +the Operating System. > + > +For boards where this approach is used, care must be taken. U-Boot > typically > +needs to 'fix up' the devicetree before passing it to Linux, e.g. to add > +information about the memory map, about which serial console is used, > provide > +the kernel address space layout randomization (KASLR) seed or select > whether the > +console should be silenced for a faster boot. > + > +Fix-ups involve modifying the devicetree. If the control devicetree is > used, > +that means the control devicetree could be modified, while U-Boot is > using it. > +Removing a device and reinserting it can cause problems if the devicetree > offset > +has changed, for example, since the device will be unable to locates its > +devicetree properties at the expected devicetree offset, which is a fixed > +integer. > + > +To deal with this, it is recommended to employ one or more of the > following > +approaches: > + > +- Make a copy of the devicetree and 'fix up' the copy, leaving the control > + devicetree alone > +- Enable `CONFIG_OF_LIVE` so that U-Boot makes its own copy of the > devicetree > + during relocation; fixups then happen on the original flat tree > +- Ensure that fix-ups happen after all loading has happened and U-Boot has > + completed image verification > + > +In practice,the last point is typically observed, since boot_prep_linux() > is > +called just before jumping to Linux, long after signature verification, > for > +example. But it is important to make sure that this line is not blurred, > +particularly if untrusted user data is involved. > + > + > +Devicetree use cases that must be supported > +------------------------------------------- > + > +Regardless of how the devicetree is provided to U-Boot at runtime, various > +U-Boot features must be fully supported. This section describes some of > these > +features and the implications for other projects. > + > +If U-Boot uses its own in-tree devicetree these features are supported > +automatically. > + > + > +Signing with U-Boot devicetree > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +U-Boot supports signing a payload so that it can be verified to have been > +created by a party owning a private key. This is called verified boot in > U-Boot > +(see doc/uImage.FIT/verified-boot.txt). > + > +Typically this works by creating a FIT and then running the `mkimage` > tool to > +add signatures for particular images. As part of this process, `mkimage` > writes > +a public key to the U-Boot devicetree, although this can be done > separately. > +See fdt_add_pubkey_ for patches for a suitable tool, for example. > + > +As with all configuration information, if another project is providing the > +devicetree to U-Boot, it must provide a way to add this public key into > the > +devicetree it passes to U-Boot. This could be via a tooling option, > making use > +of `mkimage`, or allowing a .dtsi file to be merged in with what is > generated in > +the other project. > + > + > +Providing the binman image definition > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +In complex systems U-Boot must locate and make use of other firmware > components, > +such as images for the user interface, files containing peripheral > firmware, > +multiple copies of U-Boot for use with A/B boot, etc. U-Boot uses > +:doc:`Binman <../package/binman>` as a standard way of putting an image > +together. > + > +Typically this works by running binman with the devicetree as an input, to > +create the file image. Binman then outputs an updated devicetree which is > +packed in the firmware image, so U-Boot can access the binman definition > and > +locate all the components. > + > +As with all configuration information, if another project is providing the > +devicetree to U-Boot, it must provide a way to add this binman definition > into > +the devicetree it passes to U-Boot. This could be via a tooling option, > making > +use of `binman`, or alowing a .dtsi file to be merged in with what is > generated > +in the other project. > + > + > +Protecting the devicetree > +------------------------- > + > +U-Boot relies heavily on devicetree for correct operation. A corrupt or > invalid > +device can cause U-Boot to fail to start, behave incorrectly, crash (e.g. > if > +`CONFIG_OF_LIBFDT_ASSUME_MASK` is adjusted, or fail to boot an Operating > System. > +Within U-Boot, the devicetree is as important as any other part of the > source > +code. At ruuntime, the devicetree can be considered to be structured > rodata. > + > +With secure systems, care must be taken that the devicetree is valid: > + > +- If the code / rodata has a hash or signature, the devicetree should > also, if > + they are packaged separately. > +- If the code / rodata is write-protected when running, the devicetree > should be > + also. Note that U-Boot relocates its code and devicetree, so this is > not as > + simple as it sounds. U-Boot must write-protect these items after > relocating. > + > + > +Why does U-Boot have its nodes and properties? > +---------------------------------------------- > + > +See also :doc:`../devicetree/intro`. > + > +There has been pushback at the concept that U-Boot dares have its own > nodes and > +properties in the devicetree. > + > +Apart from these nodes and properties, U-Boot uses the same bindings as > Linux. > +A `u-boot.dtsi` file helps to keep U-Boot-specific changes in separate > files, > +making it easier to keep devicetree source files in U-Boot in sync with > Linux. > + > +As a counter-example, the Zephyr OS project takes a different approach. > It uses > +entirely different bindings, in general, making no effort to sync > devicetree > +source files with Linux. U-Boot strives to be compatible with Linux in a > number > +of ways, such as source code style and common APIs, to aid porting of code > +between the projects. Devicetree is another way where U-Boot and Linux > follow a > +similar approach. > + > +Fundamentally, the idea that U-Boot cannot have its own tags flies in the > face > +of the devicetree specification (see dtspec_), which says: > + > + Nonstandard property names should specify a **unique string prefix**, > such as > + a stock ticker symbol, identifying the name of the company **or > organization** > + that defined the property. Examples: > + > + - fsl,channel-fifo-len > + - ibm,ppc-interrupt-server#s > + - **linux**,network-index > + > +It is also fundamentally unbalanced. Linux has many tags of its own (some > 36 in > +version 5.13) and at least one Linux-specific node, even if you ignore > things > +like flash partitions which clearly provide configuration information to > Linux. > + > +Practically speaking there are many reasons why U-Boot has its own nodes > and > +properties. Some examples: > + > +- Binding every device before relocation even if it won't be used, > consumes time > + and memory: tags on each node can specify which are needed in SPL or > before > + relocation. Linux has no such constraints. > + > +- Requiring the full clock tree to be up and running just to get the > debug UART > + running is inefficient. It is also and self-defeating, since if that > much > + code is working properly, you probably don't need the debug UART. A > devicetree > + property to provide the UART input-clock frequency is a simple solution. > + > +- U-Boot does not have a user space to provide policy and configuration. > It > + cannot do what Linux does and run programs and look up filesystems to > figure > + out how to boot. > + > + > +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. 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. +- **Signing flow** - The current signing flow is simple as it involves > running > + `mkimage` with the U-Boot devicetree. This would have to be updated to > use the > + special devicetree. Some way of telling the user that they have done it > wrong > + would have to be invented. > + > +Overall, adding a second devicetree would create enormous confusion and > +complexity. It seems a lot cheaper to solve this by a change of attitude. > + > + > +.. _rpi_patch: > https://patchwork.ozlabs.org/project/uboot/patch/20170402082520.32546-1-deymo@google.com/ > +.. _`TF-A`: https://www.trustedfirmware.org/projects/tf-a > +.. _`QEMU ARM`: https://github.com/qemu/qemu/blob/master/hw/arm/virt.c > +.. _`QEMU RISC-V`: > https://github.com/qemu/qemu/blob/master/hw/riscv/virt.c > +.. _`/chosen node`: > https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt > +.. _fdt_add_pubkey: > https://patchwork.ozlabs.org/project/uboot/list/?series=157843&state=* > +.. _dtspec: https://www.devicetree.org/specifications/ > diff --git a/doc/develop/devicetree/index.rst > b/doc/develop/devicetree/index.rst > index fa5db3eb76e..b5b33dfea0f 100644 > --- a/doc/develop/devicetree/index.rst > +++ b/doc/develop/devicetree/index.rst > @@ -11,3 +11,4 @@ build-time and runtime configuration. > > intro > control > + dt_update > -- > 2.33.0.1079.g6e70778dc9-goog > >
Hi Ilias, On Tue, 26 Oct 2021 at 08:06, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > Hi Simon, > > > + > > [...] > > > +This is why `CONFIG_OF_SEPARATE` should always be used when building U-Boot. > > +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot ELF > > +image as rodata, meaning that it is hard to find it and it cannot increase in > > +size. > > + > > +When modifying the devicetree, the different cases to consider are as follows: > > + > > +- CONFIG_OF_SEPARATE > > + This is easy, described above. Just change, replace or rebuild the > > + devicetree so it suits your needs, then rerun binman or redo the `cat` > > + operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb` > > + > > +- CONFIG_OF_EMBED > > + This is tricky, since the devicetree cannot easily be located. If the EFL > > + file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can be > > + examined to find it. While it is possible to contract the file, it is not > > + possible to expand the file since that would involve re-linking > > + > > +- CONFIG_OF_BOARD > > + This is a board-specific situation, so needs to be considered on a > > + case-by-case base. The devicetree must be modified so that the correct > > + one is provided to U-Boot. How this is done depends entirely on the > > + implementation of this option for the board. It might require injecting the > > + changes into a different project somehow using tooling available there, or > > + it might involve merging an overlay file at runtime to obtain the desired > > + result. > > I thought this document was trying to describe the current situation in > U-Boot. If so, the current CONFIG_OF_BOARD usage is far from what we have > here. Can you be more specific? What is the difference here? Also see the doc update later in the series, after OF_BOARD becomes a bool option. Regards, SImon
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. >> >> Signed-off-by: Simon Glass <sjg@chromium.org> >> Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> >> --- >> This patch attracted quite a bit of discussion here: >> >> https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-sjg@chromium.org/ >> >> I have not included the text suggested by François. While I agree that >> it would be useful to have an introduction in this space, I do not agree >> that we should have two devicetrees or that U-Boot should not have its own >> things in the devicetree, so it is not clear to me what we should actually >> write. >> >> The 'Devicetree Control in U-Boot' docs were recently merged and these >> provide some base info, for now. >> >> Changes in v5: >> - Bring into the OF_BOARD series >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed >> - Refer to the 'control' DTB in the first paragraph >> - Use QEMU instead of qemu >> >> Changes in v3: >> - Clarify the 'bug' refered to at the top >> - Reword 'This means that there' paragraph to explain U-Boot-specific things >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs >> >> Changes in v2: >> - Fix typos per Sean (thank you!) and a few others >> - Add a 'Use of U-Boot /config node' section >> - Drop mention of dm-verity since that actually uses the kernel cmdline >> - Explain that OF_BOARD will still work after these changes (in >> 'Once this bug is fixed...' paragraph) >> - Expand a bit on the reason why the 'Current situation' is bad >> - Clarify in a second place that Linux and U-Boot use the same devicetree >> in 'To be clear, while U-Boot...' >> - Expand on why we should have rules for other projects in >> 'Devicetree in another project' >> - Add a comment as to why devicetree in U-Boot is not 'bad design' >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover >> points raised on v1 >> - Add 'Why does U-Boot have its nodes and properties?' >> - Add 'Why not have two devicetrees?' >> >> doc/develop/devicetree/dt_update.rst | 556 +++++++++++++++++++++++++++ >> doc/develop/devicetree/index.rst | 1 + >> 2 files changed, 557 insertions(+) >> create mode 100644 doc/develop/devicetree/dt_update.rst >> >> diff --git a/doc/develop/devicetree/dt_update.rst b/doc/develop/devicetree/dt_update.rst >> new file mode 100644 >> index 00000000000..3d4902e3592 >> --- /dev/null >> +++ b/doc/develop/devicetree/dt_update.rst >> @@ -0,0 +1,556 @@ >> +.. SPDX-License-Identifier: GPL-2.0+ >> + >> +Updating the devicetree >> +======================= >> + >> +U-Boot uses devicetree for runtime configuration and storing required blobs or >> +any other information it needs to operate. This is called the 'control' >> +devicetree since it controls U-Boot. It is possible to update the control >> +devicetree separately from actually building U-Boot. This provides a good degree >> +of control and flexibility for firmware that uses U-Boot in conjunction with >> +other project. >> + >> +There are many reasons why it is useful to modify the devicetree after building >> +it: >> + >> +- Configuration can be changed, e.g. which UART to use >> +- A serial number can be added >> +- Public keys can be added to allow image verification >> +- Console output can be changed (e.g. to select serial or vidconsole) >> + >> +This section describes how to work with devicetree to accomplish your goals. >> + >> +See also :doc:`../devicetree/control` for a basic summary of the available >> +features. >> + >> + >> +Devicetree source >> +----------------- >> + >> +Every board in U-Boot must include a devicetree sufficient to build and boot >> +that board on suitable hardware (or emulation). This is specified using the >> +`CONFIG DEFAULT_DEVICE_TREE` option. >> + >> + >> +Current situation (October 2021) >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty, >> +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an enormous >> +amount of confusion and some wasted effort. This was not intended. Support for >> +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. >> + >> +Some of the problems created are: >> + >> +- It is not obvious that the devicetree is coming from another project >> + >> +- There is no way to see even a sample devicetree for these platform in U-Boot, >> + so it is hard to know what is going on, e.g. which devices are typically >> + present >> + >> +- The other project may not provide a way to support U-Boot's requirements for >> + devicetree, such as the /config node. Note: On the U-Boot mailing linst, this >> + was only discovered after weeks of discussion and confusion >> + >> +- For QEMU specifically, consulting two QEMU source files is required, for which >> + there are no references in U-Boot documentation. The code is generating a >> + devicetree, but it is not clear what controls affect this generation. >> + >> +Specifically on the changes in U-Bootm `CONFIG_OF_BOARD` was added in >> +rpi_patch_ for Raspberry Pi, which does have an in-tree devicetree, but this >> +feature has since been used for boards that don't >> + >> +Once this bug is fixed, CONFIG_OF_BOARD will override (at runtime) the >> +evicetree suppled with U-Boot, but will otherwise use CONFIG_OF_SEPARATE for the >> +in-tree build. So these two will become options, moving out of the 'choice' in >> +`dts/Kconfig`. >> + >> +This means that there is a basic devicetree build in the U-Boot tree, for >> +build-testing, consistency and documentation purposes, but at runtime U-Boot can >> +accept its devicetree from another source. The in-tree devicetree may contain >> +U-Boot-specific features (in u-boot*.dtsi files) and this may prove useful for >> +the other project, so it can ensure that U-Boot functions correctly and supports >> +all its expected features. >> + >> +To be clear, while U-Boot has its own copy of the devicetree source for each >> +board, this must match the Linux source, perhaps with some u-boot.dtsi >> +additions. The intent here is not to create a separate binding, just to provide >> +a representative devicetree in U-Boot. >> + >> +Offending boards are: >> + >> +- rpi_4 and rpi_4_32b (other rpi boards do have an in-tree devicetree) >> +- qemu_arm64 >> +- qemu_arm >> +- qemu-ppce500 >> +- qemu-riscv32 >> +- qemu-riscv32_smode >> +- qemu-riscv64 >> +- qemu-riscv64_smode >> + >> +All of these need to have a devicetree added in-tree. This is targeted to be >> +fixed in the 2022.01 release. >> + >> + >> +Building the devicetree >> +----------------------- >> + >> +U-Boot automatically builds the devicetree for a board, from the >> +`arch/<arch>/dts` directory. The Makefile in those directories has rules for >> +building devicetree files. It is preferable to avoid target-specific rules in >> +those files: i.e. all boards for a particular SoC should be built at once, >> +where practical. Apart from simplifying the Makefile, this helps to efficiently >> +(and immediately) ensure that changes in one board's DT do not break others that >> +are related. Building devicetrees is fast, so performance is seldom a concern >> +here. >> + >> + >> +Overriding the default devicetree >> +--------------------------------- >> + >> +When building U-Boot, the `DEVICE_TREE` environment variable allows the >> +default devicetree file to be overridden at build time. This can be useful if >> +modifications have to be made to the in-tree devicetree file, for the benefit >> +of a downstream build system. Note that the in-tree devicetree must be >> +sufficient to build and boot, so this is not a way to bypass that requirement. >> + >> + >> +Modifying the devicetree after building >> +--------------------------------------- >> + >> +While it is generally painful and hacky to modify the code or rodata of a >> +program after it is built, in many cases it is useful to do so, e.g. to add >> +configuration information like serial numbers, enabling/disabling features, etc. >> + >> +Devicetree provides a very nice solution to these problems since it is >> +structured data and it is relatively easy to change it, even in binary form >> +(see fdtput). >> + >> +U-Boot takes care that the devicetree is easily accessible after the build >> +process. In fact it is placed in a separate file called `u-boot.dtb`. If the >> +build system wants to modify or replace that file, it can do so. Then all that >> +is needed is to run `binman update` to update the file inside the image. If >> +binman is not used, then `u-boot-nodtb.bin` and the new `u-boot.dtb` can simply >> +be concatenated to achieve the desired result. U-Boot happily copes with the >> +devicetree growing or shrinking. >> + >> +The `u-boot.bin` image contains both pieces. While it is possible to locate the >> +devicetree within the image using the signature at the start of the file, this >> +is a bit messy. >> + >> +This is why `CONFIG_OF_SEPARATE` should always be used when building U-Boot. >> +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot ELF >> +image as rodata, meaning that it is hard to find it and it cannot increase in >> +size. >> + >> +When modifying the devicetree, the different cases to consider are as follows: >> + >> +- CONFIG_OF_SEPARATE >> + This is easy, described above. Just change, replace or rebuild the >> + devicetree so it suits your needs, then rerun binman or redo the `cat` >> + operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb` >> + >> +- CONFIG_OF_EMBED >> + This is tricky, since the devicetree cannot easily be located. If the EFL >> + file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can be >> + examined to find it. While it is possible to contract the file, it is not >> + possible to expand the file since that would involve re-linking >> + >> +- CONFIG_OF_BOARD >> + This is a board-specific situation, so needs to be considered on a >> + case-by-case base. The devicetree must be modified so that the correct >> + one is provided to U-Boot. How this is done depends entirely on the >> + implementation of this option for the board. It might require injecting the >> + changes into a different project somehow using tooling available there, or >> + it might involve merging an overlay file at runtime to obtain the desired >> + result. >> + >> + >> +Use of U-Boot /config node >> +-------------------------- >> + >> +A common problem with firmware is that many builds are needed to deal with the >> +slight variations between different, related models. For example, one model may >> +have a TPM and another may not. Devicetree provides an excellent solution to >> +this problem, in that the devicetree to actually use on a platform can be >> +injected in the factory based on which model is being manufactured at the time. >> + >> +A related problem causing build proliferation is dealing with the differences >> +between development firmware, developer-friendly firmware (e.g. with all >> +security features present but with the ability to access the command line), >> +test firmware (which runs tests used in the factory), final production firmware >> +(before signing), signed firmware (where the signatures have been inserted) and >> +the like. Ideally all or most of these should use the same U-Boot build, with >> +just some options to determine the features available. For example, being able >> +to control whether the UART console or JTAG are available, on any image, is a >> +great debugging aid. >> + >> +When the firmware consists of multiple parts, it is helpful that all operate >> +the same way at runtime, regardless of how they were built. This can be achieved >> +by passing the runtime configuration (e.g. 'enable UART console) along the chain >> +through each firmware stage. It is frustrating to have to replicate a bug on >> +production firmware which does happen on developer firmware, because they are >> +completely different builds. >> + >> +The /config node provides useful functionality for this. It allows the different >> +controls to be 'factored out' of the U-Boot binary, so they can be controlled >> +separately from the initial source-code build. The node can be easily updated by >> +a build or factory tool and can control various features in U-Boot. It is >> +similar in concept to a Kconfig option, except that it can be changed after >> +U-Boot is built. >> + >> +The /config node is similar in concept to the `/chosen node`_ except that it is >> +for passing information *into* firmware instead of from firmware to the >> +Operating System. Also, while Linux has a (sometimes extremely long) command >> +line, U-Boot does not support this. The devicetree provides a more structured >> +approach in any case. >> + >> + >> +Devicetree in another project >> +----------------------------- >> + >> +In some cases U-Boot receive its devicetree at runtime from a program that calls >> +it. For example ARM's Trusted Firmware A (`TF-A`_) may have a devicetree that it >> +passes to U-Boot. This overrides any devicetree build by U-Boot. When packaging >> +the firmware, the U-Boot devicetree may in fact be left out if it can be >> +guaranteed that it will receive one from another project. >> + >> +In this case, the devicetree in the other project must track U-Boot's use of >> +device tree, for the following reasons: >> + >> +- U-Boot only has one devicetree. See `Why not have two devicetrees?`_. >> +- For a consistent firmware build, decisions made in early stages should be >> + communicated to later ones at runtime. For example, if the serial console is >> + enabled in an early stage, it should be enabled in U-Boot too. >> +- U-Boot is quite capable of managing its own copy of the devicetree. If >> + another project wants to bypass this (often for good reason), it is reasonable >> + that it should take on the (fairly small) requirements that U-Boot features >> + that rely on devicetree are still available >> +- The point here is not that *U-Boot needs this extra node*, or *U-Boot needs >> + to have this public key*. These features are present in U-Boot in service of >> + the entire firmware system. If the U-Boot features are used, but cannot be >> + supported in the normal way, then there is pressure to implement these >> + features in other ways. In the end, we would have a different mechanism for >> + every other project that uses U-Boot. This introduces duplicate ways of doing >> + the same thing, needlessly increases the complexity of the U-Boot source code, >> + forces authors to consider parallel implementations when writing new features, >> + makes U-Boot harder to test, complicates documentation and confuses the >> + runtime flow of U-Boot. If every board did things its own way rather than >> + contributing to the common code, U-Boot would lose a lot of its cross-platform >> + value. >> + >> +The above does not indicate *bad design* within U-Boot. Devicetree is a core >> +component of U-Boot and U-Boot makes use of it to the full. It solves a myriad >> +of problems that would otherwise need their own special C struct, binary format, >> +special property, tooling for viewing and updating, etc. >> + >> +Specifically, the other project must provide a way to add configuration and >> +other information to the devicetree for use by U-Boot, such as the /config node. >> +Note that the U-Boot in-tree devicetree source must be sufficient to build and >> +boot, so this is not a way to bypass that requirement. >> + >> +If binman is used, the devicetree source in U-Boot must contain the binman >> +definition so that a valid image can be build. This helps people discover what >> +other firmware components are needed and seek out appropriate documentation. >> + >> +If verified boot is used, the project must provide a way to inject a public key, >> +certificate or other material into the U-Boot devicetree so that it is available >> +to U-Boot at runtime. See `Signing with U-Boot devicetree`_. This may be >> +through tooling in the project itself or by making use of U-Boot's tooling. >> + >> + >> +Devicetree generated on-the-fly in another project >> +-------------------------------------------------- >> + >> +In some rare cases, another project may wish to create a devicetree for U-Boot >> +entirely on-the-fly, then pass it to U-Boot at runtime. The only known example >> +of this at the time of writing (2021) is QEMU, for ARM (`QEMU ARM`_) and >> +RISC-V (`QEMU RISC-V`_). >> + >> +In effect, when the board boots, U-Boot is *downstream* of the other project. >> +It is entirely reliant on that project for its correct operation. >> + >> +This does not mean to imply that the other project is creating its own, >> +incompatible devicetree. In fact QEMU generates a valid devicetree which is >> +suitable for both U-Boot and Linux. It is quite normal for a devicetree to be >> +present in flash and be made available to U-Boot at runtime. What matters is >> +where the devicetree comes from. If the other project builds a devicetree for >> +U-Boot then it needs to support adding the things needed by U-Boot features. >> +Without them, for example: >> + >> +- U-Boot may not boot because too many devices are enabled before relocation >> +- U-Boot may not have access to the developer or production public keys used for >> + signing >> +- U-Boot may not support controlling whether the console is enabled >> +- U-Boot may not be know which MMC device to boot from >> +- U-Boot may not be able to find other firmware components that it needs to load >> + >> +Normally, supporting U-Boot's features is trivial, since the devicetree compiler >> +(dtc) can compile the source, including any U-Boot pieces. So the burden is >> +extremely low. >> + >> +In this case, the devicetree in the other project must track U-Boot's use of >> +device tree, so that it remains compatible. See `Devicetree in another project`_ >> +for reasons why. >> + >> +If a particular version of the project is needed for a particular version of >> +U-Boot, that must be documented in both projects. >> + >> +Further, it must provide a way to add configuration and other information to >> +the devicetree for use by U-Boot, such as the `/config` node and the tags used >> +by driver model. Note that the U-Boot in-tree devicetree must be sufficient to >> +build and boot, so this is not a way to bypass that requirement. >> + >> +More specifically, tooling or command-line arguments must provide a way to >> +add a `/config` node or items within that node, so that U-Boot can receive a >> +suitable configuration. It must provide a way of adding `u-boot,dm-...` tags for >> +correct operation of driver model. These options can then be used as part of the >> +build process, which puts the firmware image together. For binman, a way must be >> +provided to add the binman definition into the devicetree in the same way. >> + >> +One way to do this is to allow a .dtsi file to be merged in with the generated >> +devicetree. >> + >> +Note that the burden goes both ways. If a new feature is added to U-Boot which >> +needs support in another project, then the author of the U-Boot patch must add >> +any required support to the other project. >> + >> + >> +Passing the devicetree through to Linux >> +--------------------------------------- >> + >> +Ideally U-Boot and Linux use the same devicetree source, even though it is >> +hosted in separate projects. U-Boot adds some extra pieces, such as the >> +`config/` node and tags like `u-boot,dm-spl`. Linux adds some extra pieces, such >> +as `linux,default-trigger` and `linux,code`. This should not interfere with >> +each other. >> + >> +In principle it is possible for U-Boot's control devicetree to be passed to >> +Linux. This is, after all, one of the goals of devicetree and the original >> +Open Firmware project, to have the firmware provide the hardware description to >> +the Operating System. >> + >> +For boards where this approach is used, care must be taken. U-Boot typically >> +needs to 'fix up' the devicetree before passing it to Linux, e.g. to add >> +information about the memory map, about which serial console is used, provide >> +the kernel address space layout randomization (KASLR) seed or select whether the >> +console should be silenced for a faster boot. >> + >> +Fix-ups involve modifying the devicetree. If the control devicetree is used, >> +that means the control devicetree could be modified, while U-Boot is using it. >> +Removing a device and reinserting it can cause problems if the devicetree offset >> +has changed, for example, since the device will be unable to locates its >> +devicetree properties at the expected devicetree offset, which is a fixed >> +integer. >> + >> +To deal with this, it is recommended to employ one or more of the following >> +approaches: >> + >> +- Make a copy of the devicetree and 'fix up' the copy, leaving the control >> + devicetree alone >> +- Enable `CONFIG_OF_LIVE` so that U-Boot makes its own copy of the devicetree >> + during relocation; fixups then happen on the original flat tree >> +- Ensure that fix-ups happen after all loading has happened and U-Boot has >> + completed image verification >> + >> +In practice,the last point is typically observed, since boot_prep_linux() is >> +called just before jumping to Linux, long after signature verification, for >> +example. But it is important to make sure that this line is not blurred, >> +particularly if untrusted user data is involved. >> + >> + >> +Devicetree use cases that must be supported >> +------------------------------------------- >> + >> +Regardless of how the devicetree is provided to U-Boot at runtime, various >> +U-Boot features must be fully supported. This section describes some of these >> +features and the implications for other projects. >> + >> +If U-Boot uses its own in-tree devicetree these features are supported >> +automatically. >> + >> + >> +Signing with U-Boot devicetree >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +U-Boot supports signing a payload so that it can be verified to have been >> +created by a party owning a private key. This is called verified boot in U-Boot >> +(see doc/uImage.FIT/verified-boot.txt). >> + >> +Typically this works by creating a FIT and then running the `mkimage` tool to >> +add signatures for particular images. As part of this process, `mkimage` writes >> +a public key to the U-Boot devicetree, although this can be done separately. >> +See fdt_add_pubkey_ for patches for a suitable tool, for example. >> + >> +As with all configuration information, if another project is providing the >> +devicetree to U-Boot, it must provide a way to add this public key into the >> +devicetree it passes to U-Boot. This could be via a tooling option, making use >> +of `mkimage`, or allowing a .dtsi file to be merged in with what is generated in >> +the other project. >> + >> + >> +Providing the binman image definition >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +In complex systems U-Boot must locate and make use of other firmware components, >> +such as images for the user interface, files containing peripheral firmware, >> +multiple copies of U-Boot for use with A/B boot, etc. U-Boot uses >> +:doc:`Binman <../package/binman>` as a standard way of putting an image >> +together. >> + >> +Typically this works by running binman with the devicetree as an input, to >> +create the file image. Binman then outputs an updated devicetree which is >> +packed in the firmware image, so U-Boot can access the binman definition and >> +locate all the components. >> + >> +As with all configuration information, if another project is providing the >> +devicetree to U-Boot, it must provide a way to add this binman definition into >> +the devicetree it passes to U-Boot. This could be via a tooling option, making >> +use of `binman`, or alowing a .dtsi file to be merged in with what is generated >> +in the other project. >> + >> + >> +Protecting the devicetree >> +------------------------- >> + >> +U-Boot relies heavily on devicetree for correct operation. A corrupt or invalid >> +device can cause U-Boot to fail to start, behave incorrectly, crash (e.g. if >> +`CONFIG_OF_LIBFDT_ASSUME_MASK` is adjusted, or fail to boot an Operating System. >> +Within U-Boot, the devicetree is as important as any other part of the source >> +code. At ruuntime, the devicetree can be considered to be structured rodata. >> + >> +With secure systems, care must be taken that the devicetree is valid: >> + >> +- If the code / rodata has a hash or signature, the devicetree should also, if >> + they are packaged separately. >> +- If the code / rodata is write-protected when running, the devicetree should be >> + also. Note that U-Boot relocates its code and devicetree, so this is not as >> + simple as it sounds. U-Boot must write-protect these items after relocating. >> + >> + >> +Why does U-Boot have its nodes and properties? >> +---------------------------------------------- >> + >> +See also :doc:`../devicetree/intro`. >> + >> +There has been pushback at the concept that U-Boot dares have its own nodes and >> +properties in the devicetree. >> + >> +Apart from these nodes and properties, U-Boot uses the same bindings as Linux. >> +A `u-boot.dtsi` file helps to keep U-Boot-specific changes in separate files, >> +making it easier to keep devicetree source files in U-Boot in sync with Linux. >> + >> +As a counter-example, the Zephyr OS project takes a different approach. It uses >> +entirely different bindings, in general, making no effort to sync devicetree >> +source files with Linux. U-Boot strives to be compatible with Linux in a number >> +of ways, such as source code style and common APIs, to aid porting of code >> +between the projects. Devicetree is another way where U-Boot and Linux follow a >> +similar approach. >> + >> +Fundamentally, the idea that U-Boot cannot have its own tags flies in the face >> +of the devicetree specification (see dtspec_), which says: >> + >> + Nonstandard property names should specify a **unique string prefix**, such as >> + a stock ticker symbol, identifying the name of the company **or organization** >> + that defined the property. Examples: >> + >> + - fsl,channel-fifo-len >> + - ibm,ppc-interrupt-server#s >> + - **linux**,network-index >> + >> +It is also fundamentally unbalanced. Linux has many tags of its own (some 36 in >> +version 5.13) and at least one Linux-specific node, even if you ignore things >> +like flash partitions which clearly provide configuration information to Linux. >> + >> +Practically speaking there are many reasons why U-Boot has its own nodes and >> +properties. Some examples: >> + >> +- Binding every device before relocation even if it won't be used, consumes time >> + and memory: tags on each node can specify which are needed in SPL or before >> + relocation. Linux has no such constraints. >> + >> +- Requiring the full clock tree to be up and running just to get the debug UART >> + running is inefficient. It is also and self-defeating, since if that much >> + code is working properly, you probably don't need the debug UART. A devicetree >> + property to provide the UART input-clock frequency is a simple solution. >> + >> +- U-Boot does not have a user space to provide policy and configuration. It >> + cannot do what Linux does and run programs and look up filesystems to figure >> + out how to boot. >> + >> + >> +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. > 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. But if you are wanting to change to multiple control trees within U-Boot, I'd say the answer is "no, thank you". If there is a use case for that, please can you be specific about what we cannot do with a combined devicetree? Regards, Simon
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. > >> > >> Signed-off-by: Simon Glass <sjg@chromium.org> > >> Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> > >> --- > >> This patch attracted quite a bit of discussion here: > >> > >> > https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-sjg@chromium.org/ > >> > >> I have not included the text suggested by François. While I agree that > >> it would be useful to have an introduction in this space, I do not agree > >> that we should have two devicetrees or that U-Boot should not have its > own > >> things in the devicetree, so it is not clear to me what we should > actually > >> write. > >> > >> The 'Devicetree Control in U-Boot' docs were recently merged and these > >> provide some base info, for now. > >> > >> Changes in v5: > >> - Bring into the OF_BOARD series > >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > >> - Refer to the 'control' DTB in the first paragraph > >> - Use QEMU instead of qemu > >> > >> Changes in v3: > >> - Clarify the 'bug' refered to at the top > >> - Reword 'This means that there' paragraph to explain U-Boot-specific > things > >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > >> > >> Changes in v2: > >> - Fix typos per Sean (thank you!) and a few others > >> - Add a 'Use of U-Boot /config node' section > >> - Drop mention of dm-verity since that actually uses the kernel cmdline > >> - Explain that OF_BOARD will still work after these changes (in > >> 'Once this bug is fixed...' paragraph) > >> - Expand a bit on the reason why the 'Current situation' is bad > >> - Clarify in a second place that Linux and U-Boot use the same > devicetree > >> in 'To be clear, while U-Boot...' > >> - Expand on why we should have rules for other projects in > >> 'Devicetree in another project' > >> - Add a comment as to why devicetree in U-Boot is not 'bad design' > >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover > >> points raised on v1 > >> - Add 'Why does U-Boot have its nodes and properties?' > >> - Add 'Why not have two devicetrees?' > >> > >> doc/develop/devicetree/dt_update.rst | 556 +++++++++++++++++++++++++++ > >> doc/develop/devicetree/index.rst | 1 + > >> 2 files changed, 557 insertions(+) > >> create mode 100644 doc/develop/devicetree/dt_update.rst > >> > >> diff --git a/doc/develop/devicetree/dt_update.rst > b/doc/develop/devicetree/dt_update.rst > >> new file mode 100644 > >> index 00000000000..3d4902e3592 > >> --- /dev/null > >> +++ b/doc/develop/devicetree/dt_update.rst > >> @@ -0,0 +1,556 @@ > >> +.. SPDX-License-Identifier: GPL-2.0+ > >> + > >> +Updating the devicetree > >> +======================= > >> + > >> +U-Boot uses devicetree for runtime configuration and storing required > blobs or > >> +any other information it needs to operate. This is called the 'control' > >> +devicetree since it controls U-Boot. It is possible to update the > control > >> +devicetree separately from actually building U-Boot. This provides a > good degree > >> +of control and flexibility for firmware that uses U-Boot in > conjunction with > >> +other project. > >> + > >> +There are many reasons why it is useful to modify the devicetree after > building > >> +it: > >> + > >> +- Configuration can be changed, e.g. which UART to use > >> +- A serial number can be added > >> +- Public keys can be added to allow image verification > >> +- Console output can be changed (e.g. to select serial or vidconsole) > >> + > >> +This section describes how to work with devicetree to accomplish your > goals. > >> + > >> +See also :doc:`../devicetree/control` for a basic summary of the > available > >> +features. > >> + > >> + > >> +Devicetree source > >> +----------------- > >> + > >> +Every board in U-Boot must include a devicetree sufficient to build > and boot > >> +that board on suitable hardware (or emulation). This is specified > using the > >> +`CONFIG DEFAULT_DEVICE_TREE` option. > >> + > >> + > >> +Current situation (October 2021) > >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> + > >> +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to > be empty, > >> +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an > enormous > >> +amount of confusion and some wasted effort. This was not intended. > Support for > >> +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. > >> + > >> +Some of the problems created are: > >> + > >> +- It is not obvious that the devicetree is coming from another project > >> + > >> +- There is no way to see even a sample devicetree for these platform > in U-Boot, > >> + so it is hard to know what is going on, e.g. which devices are > typically > >> + present > >> + > >> +- The other project may not provide a way to support U-Boot's > requirements for > >> + devicetree, such as the /config node. Note: On the U-Boot mailing > linst, this > >> + was only discovered after weeks of discussion and confusion > >> + > >> +- For QEMU specifically, consulting two QEMU source files is required, > for which > >> + there are no references in U-Boot documentation. The code is > generating a > >> + devicetree, but it is not clear what controls affect this generation. > >> + > >> +Specifically on the changes in U-Bootm `CONFIG_OF_BOARD` was added in > >> +rpi_patch_ for Raspberry Pi, which does have an in-tree devicetree, > but this > >> +feature has since been used for boards that don't > >> + > >> +Once this bug is fixed, CONFIG_OF_BOARD will override (at runtime) the > >> +evicetree suppled with U-Boot, but will otherwise use > CONFIG_OF_SEPARATE for the > >> +in-tree build. So these two will become options, moving out of the > 'choice' in > >> +`dts/Kconfig`. > >> + > >> +This means that there is a basic devicetree build in the U-Boot tree, > for > >> +build-testing, consistency and documentation purposes, but at runtime > U-Boot can > >> +accept its devicetree from another source. The in-tree devicetree may > contain > >> +U-Boot-specific features (in u-boot*.dtsi files) and this may prove > useful for > >> +the other project, so it can ensure that U-Boot functions correctly > and supports > >> +all its expected features. > >> + > >> +To be clear, while U-Boot has its own copy of the devicetree source > for each > >> +board, this must match the Linux source, perhaps with some u-boot.dtsi > >> +additions. The intent here is not to create a separate binding, just > to provide > >> +a representative devicetree in U-Boot. > >> + > >> +Offending boards are: > >> + > >> +- rpi_4 and rpi_4_32b (other rpi boards do have an in-tree devicetree) > >> +- qemu_arm64 > >> +- qemu_arm > >> +- qemu-ppce500 > >> +- qemu-riscv32 > >> +- qemu-riscv32_smode > >> +- qemu-riscv64 > >> +- qemu-riscv64_smode > >> + > >> +All of these need to have a devicetree added in-tree. This is targeted > to be > >> +fixed in the 2022.01 release. > >> + > >> + > >> +Building the devicetree > >> +----------------------- > >> + > >> +U-Boot automatically builds the devicetree for a board, from the > >> +`arch/<arch>/dts` directory. The Makefile in those directories has > rules for > >> +building devicetree files. It is preferable to avoid target-specific > rules in > >> +those files: i.e. all boards for a particular SoC should be built at > once, > >> +where practical. Apart from simplifying the Makefile, this helps to > efficiently > >> +(and immediately) ensure that changes in one board's DT do not break > others that > >> +are related. Building devicetrees is fast, so performance is seldom a > concern > >> +here. > >> + > >> + > >> +Overriding the default devicetree > >> +--------------------------------- > >> + > >> +When building U-Boot, the `DEVICE_TREE` environment variable allows the > >> +default devicetree file to be overridden at build time. This can be > useful if > >> +modifications have to be made to the in-tree devicetree file, for the > benefit > >> +of a downstream build system. Note that the in-tree devicetree must be > >> +sufficient to build and boot, so this is not a way to bypass that > requirement. > >> + > >> + > >> +Modifying the devicetree after building > >> +--------------------------------------- > >> + > >> +While it is generally painful and hacky to modify the code or rodata > of a > >> +program after it is built, in many cases it is useful to do so, e.g. > to add > >> +configuration information like serial numbers, enabling/disabling > features, etc. > >> + > >> +Devicetree provides a very nice solution to these problems since it is > >> +structured data and it is relatively easy to change it, even in binary > form > >> +(see fdtput). > >> + > >> +U-Boot takes care that the devicetree is easily accessible after the > build > >> +process. In fact it is placed in a separate file called `u-boot.dtb`. > If the > >> +build system wants to modify or replace that file, it can do so. Then > all that > >> +is needed is to run `binman update` to update the file inside the > image. If > >> +binman is not used, then `u-boot-nodtb.bin` and the new `u-boot.dtb` > can simply > >> +be concatenated to achieve the desired result. U-Boot happily copes > with the > >> +devicetree growing or shrinking. > >> + > >> +The `u-boot.bin` image contains both pieces. While it is possible to > locate the > >> +devicetree within the image using the signature at the start of the > file, this > >> +is a bit messy. > >> + > >> +This is why `CONFIG_OF_SEPARATE` should always be used when building > U-Boot. > >> +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the > U-Boot ELF > >> +image as rodata, meaning that it is hard to find it and it cannot > increase in > >> +size. > >> + > >> +When modifying the devicetree, the different cases to consider are as > follows: > >> + > >> +- CONFIG_OF_SEPARATE > >> + This is easy, described above. Just change, replace or rebuild the > >> + devicetree so it suits your needs, then rerun binman or redo the > `cat` > >> + operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb` > >> + > >> +- CONFIG_OF_EMBED > >> + This is tricky, since the devicetree cannot easily be located. If > the EFL > >> + file is available, then the _dtb_dt_begin and __dtb_dt_end symbols > can be > >> + examined to find it. While it is possible to contract the file, it > is not > >> + possible to expand the file since that would involve re-linking > >> + > >> +- CONFIG_OF_BOARD > >> + This is a board-specific situation, so needs to be considered on a > >> + case-by-case base. The devicetree must be modified so that the > correct > >> + one is provided to U-Boot. How this is done depends entirely on the > >> + implementation of this option for the board. It might require > injecting the > >> + changes into a different project somehow using tooling available > there, or > >> + it might involve merging an overlay file at runtime to obtain the > desired > >> + result. > >> + > >> + > >> +Use of U-Boot /config node > >> +-------------------------- > >> + > >> +A common problem with firmware is that many builds are needed to deal > with the > >> +slight variations between different, related models. For example, one > model may > >> +have a TPM and another may not. Devicetree provides an excellent > solution to > >> +this problem, in that the devicetree to actually use on a platform can > be > >> +injected in the factory based on which model is being manufactured at > the time. > >> + > >> +A related problem causing build proliferation is dealing with the > differences > >> +between development firmware, developer-friendly firmware (e.g. with > all > >> +security features present but with the ability to access the command > line), > >> +test firmware (which runs tests used in the factory), final production > firmware > >> +(before signing), signed firmware (where the signatures have been > inserted) and > >> +the like. Ideally all or most of these should use the same U-Boot > build, with > >> +just some options to determine the features available. For example, > being able > >> +to control whether the UART console or JTAG are available, on any > image, is a > >> +great debugging aid. > >> + > >> +When the firmware consists of multiple parts, it is helpful that all > operate > >> +the same way at runtime, regardless of how they were built. This can > be achieved > >> +by passing the runtime configuration (e.g. 'enable UART console) along > the chain > >> +through each firmware stage. It is frustrating to have to replicate a > bug on > >> +production firmware which does happen on developer firmware, because > they are > >> +completely different builds. > >> + > >> +The /config node provides useful functionality for this. It allows the > different > >> +controls to be 'factored out' of the U-Boot binary, so they can be > controlled > >> +separately from the initial source-code build. The node can be easily > updated by > >> +a build or factory tool and can control various features in U-Boot. It > is > >> +similar in concept to a Kconfig option, except that it can be changed > after > >> +U-Boot is built. > >> + > >> +The /config node is similar in concept to the `/chosen node`_ except > that it is > >> +for passing information *into* firmware instead of from firmware to the > >> +Operating System. Also, while Linux has a (sometimes extremely long) > command > >> +line, U-Boot does not support this. The devicetree provides a more > structured > >> +approach in any case. > >> + > >> + > >> +Devicetree in another project > >> +----------------------------- > >> + > >> +In some cases U-Boot receive its devicetree at runtime from a program > that calls > >> +it. For example ARM's Trusted Firmware A (`TF-A`_) may have a > devicetree that it > >> +passes to U-Boot. This overrides any devicetree build by U-Boot. When > packaging > >> +the firmware, the U-Boot devicetree may in fact be left out if it can > be > >> +guaranteed that it will receive one from another project. > >> + > >> +In this case, the devicetree in the other project must track U-Boot's > use of > >> +device tree, for the following reasons: > >> + > >> +- U-Boot only has one devicetree. See `Why not have two devicetrees?`_. > >> +- For a consistent firmware build, decisions made in early stages > should be > >> + communicated to later ones at runtime. For example, if the serial > console is > >> + enabled in an early stage, it should be enabled in U-Boot too. > >> +- U-Boot is quite capable of managing its own copy of the devicetree. > If > >> + another project wants to bypass this (often for good reason), it is > reasonable > >> + that it should take on the (fairly small) requirements that U-Boot > features > >> + that rely on devicetree are still available > >> +- The point here is not that *U-Boot needs this extra node*, or > *U-Boot needs > >> + to have this public key*. These features are present in U-Boot in > service of > >> + the entire firmware system. If the U-Boot features are used, but > cannot be > >> + supported in the normal way, then there is pressure to implement > these > >> + features in other ways. In the end, we would have a different > mechanism for > >> + every other project that uses U-Boot. This introduces duplicate ways > of doing > >> + the same thing, needlessly increases the complexity of the U-Boot > source code, > >> + forces authors to consider parallel implementations when writing new > features, > >> + makes U-Boot harder to test, complicates documentation and confuses > the > >> + runtime flow of U-Boot. If every board did things its own way rather > than > >> + contributing to the common code, U-Boot would lose a lot of its > cross-platform > >> + value. > >> + > >> +The above does not indicate *bad design* within U-Boot. Devicetree is > a core > >> +component of U-Boot and U-Boot makes use of it to the full. It solves > a myriad > >> +of problems that would otherwise need their own special C struct, > binary format, > >> +special property, tooling for viewing and updating, etc. > >> + > >> +Specifically, the other project must provide a way to add > configuration and > >> +other information to the devicetree for use by U-Boot, such as the > /config node. > >> +Note that the U-Boot in-tree devicetree source must be sufficient to > build and > >> +boot, so this is not a way to bypass that requirement. > >> + > >> +If binman is used, the devicetree source in U-Boot must contain the > binman > >> +definition so that a valid image can be build. This helps people > discover what > >> +other firmware components are needed and seek out appropriate > documentation. > >> + > >> +If verified boot is used, the project must provide a way to inject a > public key, > >> +certificate or other material into the U-Boot devicetree so that it is > available > >> +to U-Boot at runtime. See `Signing with U-Boot devicetree`_. This may > be > >> +through tooling in the project itself or by making use of U-Boot's > tooling. > >> + > >> + > >> +Devicetree generated on-the-fly in another project > >> +-------------------------------------------------- > >> + > >> +In some rare cases, another project may wish to create a devicetree > for U-Boot > >> +entirely on-the-fly, then pass it to U-Boot at runtime. The only known > example > >> +of this at the time of writing (2021) is QEMU, for ARM (`QEMU ARM`_) > and > >> +RISC-V (`QEMU RISC-V`_). > >> + > >> +In effect, when the board boots, U-Boot is *downstream* of the other > project. > >> +It is entirely reliant on that project for its correct operation. > >> + > >> +This does not mean to imply that the other project is creating its own, > >> +incompatible devicetree. In fact QEMU generates a valid devicetree > which is > >> +suitable for both U-Boot and Linux. It is quite normal for a > devicetree to be > >> +present in flash and be made available to U-Boot at runtime. What > matters is > >> +where the devicetree comes from. If the other project builds a > devicetree for > >> +U-Boot then it needs to support adding the things needed by U-Boot > features. > >> +Without them, for example: > >> + > >> +- U-Boot may not boot because too many devices are enabled before > relocation > >> +- U-Boot may not have access to the developer or production public > keys used for > >> + signing > >> +- U-Boot may not support controlling whether the console is enabled > >> +- U-Boot may not be know which MMC device to boot from > >> +- U-Boot may not be able to find other firmware components that it > needs to load > >> + > >> +Normally, supporting U-Boot's features is trivial, since the > devicetree compiler > >> +(dtc) can compile the source, including any U-Boot pieces. So the > burden is > >> +extremely low. > >> + > >> +In this case, the devicetree in the other project must track U-Boot's > use of > >> +device tree, so that it remains compatible. See `Devicetree in another > project`_ > >> +for reasons why. > >> + > >> +If a particular version of the project is needed for a particular > version of > >> +U-Boot, that must be documented in both projects. > >> + > >> +Further, it must provide a way to add configuration and other > information to > >> +the devicetree for use by U-Boot, such as the `/config` node and the > tags used > >> +by driver model. Note that the U-Boot in-tree devicetree must be > sufficient to > >> +build and boot, so this is not a way to bypass that requirement. > >> + > >> +More specifically, tooling or command-line arguments must provide a > way to > >> +add a `/config` node or items within that node, so that U-Boot can > receive a > >> +suitable configuration. It must provide a way of adding > `u-boot,dm-...` tags for > >> +correct operation of driver model. These options can then be used as > part of the > >> +build process, which puts the firmware image together. For binman, a > way must be > >> +provided to add the binman definition into the devicetree in the same > way. > >> + > >> +One way to do this is to allow a .dtsi file to be merged in with the > generated > >> +devicetree. > >> + > >> +Note that the burden goes both ways. If a new feature is added to > U-Boot which > >> +needs support in another project, then the author of the U-Boot patch > must add > >> +any required support to the other project. > >> + > >> + > >> +Passing the devicetree through to Linux > >> +--------------------------------------- > >> + > >> +Ideally U-Boot and Linux use the same devicetree source, even though > it is > >> +hosted in separate projects. U-Boot adds some extra pieces, such as the > >> +`config/` node and tags like `u-boot,dm-spl`. Linux adds some extra > pieces, such > >> +as `linux,default-trigger` and `linux,code`. This should not interfere > with > >> +each other. > >> + > >> +In principle it is possible for U-Boot's control devicetree to be > passed to > >> +Linux. This is, after all, one of the goals of devicetree and the > original > >> +Open Firmware project, to have the firmware provide the hardware > description to > >> +the Operating System. > >> + > >> +For boards where this approach is used, care must be taken. U-Boot > typically > >> +needs to 'fix up' the devicetree before passing it to Linux, e.g. to > add > >> +information about the memory map, about which serial console is used, > provide > >> +the kernel address space layout randomization (KASLR) seed or select > whether the > >> +console should be silenced for a faster boot. > >> + > >> +Fix-ups involve modifying the devicetree. If the control devicetree is > used, > >> +that means the control devicetree could be modified, while U-Boot is > using it. > >> +Removing a device and reinserting it can cause problems if the > devicetree offset > >> +has changed, for example, since the device will be unable to locates > its > >> +devicetree properties at the expected devicetree offset, which is a > fixed > >> +integer. > >> + > >> +To deal with this, it is recommended to employ one or more of the > following > >> +approaches: > >> + > >> +- Make a copy of the devicetree and 'fix up' the copy, leaving the > control > >> + devicetree alone > >> +- Enable `CONFIG_OF_LIVE` so that U-Boot makes its own copy of the > devicetree > >> + during relocation; fixups then happen on the original flat tree > >> +- Ensure that fix-ups happen after all loading has happened and U-Boot > has > >> + completed image verification > >> + > >> +In practice,the last point is typically observed, since > boot_prep_linux() is > >> +called just before jumping to Linux, long after signature > verification, for > >> +example. But it is important to make sure that this line is not > blurred, > >> +particularly if untrusted user data is involved. > >> + > >> + > >> +Devicetree use cases that must be supported > >> +------------------------------------------- > >> + > >> +Regardless of how the devicetree is provided to U-Boot at runtime, > various > >> +U-Boot features must be fully supported. This section describes some > of these > >> +features and the implications for other projects. > >> + > >> +If U-Boot uses its own in-tree devicetree these features are supported > >> +automatically. > >> + > >> + > >> +Signing with U-Boot devicetree > >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> + > >> +U-Boot supports signing a payload so that it can be verified to have > been > >> +created by a party owning a private key. This is called verified boot > in U-Boot > >> +(see doc/uImage.FIT/verified-boot.txt). > >> + > >> +Typically this works by creating a FIT and then running the `mkimage` > tool to > >> +add signatures for particular images. As part of this process, > `mkimage` writes > >> +a public key to the U-Boot devicetree, although this can be done > separately. > >> +See fdt_add_pubkey_ for patches for a suitable tool, for example. > >> + > >> +As with all configuration information, if another project is providing > the > >> +devicetree to U-Boot, it must provide a way to add this public key > into the > >> +devicetree it passes to U-Boot. This could be via a tooling option, > making use > >> +of `mkimage`, or allowing a .dtsi file to be merged in with what is > generated in > >> +the other project. > >> + > >> + > >> +Providing the binman image definition > >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> + > >> +In complex systems U-Boot must locate and make use of other firmware > components, > >> +such as images for the user interface, files containing peripheral > firmware, > >> +multiple copies of U-Boot for use with A/B boot, etc. U-Boot uses > >> +:doc:`Binman <../package/binman>` as a standard way of putting an image > >> +together. > >> + > >> +Typically this works by running binman with the devicetree as an > input, to > >> +create the file image. Binman then outputs an updated devicetree which > is > >> +packed in the firmware image, so U-Boot can access the binman > definition and > >> +locate all the components. > >> + > >> +As with all configuration information, if another project is providing > the > >> +devicetree to U-Boot, it must provide a way to add this binman > definition into > >> +the devicetree it passes to U-Boot. This could be via a tooling > option, making > >> +use of `binman`, or alowing a .dtsi file to be merged in with what is > generated > >> +in the other project. > >> + > >> + > >> +Protecting the devicetree > >> +------------------------- > >> + > >> +U-Boot relies heavily on devicetree for correct operation. A corrupt > or invalid > >> +device can cause U-Boot to fail to start, behave incorrectly, crash > (e.g. if > >> +`CONFIG_OF_LIBFDT_ASSUME_MASK` is adjusted, or fail to boot an > Operating System. > >> +Within U-Boot, the devicetree is as important as any other part of the > source > >> +code. At ruuntime, the devicetree can be considered to be structured > rodata. > >> + > >> +With secure systems, care must be taken that the devicetree is valid: > >> + > >> +- If the code / rodata has a hash or signature, the devicetree should > also, if > >> + they are packaged separately. > >> +- If the code / rodata is write-protected when running, the devicetree > should be > >> + also. Note that U-Boot relocates its code and devicetree, so this is > not as > >> + simple as it sounds. U-Boot must write-protect these items after > relocating. > >> + > >> + > >> +Why does U-Boot have its nodes and properties? > >> +---------------------------------------------- > >> + > >> +See also :doc:`../devicetree/intro`. > >> + > >> +There has been pushback at the concept that U-Boot dares have its own > nodes and > >> +properties in the devicetree. > >> + > >> +Apart from these nodes and properties, U-Boot uses the same bindings > as Linux. > >> +A `u-boot.dtsi` file helps to keep U-Boot-specific changes in separate > files, > >> +making it easier to keep devicetree source files in U-Boot in sync > with Linux. > >> + > >> +As a counter-example, the Zephyr OS project takes a different > approach. It uses > >> +entirely different bindings, in general, making no effort to sync > devicetree > >> +source files with Linux. U-Boot strives to be compatible with Linux in > a number > >> +of ways, such as source code style and common APIs, to aid porting of > code > >> +between the projects. Devicetree is another way where U-Boot and Linux > follow a > >> +similar approach. > >> + > >> +Fundamentally, the idea that U-Boot cannot have its own tags flies in > the face > >> +of the devicetree specification (see dtspec_), which says: > >> + > >> + Nonstandard property names should specify a **unique string > prefix**, such as > >> + a stock ticker symbol, identifying the name of the company **or > organization** > >> + that defined the property. Examples: > >> + > >> + - fsl,channel-fifo-len > >> + - ibm,ppc-interrupt-server#s > >> + - **linux**,network-index > >> + > >> +It is also fundamentally unbalanced. Linux has many tags of its own > (some 36 in > >> +version 5.13) and at least one Linux-specific node, even if you ignore > things > >> +like flash partitions which clearly provide configuration information > to Linux. > >> + > >> +Practically speaking there are many reasons why U-Boot has its own > nodes and > >> +properties. Some examples: > >> + > >> +- Binding every device before relocation even if it won't be used, > consumes time > >> + and memory: tags on each node can specify which are needed in SPL or > before > >> + relocation. Linux has no such constraints. > >> + > >> +- Requiring the full clock tree to be up and running just to get the > debug UART > >> + running is inefficient. It is also and self-defeating, since if that > much > >> + code is working properly, you probably don't need the debug UART. A > devicetree > >> + property to provide the UART input-clock frequency is a simple > solution. > >> + > >> +- U-Boot does not have a user space to provide policy and > configuration. It > >> + cannot do what Linux does and run programs and look up filesystems > to figure > >> + out how to boot. > >> + > >> + > >> +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. > > > 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? > 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. 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). You can certain have a similar mechanism for binman. > If there > is a use case for that, please can you be specific about what we > cannot do with a combined devicetree? > > Regards, > Simon >
On Tue, 26 Oct 2021 at 18:27, Simon Glass <sjg@chromium.org> wrote: > > Hi Ilias, > > On Tue, 26 Oct 2021 at 08:06, Ilias Apalodimas > <ilias.apalodimas@linaro.org> wrote: > > > > Hi Simon, > > > > > + > > > > [...] > > > > > +This is why `CONFIG_OF_SEPARATE` should always be used when building U-Boot. > > > +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot ELF > > > +image as rodata, meaning that it is hard to find it and it cannot increase in > > > +size. > > > + > > > +When modifying the devicetree, the different cases to consider are as follows: > > > + > > > +- CONFIG_OF_SEPARATE > > > + This is easy, described above. Just change, replace or rebuild the > > > + devicetree so it suits your needs, then rerun binman or redo the `cat` > > > + operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb` > > > + > > > +- CONFIG_OF_EMBED > > > + This is tricky, since the devicetree cannot easily be located. If the EFL > > > + file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can be > > > + examined to find it. While it is possible to contract the file, it is not > > > + possible to expand the file since that would involve re-linking > > > + > > > +- CONFIG_OF_BOARD > > > + This is a board-specific situation, so needs to be considered on a > > > + case-by-case base. The devicetree must be modified so that the correct > > > + one is provided to U-Boot. How this is done depends entirely on the > > > + implementation of this option for the board. It might require injecting the > > > + changes into a different project somehow using tooling available there, or > > > + it might involve merging an overlay file at runtime to obtain the desired > > > + result. > > > > I thought this document was trying to describe the current situation in > > U-Boot. If so, the current CONFIG_OF_BOARD usage is far from what we have > > here. > > Can you be more specific? What is the difference here? Also see the > doc update later in the series, after OF_BOARD becomes a bool option. The doc you sent says "devicetree must be modified so that the correct one is provided to U-Boot. By this I assume you mean the 'config/' node etc right? If that's the case this is *not* what is currently happening. We simply replace the entire device tree with whatever was configured. Regards /Ilias > > Regards, > SImon
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: >> > 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. 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. 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? What I would like, to package up the firmware for ANY board, after all the building is done in various projects: binman -b <board> >> >> If there >> is a use case for that, please can you be specific about what we >> cannot do with a combined devicetree? Regards, SImon
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: > >> > 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 ;-) > > 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. > 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. In a short term future (see Alibaba and Marvell announcements) you will have to deal with Arm v9 realms and associated firmware. > >> > >> If there > >> is a use case for that, please can you be specific about what we > >> cannot do with a combined devicetree? > > Regards, > SImon >
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: >> >> > 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? >> >> >> >> >> If there >> >> is a use case for that, please can you be specific about what we >> >> cannot do with a combined devicetree? Regards, SImon
On Wed, 27 Oct 2021 at 21:33, Simon Glass <sjg@chromium.org> wrote: > > 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: > >> >> > 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
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: > >> >> > 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. > 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 >
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 <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: > > >> > 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?
Hi Ilias, On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > On Wed, 27 Oct 2021 at 21:33, Simon Glass <sjg@chromium.org> wrote: > > > > 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: > > >> >> > 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? 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? I am very happy to help and provide part of the solution, but it needs a shared vision. 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 know you have made big efforts to engage, Ilias. We have spoken many times and I'm sure f2f would be easier. Regards, Simon
Hi Tom Le mer. 27 oct. 2021 à 21:48, Tom Rini <trini@konsulko.com> a écrit : > 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 <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: > > > >> > 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? may be none. The DT may contain only secure devices and devices for which there are no Linux drivers (clocks or others). I am not sure “secure device” is clear. This is a device that is separated by hardware methods to be only accessible by EL3, secure ELx. So even if you have secure mmio range you can’t access it from normal world at all. > > > -- > Tom >
Hi Simon, [...] > > > > > > 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 There's no pushback at all, apart from the TPM one. (and for a very good reason I've explained over and over again). In fact we add the sefltests as part of our patchsets. > 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. I guess you mean [1]. I've lost count of how many times I responded to this. Threads [2], [3] and [4] are just a few examples, so I just got tired or replying the same thing over and over. So bottom line, we are contributing selftests as always, we just don't agree with the way *you* want this specific TPM test, trying to force us into sandbox. So instead of respecting what we have (which btw is acceptable from u-boot's perspective and cleans up a lot of the TPM crud along the way), you went ahead making misleading statements on the selftests we contribute, in general. What's even more annoying is that, as I showed you, we pretty much add a selftest for *every* feature we add. Excellent ... that's certainly ... encouraging ... and very productive. > > 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? > Of course I disagree. People decided not to use SPL for their own reasons. I am certainly not qualified to answer why Arm choose to do that, but it seems to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure U-Boot is compatible and remains the de-facto choice for embedded boot loaders playing nicely with all the new FSBLs come up with. If you cosinder SPL and U-Boot the center of the known universe, we certainly view things differently. FWIW it's *our* work mostly that made U-Boot SystemReady compliant, which is something Arm pushes for [5]. > I'm sorry if you find this a bit sharp. Which part? The first one wrt to selftests is not sharp. It's manipulative and utterly unacceptable for me, not to mention entirely fabricated. The latter on bootloading fragmentation, I am always happy to discuss. > 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? I am > very happy to help and provide part of the solution, but it needs a > shared vision. There's a TF-A mailing list, we can certainly engage there and try to align our ideas/designs. > > 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 know you have made big efforts to engage, Ilias. We > have spoken many times and I'm sure f2f would be easier. > > > 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 know you have made big efforts to engage, Ilias. We > have spoken many times and I'm sure f2f would be easier. Maybe, hopefully travelling will restart soon. [1] https://lore.kernel.org/u-boot/CAPnjgZ2mmcUKz0v=ysSvf17c6ab++-hEpO4rc0OeeAEz7pFA2g@mail.gmail.com/ [2] https://lore.kernel.org/u-boot/YVdlvpThuqr8jksL@apalos.home/ [3] https://lore.kernel.org/u-boot/CAC_iWjLWxPyEwPpG7v=1U1sxLOD4LXF+Vm+cGTHom9Mpz9pAgw@mail.gmail.com/ [4] https://lore.kernel.org/u-boot/YVGGRqgVAiHvd1aR@apalos.home/ [5] https://www.arm.com/why-arm/architecture/systems/systemready-certification-program/ir?_ga=2.140829686.578781084.1635493248-857780164.1580291819 Regards /Ilias
Hi Simon (I keep getting messages about delivery problems so I don't know what went through or not) On Wed, 27 Oct 2021 at 21:52, Simon Glass <sjg@chromium.org> wrote: > > Hi Ilias, > > On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas > <ilias.apalodimas@linaro.org> wrote: > > > > On Wed, 27 Oct 2021 at 21:33, Simon Glass <sjg@chromium.org> wrote: > > > > > > 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: > > > >> >> > 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. > > 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. > > Regards, > Simon -- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
On Fri, Oct 29, 2021 at 01:20:52PM +0300, Ilias Apalodimas wrote: > Hi Simon, > > [...] > > > > > > > > > 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 > > There's no pushback at all, apart from the TPM one. (and for a very good > reason I've explained over and over again). In fact we add the sefltests > as part of our patchsets. And, for that set of TPM things, I agree with NOT making sandbox the requirement there. As QEMU is able to provide a TPM that will see real world usage, that's what we need to validate against primarily. > > 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. > > I guess you mean [1]. I've lost count of how many times I responded to > this. Threads [2], [3] and [4] are just a few examples, so I just got > tired or replying the same thing over and over. > > So bottom line, we are contributing selftests as always, we just don't agree > with the way *you* want this specific TPM test, trying to force us into sandbox. > So instead of respecting what we have (which btw is acceptable from u-boot's > perspective and cleans up a lot of the TPM crud along the way), you went ahead > making misleading statements on the selftests we contribute, in general. What's > even more annoying is that, as I showed you, we pretty much add a selftest > for *every* feature we add. Excellent ... that's certainly ... encouraging ... and > very productive. > > > > > 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? > > > > Of course I disagree. People decided not to use SPL for their own reasons. > I am certainly not qualified to answer why Arm choose to do that, but it seems > to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure > U-Boot is compatible and remains the de-facto choice for embedded boot > loaders playing nicely with all the new FSBLs come up with. If you > cosinder SPL and U-Boot the center of the known universe, we certainly view > things differently. FWIW it's *our* work mostly that made U-Boot SystemReady > compliant, which is something Arm pushes for [5]. Let me say for the record that I am appreciative of the fact the Linaro has been putting so much effort in to U-Boot, both in terms of tests and also in general SystemReady compliance work.
Hi Ilias, On Fri, 29 Oct 2021 at 04:20, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > Hi Simon, > > [...] > > > > > > > > > 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 > > There's no pushback at all, apart from the TPM one. (and for a very good > reason I've explained over and over again). In fact we add the sefltests > as part of our patchsets. > > > 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. > > I guess you mean [1]. I've lost count of how many times I responded to > this. Threads [2], [3] and [4] are just a few examples, so I just got > tired or replying the same thing over and over. > > So bottom line, we are contributing selftests as always, we just don't agree > with the way *you* want this specific TPM test, trying to force us into sandbox. > So instead of respecting what we have (which btw is acceptable from u-boot's > perspective and cleans up a lot of the TPM crud along the way), you went ahead > making misleading statements on the selftests we contribute, in general. What's > even more annoying is that, as I showed you, we pretty much add a selftest > for *every* feature we add. Excellent ... that's certainly ... encouraging ... and > very productive. > > > > > 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? > > > > Of course I disagree. People decided not to use SPL for their own reasons. > I am certainly not qualified to answer why Arm choose to do that, but it seems > to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure > U-Boot is compatible and remains the de-facto choice for embedded boot > loaders playing nicely with all the new FSBLs come up with. If you > cosinder SPL and U-Boot the center of the known universe, we certainly view > things differently. FWIW it's *our* work mostly that made U-Boot SystemReady > compliant, which is something Arm pushes for [5]. > > > I'm sorry if you find this a bit sharp. > > Which part? The first one wrt to selftests is not sharp. It's > manipulative and utterly unacceptable for me, not to mention entirely > fabricated. > > The latter on bootloading fragmentation, I am always happy to discuss. My comment was about the push-back I feel I have received when requesting tests. It was a poor choice of words since it suggests this is an ongoing problem when in fact many tests have been written. So I would like to withdraw that and I am sorry for saying that and for upsetting you. I certainly agree that Linaro has written lots of tests and this is great. Thank you to you and Linaro for that. The business of how the tests are written can be handled in other threads. > > > 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? I am > > very happy to help and provide part of the solution, but it needs a > > shared vision. > > There's a TF-A mailing list, we can certainly engage there and try to align > our ideas/designs. > > > > > 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 know you have made big efforts to engage, Ilias. We > > have spoken many times and I'm sure f2f would be easier. > > > > > > > > > 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 know you have made big efforts to engage, Ilias. We > > have spoken many times and I'm sure f2f would be easier. > > Maybe, hopefully travelling will restart soon. I think the whole issue in this thread comes down to a matter of alignment. As you can tell, I am frustrated with where things are headed and hope we can course-correct at some point. Regards, Simon > > [1] https://lore.kernel.org/u-boot/CAPnjgZ2mmcUKz0v=ysSvf17c6ab++-hEpO4rc0OeeAEz7pFA2g@mail.gmail.com/ > [2] https://lore.kernel.org/u-boot/YVdlvpThuqr8jksL@apalos.home/ > [3] https://lore.kernel.org/u-boot/CAC_iWjLWxPyEwPpG7v=1U1sxLOD4LXF+Vm+cGTHom9Mpz9pAgw@mail.gmail.com/ > [4] https://lore.kernel.org/u-boot/YVGGRqgVAiHvd1aR@apalos.home/ > [5] https://www.arm.com/why-arm/architecture/systems/systemready-certification-program/ir?_ga=2.140829686.578781084.1635493248-857780164.1580291819 > > Regards > /Ilias
Hi François, On Fri, 29 Oct 2021 at 11:07, François Ozog <francois.ozog@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 <sjg@chromium.org> wrote: > > > > Hi Ilias, > > > > On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas > > <ilias.apalodimas@linaro.org> wrote: > > > > > > On Wed, 27 Oct 2021 at 21:33, Simon Glass <sjg@chromium.org> wrote: > > > > > > > > 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: > > > > >> >> > 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
Hi Simon, [...] > > > > > > > > > > > > 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 > > > > There's no pushback at all, apart from the TPM one. (and for a very good > > reason I've explained over and over again). In fact we add the sefltests > > as part of our patchsets. > > > > > 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. > > > > I guess you mean [1]. I've lost count of how many times I responded to > > this. Threads [2], [3] and [4] are just a few examples, so I just got > > tired or replying the same thing over and over. > > > > So bottom line, we are contributing selftests as always, we just don't agree > > with the way *you* want this specific TPM test, trying to force us into sandbox. > > So instead of respecting what we have (which btw is acceptable from u-boot's > > perspective and cleans up a lot of the TPM crud along the way), you went ahead > > making misleading statements on the selftests we contribute, in general. What's > > even more annoying is that, as I showed you, we pretty much add a selftest > > for *every* feature we add. Excellent ... that's certainly ... encouraging ... and > > very productive. > > > > > > > > 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? > > > > > > > Of course I disagree. People decided not to use SPL for their own reasons. > > I am certainly not qualified to answer why Arm choose to do that, but it seems > > to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure > > U-Boot is compatible and remains the de-facto choice for embedded boot > > loaders playing nicely with all the new FSBLs come up with. If you > > cosinder SPL and U-Boot the center of the known universe, we certainly view > > things differently. FWIW it's *our* work mostly that made U-Boot SystemReady > > compliant, which is something Arm pushes for [5]. > > > > > I'm sorry if you find this a bit sharp. > > > > Which part? The first one wrt to selftests is not sharp. It's > > manipulative and utterly unacceptable for me, not to mention entirely > > fabricated. > > > > The latter on bootloading fragmentation, I am always happy to discuss. > > My comment was about the push-back I feel I have received when > requesting tests. It was a poor choice of words since it suggests this > is an ongoing problem when in fact many tests have been written. So I > would like to withdraw that and I am sorry for saying that and for > upsetting you. I certainly agree that Linaro has written lots of tests > and this is great. Thank you to you and Linaro for that. The business > of how the tests are written can be handled in other threads. Thanks, I appreciate this. Let's just forget this ever happened. The discussions are usually constructive and I am happy with the general progress, despite of the differences of opinion. > > > > > > 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? I am > > > very happy to help and provide part of the solution, but it needs a > > > shared vision. > > > > There's a TF-A mailing list, we can certainly engage there and try to align > > our ideas/designs. > > > > > > > > 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 know you have made big efforts to engage, Ilias. We > > > have spoken many times and I'm sure f2f would be easier. > > > > > > > > > > > > > > > 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 know you have made big efforts to engage, Ilias. We > > > have spoken many times and I'm sure f2f would be easier. > > > > Maybe, hopefully travelling will restart soon. > > I think the whole issue in this thread comes down to a matter of alignment. > > As you can tell, I am frustrated with where things are headed and hope > we can course-correct at some point. This is a matter of perspective to me. I've accepted the fact that firmware gets more complex. Whether I personally like it or not is a different story. One thing that's clear to me though is that we either have to adapt, or slowly become irrelevant. Thanks /Ilias > > Regards, > Simon > > > > > > [1] https://lore.kernel.org/u-boot/CAPnjgZ2mmcUKz0v=ysSvf17c6ab++-hEpO4rc0OeeAEz7pFA2g@mail.gmail.com/ > > [2] https://lore.kernel.org/u-boot/YVdlvpThuqr8jksL@apalos.home/ > > [3] https://lore.kernel.org/u-boot/CAC_iWjLWxPyEwPpG7v=1U1sxLOD4LXF+Vm+cGTHom9Mpz9pAgw@mail.gmail.com/ > > [4] https://lore.kernel.org/u-boot/YVGGRqgVAiHvd1aR@apalos.home/ > > [5] https://www.arm.com/why-arm/architecture/systems/systemready-certification-program/ir?_ga=2.140829686.578781084.1635493248-857780164.1580291819 > > > > Regards > > /Ilias
Hi Ilias, On Tue, 2 Nov 2021 at 09:38, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > Hi Simon, > > [...] > > > > > > > > > > > > > > > > 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 > > > > > > There's no pushback at all, apart from the TPM one. (and for a very good > > > reason I've explained over and over again). In fact we add the sefltests > > > as part of our patchsets. > > > > > > > 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. > > > > > > I guess you mean [1]. I've lost count of how many times I responded to > > > this. Threads [2], [3] and [4] are just a few examples, so I just got > > > tired or replying the same thing over and over. > > > > > > So bottom line, we are contributing selftests as always, we just don't agree > > > with the way *you* want this specific TPM test, trying to force us into sandbox. > > > So instead of respecting what we have (which btw is acceptable from u-boot's > > > perspective and cleans up a lot of the TPM crud along the way), you went ahead > > > making misleading statements on the selftests we contribute, in general. What's > > > even more annoying is that, as I showed you, we pretty much add a selftest > > > for *every* feature we add. Excellent ... that's certainly ... encouraging ... and > > > very productive. > > > > > > > > > > > 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? > > > > > > > > > > Of course I disagree. People decided not to use SPL for their own reasons. > > > I am certainly not qualified to answer why Arm choose to do that, but it seems > > > to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure > > > U-Boot is compatible and remains the de-facto choice for embedded boot > > > loaders playing nicely with all the new FSBLs come up with. If you > > > cosinder SPL and U-Boot the center of the known universe, we certainly view > > > things differently. FWIW it's *our* work mostly that made U-Boot SystemReady > > > compliant, which is something Arm pushes for [5]. > > > > > > > I'm sorry if you find this a bit sharp. > > > > > > Which part? The first one wrt to selftests is not sharp. It's > > > manipulative and utterly unacceptable for me, not to mention entirely > > > fabricated. > > > > > > The latter on bootloading fragmentation, I am always happy to discuss. > > > > My comment was about the push-back I feel I have received when > > requesting tests. It was a poor choice of words since it suggests this > > is an ongoing problem when in fact many tests have been written. So I > > would like to withdraw that and I am sorry for saying that and for > > upsetting you. I certainly agree that Linaro has written lots of tests > > and this is great. Thank you to you and Linaro for that. The business > > of how the tests are written can be handled in other threads. > > Thanks, I appreciate this. Let's just forget this ever happened. The discussions are > usually constructive and I am happy with the general progress, despite > of the differences of opinion. OK thank you. Yes I agree. > > > > > > > > > > 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? I am > > > > very happy to help and provide part of the solution, but it needs a > > > > shared vision. > > > > > > There's a TF-A mailing list, we can certainly engage there and try to align > > > our ideas/designs. > > > > > > > > > > > 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 know you have made big efforts to engage, Ilias. We > > > > have spoken many times and I'm sure f2f would be easier. > > > > > > > > > > > > > > > > > > > > > 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 know you have made big efforts to engage, Ilias. We > > > > have spoken many times and I'm sure f2f would be easier. > > > > > > Maybe, hopefully travelling will restart soon. > > > > I think the whole issue in this thread comes down to a matter of alignment. > > > > As you can tell, I am frustrated with where things are headed and hope > > we can course-correct at some point. > > This is a matter of perspective to me. I've accepted the fact that > firmware gets more complex. Whether I personally like it or not is a > different story. One thing that's clear to me though is that we either > have to adapt, or slowly become irrelevant. I have a lot of ideas here and I think we can do much better, not just on ARM but Intel/AMD also. I can't imagine how we could discuss these except in-person for a day or two with a whiteboard, so for now I will just let things ride. Regards, Simon
diff --git a/doc/develop/devicetree/dt_update.rst b/doc/develop/devicetree/dt_update.rst new file mode 100644 index 00000000000..3d4902e3592 --- /dev/null +++ b/doc/develop/devicetree/dt_update.rst @@ -0,0 +1,556 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Updating the devicetree +======================= + +U-Boot uses devicetree for runtime configuration and storing required blobs or +any other information it needs to operate. This is called the 'control' +devicetree since it controls U-Boot. It is possible to update the control +devicetree separately from actually building U-Boot. This provides a good degree +of control and flexibility for firmware that uses U-Boot in conjunction with +other project. + +There are many reasons why it is useful to modify the devicetree after building +it: + +- Configuration can be changed, e.g. which UART to use +- A serial number can be added +- Public keys can be added to allow image verification +- Console output can be changed (e.g. to select serial or vidconsole) + +This section describes how to work with devicetree to accomplish your goals. + +See also :doc:`../devicetree/control` for a basic summary of the available +features. + + +Devicetree source +----------------- + +Every board in U-Boot must include a devicetree sufficient to build and boot +that board on suitable hardware (or emulation). This is specified using the +`CONFIG DEFAULT_DEVICE_TREE` option. + + +Current situation (October 2021) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty, +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an enormous +amount of confusion and some wasted effort. This was not intended. Support for +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. + +Some of the problems created are: + +- It is not obvious that the devicetree is coming from another project + +- There is no way to see even a sample devicetree for these platform in U-Boot, + so it is hard to know what is going on, e.g. which devices are typically + present + +- The other project may not provide a way to support U-Boot's requirements for + devicetree, such as the /config node. Note: On the U-Boot mailing linst, this + was only discovered after weeks of discussion and confusion + +- For QEMU specifically, consulting two QEMU source files is required, for which + there are no references in U-Boot documentation. The code is generating a + devicetree, but it is not clear what controls affect this generation. + +Specifically on the changes in U-Bootm `CONFIG_OF_BOARD` was added in +rpi_patch_ for Raspberry Pi, which does have an in-tree devicetree, but this +feature has since been used for boards that don't + +Once this bug is fixed, CONFIG_OF_BOARD will override (at runtime) the +evicetree suppled with U-Boot, but will otherwise use CONFIG_OF_SEPARATE for the +in-tree build. So these two will become options, moving out of the 'choice' in +`dts/Kconfig`. + +This means that there is a basic devicetree build in the U-Boot tree, for +build-testing, consistency and documentation purposes, but at runtime U-Boot can +accept its devicetree from another source. The in-tree devicetree may contain +U-Boot-specific features (in u-boot*.dtsi files) and this may prove useful for +the other project, so it can ensure that U-Boot functions correctly and supports +all its expected features. + +To be clear, while U-Boot has its own copy of the devicetree source for each +board, this must match the Linux source, perhaps with some u-boot.dtsi +additions. The intent here is not to create a separate binding, just to provide +a representative devicetree in U-Boot. + +Offending boards are: + +- rpi_4 and rpi_4_32b (other rpi boards do have an in-tree devicetree) +- qemu_arm64 +- qemu_arm +- qemu-ppce500 +- qemu-riscv32 +- qemu-riscv32_smode +- qemu-riscv64 +- qemu-riscv64_smode + +All of these need to have a devicetree added in-tree. This is targeted to be +fixed in the 2022.01 release. + + +Building the devicetree +----------------------- + +U-Boot automatically builds the devicetree for a board, from the +`arch/<arch>/dts` directory. The Makefile in those directories has rules for +building devicetree files. It is preferable to avoid target-specific rules in +those files: i.e. all boards for a particular SoC should be built at once, +where practical. Apart from simplifying the Makefile, this helps to efficiently +(and immediately) ensure that changes in one board's DT do not break others that +are related. Building devicetrees is fast, so performance is seldom a concern +here. + + +Overriding the default devicetree +--------------------------------- + +When building U-Boot, the `DEVICE_TREE` environment variable allows the +default devicetree file to be overridden at build time. This can be useful if +modifications have to be made to the in-tree devicetree file, for the benefit +of a downstream build system. Note that the in-tree devicetree must be +sufficient to build and boot, so this is not a way to bypass that requirement. + + +Modifying the devicetree after building +--------------------------------------- + +While it is generally painful and hacky to modify the code or rodata of a +program after it is built, in many cases it is useful to do so, e.g. to add +configuration information like serial numbers, enabling/disabling features, etc. + +Devicetree provides a very nice solution to these problems since it is +structured data and it is relatively easy to change it, even in binary form +(see fdtput). + +U-Boot takes care that the devicetree is easily accessible after the build +process. In fact it is placed in a separate file called `u-boot.dtb`. If the +build system wants to modify or replace that file, it can do so. Then all that +is needed is to run `binman update` to update the file inside the image. If +binman is not used, then `u-boot-nodtb.bin` and the new `u-boot.dtb` can simply +be concatenated to achieve the desired result. U-Boot happily copes with the +devicetree growing or shrinking. + +The `u-boot.bin` image contains both pieces. While it is possible to locate the +devicetree within the image using the signature at the start of the file, this +is a bit messy. + +This is why `CONFIG_OF_SEPARATE` should always be used when building U-Boot. +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot ELF +image as rodata, meaning that it is hard to find it and it cannot increase in +size. + +When modifying the devicetree, the different cases to consider are as follows: + +- CONFIG_OF_SEPARATE + This is easy, described above. Just change, replace or rebuild the + devicetree so it suits your needs, then rerun binman or redo the `cat` + operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb` + +- CONFIG_OF_EMBED + This is tricky, since the devicetree cannot easily be located. If the EFL + file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can be + examined to find it. While it is possible to contract the file, it is not + possible to expand the file since that would involve re-linking + +- CONFIG_OF_BOARD + This is a board-specific situation, so needs to be considered on a + case-by-case base. The devicetree must be modified so that the correct + one is provided to U-Boot. How this is done depends entirely on the + implementation of this option for the board. It might require injecting the + changes into a different project somehow using tooling available there, or + it might involve merging an overlay file at runtime to obtain the desired + result. + + +Use of U-Boot /config node +-------------------------- + +A common problem with firmware is that many builds are needed to deal with the +slight variations between different, related models. For example, one model may +have a TPM and another may not. Devicetree provides an excellent solution to +this problem, in that the devicetree to actually use on a platform can be +injected in the factory based on which model is being manufactured at the time. + +A related problem causing build proliferation is dealing with the differences +between development firmware, developer-friendly firmware (e.g. with all +security features present but with the ability to access the command line), +test firmware (which runs tests used in the factory), final production firmware +(before signing), signed firmware (where the signatures have been inserted) and +the like. Ideally all or most of these should use the same U-Boot build, with +just some options to determine the features available. For example, being able +to control whether the UART console or JTAG are available, on any image, is a +great debugging aid. + +When the firmware consists of multiple parts, it is helpful that all operate +the same way at runtime, regardless of how they were built. This can be achieved +by passing the runtime configuration (e.g. 'enable UART console) along the chain +through each firmware stage. It is frustrating to have to replicate a bug on +production firmware which does happen on developer firmware, because they are +completely different builds. + +The /config node provides useful functionality for this. It allows the different +controls to be 'factored out' of the U-Boot binary, so they can be controlled +separately from the initial source-code build. The node can be easily updated by +a build or factory tool and can control various features in U-Boot. It is +similar in concept to a Kconfig option, except that it can be changed after +U-Boot is built. + +The /config node is similar in concept to the `/chosen node`_ except that it is +for passing information *into* firmware instead of from firmware to the +Operating System. Also, while Linux has a (sometimes extremely long) command +line, U-Boot does not support this. The devicetree provides a more structured +approach in any case. + + +Devicetree in another project +----------------------------- + +In some cases U-Boot receive its devicetree at runtime from a program that calls +it. For example ARM's Trusted Firmware A (`TF-A`_) may have a devicetree that it +passes to U-Boot. This overrides any devicetree build by U-Boot. When packaging +the firmware, the U-Boot devicetree may in fact be left out if it can be +guaranteed that it will receive one from another project. + +In this case, the devicetree in the other project must track U-Boot's use of +device tree, for the following reasons: + +- U-Boot only has one devicetree. See `Why not have two devicetrees?`_. +- For a consistent firmware build, decisions made in early stages should be + communicated to later ones at runtime. For example, if the serial console is + enabled in an early stage, it should be enabled in U-Boot too. +- U-Boot is quite capable of managing its own copy of the devicetree. If + another project wants to bypass this (often for good reason), it is reasonable + that it should take on the (fairly small) requirements that U-Boot features + that rely on devicetree are still available +- The point here is not that *U-Boot needs this extra node*, or *U-Boot needs + to have this public key*. These features are present in U-Boot in service of + the entire firmware system. If the U-Boot features are used, but cannot be + supported in the normal way, then there is pressure to implement these + features in other ways. In the end, we would have a different mechanism for + every other project that uses U-Boot. This introduces duplicate ways of doing + the same thing, needlessly increases the complexity of the U-Boot source code, + forces authors to consider parallel implementations when writing new features, + makes U-Boot harder to test, complicates documentation and confuses the + runtime flow of U-Boot. If every board did things its own way rather than + contributing to the common code, U-Boot would lose a lot of its cross-platform + value. + +The above does not indicate *bad design* within U-Boot. Devicetree is a core +component of U-Boot and U-Boot makes use of it to the full. It solves a myriad +of problems that would otherwise need their own special C struct, binary format, +special property, tooling for viewing and updating, etc. + +Specifically, the other project must provide a way to add configuration and +other information to the devicetree for use by U-Boot, such as the /config node. +Note that the U-Boot in-tree devicetree source must be sufficient to build and +boot, so this is not a way to bypass that requirement. + +If binman is used, the devicetree source in U-Boot must contain the binman +definition so that a valid image can be build. This helps people discover what +other firmware components are needed and seek out appropriate documentation. + +If verified boot is used, the project must provide a way to inject a public key, +certificate or other material into the U-Boot devicetree so that it is available +to U-Boot at runtime. See `Signing with U-Boot devicetree`_. This may be +through tooling in the project itself or by making use of U-Boot's tooling. + + +Devicetree generated on-the-fly in another project +-------------------------------------------------- + +In some rare cases, another project may wish to create a devicetree for U-Boot +entirely on-the-fly, then pass it to U-Boot at runtime. The only known example +of this at the time of writing (2021) is QEMU, for ARM (`QEMU ARM`_) and +RISC-V (`QEMU RISC-V`_). + +In effect, when the board boots, U-Boot is *downstream* of the other project. +It is entirely reliant on that project for its correct operation. + +This does not mean to imply that the other project is creating its own, +incompatible devicetree. In fact QEMU generates a valid devicetree which is +suitable for both U-Boot and Linux. It is quite normal for a devicetree to be +present in flash and be made available to U-Boot at runtime. What matters is +where the devicetree comes from. If the other project builds a devicetree for +U-Boot then it needs to support adding the things needed by U-Boot features. +Without them, for example: + +- U-Boot may not boot because too many devices are enabled before relocation +- U-Boot may not have access to the developer or production public keys used for + signing +- U-Boot may not support controlling whether the console is enabled +- U-Boot may not be know which MMC device to boot from +- U-Boot may not be able to find other firmware components that it needs to load + +Normally, supporting U-Boot's features is trivial, since the devicetree compiler +(dtc) can compile the source, including any U-Boot pieces. So the burden is +extremely low. + +In this case, the devicetree in the other project must track U-Boot's use of +device tree, so that it remains compatible. See `Devicetree in another project`_ +for reasons why. + +If a particular version of the project is needed for a particular version of +U-Boot, that must be documented in both projects. + +Further, it must provide a way to add configuration and other information to +the devicetree for use by U-Boot, such as the `/config` node and the tags used +by driver model. Note that the U-Boot in-tree devicetree must be sufficient to +build and boot, so this is not a way to bypass that requirement. + +More specifically, tooling or command-line arguments must provide a way to +add a `/config` node or items within that node, so that U-Boot can receive a +suitable configuration. It must provide a way of adding `u-boot,dm-...` tags for +correct operation of driver model. These options can then be used as part of the +build process, which puts the firmware image together. For binman, a way must be +provided to add the binman definition into the devicetree in the same way. + +One way to do this is to allow a .dtsi file to be merged in with the generated +devicetree. + +Note that the burden goes both ways. If a new feature is added to U-Boot which +needs support in another project, then the author of the U-Boot patch must add +any required support to the other project. + + +Passing the devicetree through to Linux +--------------------------------------- + +Ideally U-Boot and Linux use the same devicetree source, even though it is +hosted in separate projects. U-Boot adds some extra pieces, such as the +`config/` node and tags like `u-boot,dm-spl`. Linux adds some extra pieces, such +as `linux,default-trigger` and `linux,code`. This should not interfere with +each other. + +In principle it is possible for U-Boot's control devicetree to be passed to +Linux. This is, after all, one of the goals of devicetree and the original +Open Firmware project, to have the firmware provide the hardware description to +the Operating System. + +For boards where this approach is used, care must be taken. U-Boot typically +needs to 'fix up' the devicetree before passing it to Linux, e.g. to add +information about the memory map, about which serial console is used, provide +the kernel address space layout randomization (KASLR) seed or select whether the +console should be silenced for a faster boot. + +Fix-ups involve modifying the devicetree. If the control devicetree is used, +that means the control devicetree could be modified, while U-Boot is using it. +Removing a device and reinserting it can cause problems if the devicetree offset +has changed, for example, since the device will be unable to locates its +devicetree properties at the expected devicetree offset, which is a fixed +integer. + +To deal with this, it is recommended to employ one or more of the following +approaches: + +- Make a copy of the devicetree and 'fix up' the copy, leaving the control + devicetree alone +- Enable `CONFIG_OF_LIVE` so that U-Boot makes its own copy of the devicetree + during relocation; fixups then happen on the original flat tree +- Ensure that fix-ups happen after all loading has happened and U-Boot has + completed image verification + +In practice,the last point is typically observed, since boot_prep_linux() is +called just before jumping to Linux, long after signature verification, for +example. But it is important to make sure that this line is not blurred, +particularly if untrusted user data is involved. + + +Devicetree use cases that must be supported +------------------------------------------- + +Regardless of how the devicetree is provided to U-Boot at runtime, various +U-Boot features must be fully supported. This section describes some of these +features and the implications for other projects. + +If U-Boot uses its own in-tree devicetree these features are supported +automatically. + + +Signing with U-Boot devicetree +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +U-Boot supports signing a payload so that it can be verified to have been +created by a party owning a private key. This is called verified boot in U-Boot +(see doc/uImage.FIT/verified-boot.txt). + +Typically this works by creating a FIT and then running the `mkimage` tool to +add signatures for particular images. As part of this process, `mkimage` writes +a public key to the U-Boot devicetree, although this can be done separately. +See fdt_add_pubkey_ for patches for a suitable tool, for example. + +As with all configuration information, if another project is providing the +devicetree to U-Boot, it must provide a way to add this public key into the +devicetree it passes to U-Boot. This could be via a tooling option, making use +of `mkimage`, or allowing a .dtsi file to be merged in with what is generated in +the other project. + + +Providing the binman image definition +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In complex systems U-Boot must locate and make use of other firmware components, +such as images for the user interface, files containing peripheral firmware, +multiple copies of U-Boot for use with A/B boot, etc. U-Boot uses +:doc:`Binman <../package/binman>` as a standard way of putting an image +together. + +Typically this works by running binman with the devicetree as an input, to +create the file image. Binman then outputs an updated devicetree which is +packed in the firmware image, so U-Boot can access the binman definition and +locate all the components. + +As with all configuration information, if another project is providing the +devicetree to U-Boot, it must provide a way to add this binman definition into +the devicetree it passes to U-Boot. This could be via a tooling option, making +use of `binman`, or alowing a .dtsi file to be merged in with what is generated +in the other project. + + +Protecting the devicetree +------------------------- + +U-Boot relies heavily on devicetree for correct operation. A corrupt or invalid +device can cause U-Boot to fail to start, behave incorrectly, crash (e.g. if +`CONFIG_OF_LIBFDT_ASSUME_MASK` is adjusted, or fail to boot an Operating System. +Within U-Boot, the devicetree is as important as any other part of the source +code. At ruuntime, the devicetree can be considered to be structured rodata. + +With secure systems, care must be taken that the devicetree is valid: + +- If the code / rodata has a hash or signature, the devicetree should also, if + they are packaged separately. +- If the code / rodata is write-protected when running, the devicetree should be + also. Note that U-Boot relocates its code and devicetree, so this is not as + simple as it sounds. U-Boot must write-protect these items after relocating. + + +Why does U-Boot have its nodes and properties? +---------------------------------------------- + +See also :doc:`../devicetree/intro`. + +There has been pushback at the concept that U-Boot dares have its own nodes and +properties in the devicetree. + +Apart from these nodes and properties, U-Boot uses the same bindings as Linux. +A `u-boot.dtsi` file helps to keep U-Boot-specific changes in separate files, +making it easier to keep devicetree source files in U-Boot in sync with Linux. + +As a counter-example, the Zephyr OS project takes a different approach. It uses +entirely different bindings, in general, making no effort to sync devicetree +source files with Linux. U-Boot strives to be compatible with Linux in a number +of ways, such as source code style and common APIs, to aid porting of code +between the projects. Devicetree is another way where U-Boot and Linux follow a +similar approach. + +Fundamentally, the idea that U-Boot cannot have its own tags flies in the face +of the devicetree specification (see dtspec_), which says: + + Nonstandard property names should specify a **unique string prefix**, such as + a stock ticker symbol, identifying the name of the company **or organization** + that defined the property. Examples: + + - fsl,channel-fifo-len + - ibm,ppc-interrupt-server#s + - **linux**,network-index + +It is also fundamentally unbalanced. Linux has many tags of its own (some 36 in +version 5.13) and at least one Linux-specific node, even if you ignore things +like flash partitions which clearly provide configuration information to Linux. + +Practically speaking there are many reasons why U-Boot has its own nodes and +properties. Some examples: + +- Binding every device before relocation even if it won't be used, consumes time + and memory: tags on each node can specify which are needed in SPL or before + relocation. Linux has no such constraints. + +- Requiring the full clock tree to be up and running just to get the debug UART + running is inefficient. It is also and self-defeating, since if that much + code is working properly, you probably don't need the debug UART. A devicetree + property to provide the UART input-clock frequency is a simple solution. + +- U-Boot does not have a user space to provide policy and configuration. It + cannot do what Linux does and run programs and look up filesystems to figure + out how to boot. + + +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. + +- **Signing flow** - The current signing flow is simple as it involves running + `mkimage` with the U-Boot devicetree. This would have to be updated to use the + special devicetree. Some way of telling the user that they have done it wrong + would have to be invented. + +Overall, adding a second devicetree would create enormous confusion and +complexity. It seems a lot cheaper to solve this by a change of attitude. + + +.. _rpi_patch: https://patchwork.ozlabs.org/project/uboot/patch/20170402082520.32546-1-deymo@google.com/ +.. _`TF-A`: https://www.trustedfirmware.org/projects/tf-a +.. _`QEMU ARM`: https://github.com/qemu/qemu/blob/master/hw/arm/virt.c +.. _`QEMU RISC-V`: https://github.com/qemu/qemu/blob/master/hw/riscv/virt.c +.. _`/chosen node`: https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt +.. _fdt_add_pubkey: https://patchwork.ozlabs.org/project/uboot/list/?series=157843&state=* +.. _dtspec: https://www.devicetree.org/specifications/ diff --git a/doc/develop/devicetree/index.rst b/doc/develop/devicetree/index.rst index fa5db3eb76e..b5b33dfea0f 100644 --- a/doc/develop/devicetree/index.rst +++ b/doc/develop/devicetree/index.rst @@ -11,3 +11,4 @@ build-time and runtime configuration. intro control + dt_update