* [PATCH v6 01/25] doc: Add documentation about devicetree usage
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
@ 2021-12-02 15:58 ` Simon Glass
2021-12-03 12:34 ` Heinrich Schuchardt
2021-12-02 15:58 ` [PATCH v6 02/25] arm: qemu: Mention -nographic in the docs Simon Glass
` (25 subsequent siblings)
26 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:58 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Marcel Ziswiler
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 v6:
- Fix description of OF_BOARD so it refers just to the current state
- Explain that the 'two devicetrees' refers to two *control* devicetrees
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 | 555 +++++++++++++++++++++++++++
doc/develop/devicetree/index.rst | 1 +
2 files changed, 556 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..a1429d6e21a
--- /dev/null
+++ b/doc/develop/devicetree/dt_update.rst
@@ -0,0 +1,555 @@
+.. 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.
+
+
+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`). This would mean that U-Boot would be controlled by two
+devicetrees, i.e. OF_CONTROL would require/allow two devicetrees in order to
+work.
+
+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 used for controlling its
+ operation (although having multiple devicetrees to pass on to the OS is
+ common). U-Boot would be in the unfortunate position of having to describe
+ the purpose of the two control devicetrees 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
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
2021-12-02 15:58 ` [PATCH v6 01/25] doc: Add documentation about devicetree usage Simon Glass
@ 2021-12-03 12:34 ` Heinrich Schuchardt
2021-12-03 13:09 ` Heinrich Schuchardt
0 siblings, 1 reply; 136+ messages in thread
From: Heinrich Schuchardt @ 2021-12-03 12:34 UTC (permalink / raw)
To: Simon Glass
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Marcel Ziswiler, U-Boot Mailing List
On 12/2/21 16:58, Simon Glass 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 v6:
> - Fix description of OF_BOARD so it refers just to the current state
> - Explain that the 'two devicetrees' refers to two *control* devicetrees
>
> 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 | 555 +++++++++++++++++++++++++++
> doc/develop/devicetree/index.rst | 1 +
> 2 files changed, 556 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..a1429d6e21a
> --- /dev/null
> +++ b/doc/develop/devicetree/dt_update.rst
> @@ -0,0 +1,555 @@
> +.. 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
Even if you remove these lines in 17/25 I would prefer not to introduce
typos here:
%s/linst/list/
> + 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.
> +
> +
> +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.
Did you ever ask the QEMU community what they think about your ideas?
What was the reply?
Best regards
Heinrich
> +
> +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`). This would mean that U-Boot would be controlled by two
> +devicetrees, i.e. OF_CONTROL would require/allow two devicetrees in order to
> +work.
> +
> +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 used for controlling its
> + operation (although having multiple devicetrees to pass on to the OS is
> + common). U-Boot would be in the unfortunate position of having to describe
> + the purpose of the two control devicetrees 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
>
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
2021-12-03 12:34 ` Heinrich Schuchardt
@ 2021-12-03 13:09 ` Heinrich Schuchardt
2021-12-03 20:13 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Heinrich Schuchardt @ 2021-12-03 13:09 UTC (permalink / raw)
To: Simon Glass
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Marcel Ziswiler, U-Boot Mailing List
On 12/3/21 13:34, Heinrich Schuchardt wrote:
> On 12/2/21 16:58, Simon Glass 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 v6:
>> - Fix description of OF_BOARD so it refers just to the current state
>> - Explain that the 'two devicetrees' refers to two *control* devicetrees
>>
>> 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 | 555 +++++++++++++++++++++++++++
>> doc/develop/devicetree/index.rst | 1 +
>> 2 files changed, 556 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..a1429d6e21a
>> --- /dev/null
>> +++ b/doc/develop/devicetree/dt_update.rst
>> @@ -0,0 +1,555 @@
>> +.. 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
>
> Even if you remove these lines in 17/25 I would prefer not to introduce
> typos here:
>
> %s/linst/list/
>
>> + 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.
>> +
>> +
>> +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.
>
> Did you ever ask the QEMU community what they think about your ideas?
> What was the reply?
Looking at the thread
https://lore.kernel.org/all/20210926183410.256484-1-sjg@chromium.org/
the QEMU project said NAK. This matches the expectation that I expressed
repeatedly.
Why don't you mention the QEMU reply in this patch series and adjust
your design accordingly?
Best regards
Heinrich
>
> Best regards
>
> Heinrich
>
>> +
>> +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`). This would mean that U-Boot would be controlled by two
>> +devicetrees, i.e. OF_CONTROL would require/allow two devicetrees in
>> order to
>> +work.
>> +
>> +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 used for
>> controlling its
>> + operation (although having multiple devicetrees to pass on to the
>> OS is
>> + common). U-Boot would be in the unfortunate position of having to
>> describe
>> + the purpose of the two control devicetrees 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
>>
>
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
2021-12-03 13:09 ` Heinrich Schuchardt
@ 2021-12-03 20:13 ` Simon Glass
2021-12-03 20:28 ` Heinrich Schuchardt
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-03 20:13 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Marcel Ziswiler, U-Boot Mailing List
Hi Heinrich,
On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 12/3/21 13:34, Heinrich Schuchardt wrote:
> > On 12/2/21 16:58, Simon Glass 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 v6:
> >> - Fix description of OF_BOARD so it refers just to the current state
> >> - Explain that the 'two devicetrees' refers to two *control* devicetrees
> >>
> >> 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 | 555 +++++++++++++++++++++++++++
> >> doc/develop/devicetree/index.rst | 1 +
> >> 2 files changed, 556 insertions(+)
> >> create mode 100644 doc/develop/devicetree/dt_update.rst
> >>
[..]
> >> +
> >> +- 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
> >
> > Even if you remove these lines in 17/25 I would prefer not to introduce
> > typos here:
> >
> > %s/linst/list/
> >
OK I can fix that.
[..]
> >> +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.
> >
> > Did you ever ask the QEMU community what they think about your ideas?
> > What was the reply?
>
> Looking at the thread
> https://lore.kernel.org/all/20210926183410.256484-1-sjg@chromium.org/
> the QEMU project said NAK. This matches the expectation that I expressed
> repeatedly.
>
> Why don't you mention the QEMU reply in this patch series and adjust
> your design accordingly?
The QEMU maintainer may react when he sees a problem.
I have already clearly stated that there is no way we are have two
control DTBs. The overlay is also unworkable and unnecessary. That is
why I put so much effort into this patch, after all.
So for now, people will just have to deal with what QEMU provides. I
sent a patch to resolve the problem which can be accepted at any point
if people complain enough. So far only François has offered support
for it.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
2021-12-03 20:13 ` Simon Glass
@ 2021-12-03 20:28 ` Heinrich Schuchardt
2021-12-04 1:02 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Heinrich Schuchardt @ 2021-12-03 20:28 UTC (permalink / raw)
To: Simon Glass
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Marcel Ziswiler, U-Boot Mailing List
On 12/3/21 9:13 PM, Simon Glass wrote:
> Hi Heinrich,
>
> On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> On 12/3/21 13:34, Heinrich Schuchardt wrote:
>>> On 12/2/21 16:58, Simon Glass 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 v6:
>>>> - Fix description of OF_BOARD so it refers just to the current state
>>>> - Explain that the 'two devicetrees' refers to two *control* devicetrees
>>>>
>>>> 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 | 555 +++++++++++++++++++++++++++
>>>> doc/develop/devicetree/index.rst | 1 +
>>>> 2 files changed, 556 insertions(+)
>>>> create mode 100644 doc/develop/devicetree/dt_update.rst
>>>>
> [..]
>
>>>> +
>>>> +- 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
>>>
>>> Even if you remove these lines in 17/25 I would prefer not to introduce
>>> typos here:
>>>
>>> %s/linst/list/
>>>
>
> OK I can fix that.
>
> [..]
>
>>>> +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.
>>>
>>> Did you ever ask the QEMU community what they think about your ideas?
>>> What was the reply?
>>
>> Looking at the thread
>> https://lore.kernel.org/all/20210926183410.256484-1-sjg@chromium.org/
>> the QEMU project said NAK. This matches the expectation that I expressed
>> repeatedly.
>>
>> Why don't you mention the QEMU reply in this patch series and adjust
>> your design accordingly?
>
> The QEMU maintainer may react when he sees a problem.
Why are you unwilling to admit the problem? QEMU will never support
U-Boot specific stuff.
Please, develop concepts that solve U-Boot's needs within U-Boot.
Best regards
Heinrich
>
> I have already clearly stated that there is no way we are have two
> control DTBs. The overlay is also unworkable and unnecessary. That is
> why I put so much effort into this patch, after all.
>
> So for now, people will just have to deal with what QEMU provides. I
> sent a patch to resolve the problem which can be accepted at any point
> if people complain enough. So far only François has offered support
> for it.
>
> Regards,
> Simon
>
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
2021-12-03 20:28 ` Heinrich Schuchardt
@ 2021-12-04 1:02 ` Simon Glass
2021-12-04 11:06 ` François Ozog
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-04 1:02 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Marcel Ziswiler, U-Boot Mailing List
Hi Heinrich,
On Fri, 3 Dec 2021 at 13:28, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 12/3/21 9:13 PM, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>
> >> On 12/3/21 13:34, Heinrich Schuchardt wrote:
> >>> On 12/2/21 16:58, Simon Glass 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 v6:
> >>>> - Fix description of OF_BOARD so it refers just to the current state
> >>>> - Explain that the 'two devicetrees' refers to two *control* devicetrees
> >>>>
> >>>> 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 | 555 +++++++++++++++++++++++++++
> >>>> doc/develop/devicetree/index.rst | 1 +
> >>>> 2 files changed, 556 insertions(+)
> >>>> create mode 100644 doc/develop/devicetree/dt_update.rst
> >>>>
> > [..]
> >
> >>>> +
> >>>> +- 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
> >>>
> >>> Even if you remove these lines in 17/25 I would prefer not to introduce
> >>> typos here:
> >>>
> >>> %s/linst/list/
> >>>
> >
> > OK I can fix that.
> >
> > [..]
> >
> >>>> +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.
> >>>
> >>> Did you ever ask the QEMU community what they think about your ideas?
> >>> What was the reply?
> >>
> >> Looking at the thread
> >> https://lore.kernel.org/all/20210926183410.256484-1-sjg@chromium.org/
> >> the QEMU project said NAK. This matches the expectation that I expressed
> >> repeatedly.
> >>
> >> Why don't you mention the QEMU reply in this patch series and adjust
> >> your design accordingly?
> >
> > The QEMU maintainer may react when he sees a problem.
>
> Why are you unwilling to admit the problem? QEMU will never support
> U-Boot specific stuff.
>
> Please, develop concepts that solve U-Boot's needs within U-Boot.
So you are saying that because QEMU wrote it's devicetree support with
Linux in mind, we should, what...? Spent 500ms merging devicetrees
before relocation? Move back to platdata? Delete driver model? Rewrite
U-Boot?
U-Boot works quite nicely as it is. The problem is that people are
still coming to terms with U-Boot's right to use the devicetree. This
could take a few more years, I think, or it may never happen. Most
people don't even know how U-Boot works. We just need to be patient.
Regards,
Simon
>
> Best regards
>
> Heinrich
>
> >
> > I have already clearly stated that there is no way we are have two
> > control DTBs. The overlay is also unworkable and unnecessary. That is
> > why I put so much effort into this patch, after all.
> >
> > So for now, people will just have to deal with what QEMU provides. I
> > sent a patch to resolve the problem which can be accepted at any point
> > if people complain enough. So far only François has offered support
> > for it.
> >
> > Regards,
> > Simon
> >
>
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
2021-12-04 1:02 ` Simon Glass
@ 2021-12-04 11:06 ` François Ozog
2021-12-04 17:42 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: François Ozog @ 2021-12-04 11:06 UTC (permalink / raw)
To: Simon Glass
Cc: Heinrich Schuchardt, Ilias Apalodimas, Marcel Ziswiler,
Mark Kettenis, Sean Anderson, Tom Rini, U-Boot Mailing List
Hi Simon
Le sam. 4 déc. 2021 à 02:02, Simon Glass <sjg@chromium.org> a écrit :
> Hi Heinrich,
>
> On Fri, 3 Dec 2021 at 13:28, Heinrich Schuchardt <xypron.glpk@gmx.de>
> wrote:
> >
> > On 12/3/21 9:13 PM, Simon Glass wrote:
> > > Hi Heinrich,
> > >
> > > On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt <xypron.glpk@gmx.de>
> wrote:
> > >>
> > >> On 12/3/21 13:34, Heinrich Schuchardt wrote:
> > >>> On 12/2/21 16:58, Simon Glass 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 v6:
> > >>>> - Fix description of OF_BOARD so it refers just to the current state
> > >>>> - Explain that the 'two devicetrees' refers to two *control*
> devicetrees
> > >>>>
> > >>>> 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 | 555
> +++++++++++++++++++++++++++
> > >>>> doc/develop/devicetree/index.rst | 1 +
> > >>>> 2 files changed, 556 insertions(+)
> > >>>> create mode 100644 doc/develop/devicetree/dt_update.rst
> > >>>>
> > > [..]
> > >
> > >>>> +
> > >>>> +- 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
> > >>>
> > >>> Even if you remove these lines in 17/25 I would prefer not to
> introduce
> > >>> typos here:
> > >>>
> > >>> %s/linst/list/
> > >>>
> > >
> > > OK I can fix that.
> > >
> > > [..]
> > >
> > >>>> +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.
> > >>>
> > >>> Did you ever ask the QEMU community what they think about your ideas?
> > >>> What was the reply?
> > >>
> > >> Looking at the thread
> > >> https://lore.kernel.org/all/20210926183410.256484-1-sjg@chromium.org/
> > >> the QEMU project said NAK. This matches the expectation that I
> expressed
> > >> repeatedly.
> > >>
> > >> Why don't you mention the QEMU reply in this patch series and adjust
> > >> your design accordingly?
> > >
> > > The QEMU maintainer may react when he sees a problem.
> >
> > Why are you unwilling to admit the problem? QEMU will never support
> > U-Boot specific stuff.
> >
> > Please, develop concepts that solve U-Boot's needs within U-Boot.
>
> So you are saying that because QEMU wrote it's devicetree support with
> Linux in mind, we should, what...? Spent 500ms merging devicetrees
> before relocation? Move back to platdata? Delete driver model? Rewrite
> U-Boot?
>
heinrich did not said that. He said that QEMU team said it doesn’t want to
deal with specifics of *any* payload, be it a Linux kernel, a hypervisor,
TFA, U-Boot, Coreboot or *Boot.
In that spirit, TFA made sure they can have the DT they need in the FIP.
I add now: U-Boot when loaded by SPL in QEMU can follow the same pattern
and have a FIT contain U-Boot and the control DTs it needs and deal with
it. Binman should be used to assemble that image. Something along those
lines…
>
> U-Boot works quite nicely as it is. The problem is that people are
> still coming to terms with U-Boot's right to use the devicetree. This
> could take a few more years, I think, or it may never happen. Most
> people don't even know how U-Boot works. We just need to be patient.
>
> Regards,
> Simon
>
>
> >
> > Best regards
> >
> > Heinrich
> >
> > >
> > > I have already clearly stated that there is no way we are have two
> > > control DTBs. The overlay is also unworkable and unnecessary. That is
> > > why I put so much effort into this patch, after all.
> > >
> > > So for now, people will just have to deal with what QEMU provides. I
> > > sent a patch to resolve the problem which can be accepted at any point
> > > if people complain enough. So far only François has offered support
> > > for it.
> > >
> > > Regards,
> > > Simon
> > >
> >
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
2021-12-04 11:06 ` François Ozog
@ 2021-12-04 17:42 ` Simon Glass
2021-12-05 1:14 ` François Ozog
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-04 17:42 UTC (permalink / raw)
To: François Ozog
Cc: Heinrich Schuchardt, Ilias Apalodimas, Marcel Ziswiler,
Mark Kettenis, Sean Anderson, Tom Rini, U-Boot Mailing List
Hi François,
On Sat, 4 Dec 2021 at 04:06, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon
>
> Le sam. 4 déc. 2021 à 02:02, Simon Glass <sjg@chromium.org> a écrit :
>>
>> Hi Heinrich,
>>
>> On Fri, 3 Dec 2021 at 13:28, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>> >
>> > On 12/3/21 9:13 PM, Simon Glass wrote:
>> > > Hi Heinrich,
>> > >
>> > > On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>> > >>
>> > >> On 12/3/21 13:34, Heinrich Schuchardt wrote:
>> > >>> On 12/2/21 16:58, Simon Glass 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 v6:
>> > >>>> - Fix description of OF_BOARD so it refers just to the current state
>> > >>>> - Explain that the 'two devicetrees' refers to two *control* devicetrees
>> > >>>>
>> > >>>> 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 | 555 +++++++++++++++++++++++++++
>> > >>>> doc/develop/devicetree/index.rst | 1 +
>> > >>>> 2 files changed, 556 insertions(+)
>> > >>>> create mode 100644 doc/develop/devicetree/dt_update.rst
>> > >>>>
>> > > [..]
>> > >
>> > >>>> +
>> > >>>> +- 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
>> > >>>
>> > >>> Even if you remove these lines in 17/25 I would prefer not to introduce
>> > >>> typos here:
>> > >>>
>> > >>> %s/linst/list/
>> > >>>
>> > >
>> > > OK I can fix that.
>> > >
>> > > [..]
>> > >
>> > >>>> +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.
>> > >>>
>> > >>> Did you ever ask the QEMU community what they think about your ideas?
>> > >>> What was the reply?
>> > >>
>> > >> Looking at the thread
>> > >> https://lore.kernel.org/all/20210926183410.256484-1-sjg@chromium.org/
>> > >> the QEMU project said NAK. This matches the expectation that I expressed
>> > >> repeatedly.
>> > >>
>> > >> Why don't you mention the QEMU reply in this patch series and adjust
>> > >> your design accordingly?
>> > >
>> > > The QEMU maintainer may react when he sees a problem.
>> >
>> > Why are you unwilling to admit the problem? QEMU will never support
>> > U-Boot specific stuff.
>> >
>> > Please, develop concepts that solve U-Boot's needs within U-Boot.
>>
>> So you are saying that because QEMU wrote it's devicetree support with
>> Linux in mind, we should, what...? Spent 500ms merging devicetrees
>> before relocation? Move back to platdata? Delete driver model? Rewrite
>> U-Boot?
>
> heinrich did not said that. He said that QEMU team said it doesn’t want to deal with specifics of *any* payload, be it a Linux kernel, a hypervisor, TFA, U-Boot, Coreboot or *Boot.
Except that QEMU does deal with the Linux specifics. See the
qemu-arm.dts file in this series, which is directly taken from QEMU.
It has linux, properties and a chosen node. I wasn't even suggesting
that it deal with U-Boot specifics, just provide a way to adjust the
DT that it creates out of whole cloth.
> In that spirit, TFA made sure they can have the DT they need in the FIP.
> I add now: U-Boot when loaded by SPL in QEMU can follow the same pattern and have a FIT contain U-Boot and the control DTs it needs and deal with it. Binman should be used to assemble that image. Something along those lines…
Yes, except U-Boot cannot even boot from SPL without some DT
properties. See my patch
https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-sjg@chromium.org/
I have been working on this for years. Trust me...
Regards,
Simon
>>
>>
>> U-Boot works quite nicely as it is. The problem is that people are
>> still coming to terms with U-Boot's right to use the devicetree. This
>> could take a few more years, I think, or it may never happen. Most
>> people don't even know how U-Boot works. We just need to be patient.
>>
>> Regards,
>> Simon
>>
>>
>> >
>> > Best regards
>> >
>> > Heinrich
>> >
>> > >
>> > > I have already clearly stated that there is no way we are have two
>> > > control DTBs. The overlay is also unworkable and unnecessary. That is
>> > > why I put so much effort into this patch, after all.
>>
>>
>> > >
>> > > So for now, people will just have to deal with what QEMU provides. I
>> > > sent a patch to resolve the problem which can be accepted at any point
>> > > if people complain enough. So far only François has offered support
>> > > for it.
>> > >
>> > > Regards,
>> > > Simon
>> > >
>> >
>
> --
> François-Frédéric Ozog | Director Business Development
> T: +33.67221.6485
> francois.ozog@linaro.org | Skype: ffozog
>
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
2021-12-04 17:42 ` Simon Glass
@ 2021-12-05 1:14 ` François Ozog
2021-12-06 15:23 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: François Ozog @ 2021-12-05 1:14 UTC (permalink / raw)
To: Simon Glass
Cc: Heinrich Schuchardt, Ilias Apalodimas, Marcel Ziswiler,
Mark Kettenis, Sean Anderson, Tom Rini, U-Boot Mailing List
Hi Simon
Le sam. 4 déc. 2021 à 18:42, Simon Glass <sjg@chromium.org> a écrit :
> Hi François,
>
> On Sat, 4 Dec 2021 at 04:06, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> > Hi Simon
> >
> > Le sam. 4 déc. 2021 à 02:02, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> Hi Heinrich,
> >>
> >> On Fri, 3 Dec 2021 at 13:28, Heinrich Schuchardt <xypron.glpk@gmx.de>
> wrote:
> >> >
> >> > On 12/3/21 9:13 PM, Simon Glass wrote:
> >> > > Hi Heinrich,
> >> > >
> >> > > On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt <
> xypron.glpk@gmx.de> wrote:
> >> > >>
> >> > >> On 12/3/21 13:34, Heinrich Schuchardt wrote:
> >> > >>> On 12/2/21 16:58, Simon Glass 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 v6:
> >> > >>>> - Fix description of OF_BOARD so it refers just to the current
> state
> >> > >>>> - Explain that the 'two devicetrees' refers to two *control*
> devicetrees
> >> > >>>>
> >> > >>>> 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 | 555
> +++++++++++++++++++++++++++
> >> > >>>> doc/develop/devicetree/index.rst | 1 +
> >> > >>>> 2 files changed, 556 insertions(+)
> >> > >>>> create mode 100644 doc/develop/devicetree/dt_update.rst
> >> > >>>>
> >> > > [..]
> >> > >
> >> > >>>> +
> >> > >>>> +- 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
> >> > >>>
> >> > >>> Even if you remove these lines in 17/25 I would prefer not to
> introduce
> >> > >>> typos here:
> >> > >>>
> >> > >>> %s/linst/list/
> >> > >>>
> >> > >
> >> > > OK I can fix that.
> >> > >
> >> > > [..]
> >> > >
> >> > >>>> +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.
> >> > >>>
> >> > >>> Did you ever ask the QEMU community what they think about your
> ideas?
> >> > >>> What was the reply?
> >> > >>
> >> > >> Looking at the thread
> >> > >>
> https://lore.kernel.org/all/20210926183410.256484-1-sjg@chromium.org/
> >> > >> the QEMU project said NAK. This matches the expectation that I
> expressed
> >> > >> repeatedly.
> >> > >>
> >> > >> Why don't you mention the QEMU reply in this patch series and
> adjust
> >> > >> your design accordingly?
> >> > >
> >> > > The QEMU maintainer may react when he sees a problem.
> >> >
> >> > Why are you unwilling to admit the problem? QEMU will never support
> >> > U-Boot specific stuff.
> >> >
> >> > Please, develop concepts that solve U-Boot's needs within U-Boot.
> >>
> >> So you are saying that because QEMU wrote it's devicetree support with
> >> Linux in mind, we should, what...? Spent 500ms merging devicetrees
> >> before relocation? Move back to platdata? Delete driver model? Rewrite
> >> U-Boot?
> >
> > heinrich did not said that. He said that QEMU team said it doesn’t want
> to deal with specifics of *any* payload, be it a Linux kernel, a
> hypervisor, TFA, U-Boot, Coreboot or *Boot.
>
> Except that QEMU does deal with the Linux specifics. See the
> qemu-arm.dts file in this series, which is directly taken from QEMU.
> It has linux, properties and a chosen node. I wasn't even suggesting
> that it deal with U-Boot specifics, just provide a way to adjust the
> DT that it creates out of whole cloth.
>
> > In that spirit, TFA made sure they can have the DT they need in the FIP.
> > I add now: U-Boot when loaded by SPL in QEMU can follow the same pattern
> and have a FIT contain U-Boot and the control DTs it needs and deal with
> it. Binman should be used to assemble that image. Something along those
> lines…
>
> Yes, except U-Boot cannot even boot from SPL without some DT
> properties. See my patch
>
>
> https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-sjg@chromium.org/
what is the purpose of
+ pl011@9000000 {+ u-boot,dm-spl;+ };
is it to do the same as stdout-path ?
Why do you need to place SPL in the ROM space ?
> I have been working on this for years. Trust me...
>
> Regards,
> Simon
>
> >>
> >>
> >> U-Boot works quite nicely as it is. The problem is that people are
> >> still coming to terms with U-Boot's right to use the devicetree. This
> >> could take a few more years, I think, or it may never happen. Most
> >> people don't even know how U-Boot works. We just need to be patient.
> >>
> >> Regards,
> >> Simon
> >>
> >>
> >> >
> >> > Best regards
> >> >
> >> > Heinrich
> >> >
> >> > >
> >> > > I have already clearly stated that there is no way we are have two
> >> > > control DTBs. The overlay is also unworkable and unnecessary. That
> is
> >> > > why I put so much effort into this patch, after all.
> >>
> >>
> >> > >
> >> > > So for now, people will just have to deal with what QEMU provides. I
> >> > > sent a patch to resolve the problem which can be accepted at any
> point
> >> > > if people complain enough. So far only François has offered support
> >> > > for it.
> >> > >
> >> > > Regards,
> >> > > Simon
> >> > >
> >> >
> >
> > --
> > François-Frédéric Ozog | Director Business Development
> > T: +33.67221.6485
> > francois.ozog@linaro.org | Skype: ffozog
> >
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
2021-12-05 1:14 ` François Ozog
@ 2021-12-06 15:23 ` Simon Glass
2021-12-07 22:02 ` François Ozog
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-06 15:23 UTC (permalink / raw)
To: François Ozog
Cc: Heinrich Schuchardt, Ilias Apalodimas, Marcel Ziswiler,
Mark Kettenis, Sean Anderson, Tom Rini, U-Boot Mailing List
Hi François,
On Sat, 4 Dec 2021 at 18:15, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon
>
> Le sam. 4 déc. 2021 à 18:42, Simon Glass <sjg@chromium.org> a écrit :
>>
>> Hi François,
>>
>> On Sat, 4 Dec 2021 at 04:06, François Ozog <francois.ozog@linaro.org> wrote:
>> >
>> > Hi Simon
>> >
>> > Le sam. 4 déc. 2021 à 02:02, Simon Glass <sjg@chromium.org> a écrit :
>> >>
>> >> Hi Heinrich,
>> >>
>> >> On Fri, 3 Dec 2021 at 13:28, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>> >> >
>> >> > On 12/3/21 9:13 PM, Simon Glass wrote:
>> >> > > Hi Heinrich,
>> >> > >
>> >> > > On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>> >> > >>
>> >> > >> On 12/3/21 13:34, Heinrich Schuchardt wrote:
>> >> > >>> On 12/2/21 16:58, Simon Glass 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 v6:
>> >> > >>>> - Fix description of OF_BOARD so it refers just to the current state
>> >> > >>>> - Explain that the 'two devicetrees' refers to two *control* devicetrees
>> >> > >>>>
>> >> > >>>> 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 | 555 +++++++++++++++++++++++++++
>> >> > >>>> doc/develop/devicetree/index.rst | 1 +
>> >> > >>>> 2 files changed, 556 insertions(+)
>> >> > >>>> create mode 100644 doc/develop/devicetree/dt_update.rst
>> >> > >>>>
>> >> > > [..]
>> >> > >
>> >> > >>>> +
>> >> > >>>> +- 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
>> >> > >>>
>> >> > >>> Even if you remove these lines in 17/25 I would prefer not to introduce
>> >> > >>> typos here:
>> >> > >>>
>> >> > >>> %s/linst/list/
>> >> > >>>
>> >> > >
>> >> > > OK I can fix that.
>> >> > >
>> >> > > [..]
>> >> > >
>> >> > >>>> +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.
>> >> > >>>
>> >> > >>> Did you ever ask the QEMU community what they think about your ideas?
>> >> > >>> What was the reply?
>> >> > >>
>> >> > >> Looking at the thread
>> >> > >> https://lore.kernel.org/all/20210926183410.256484-1-sjg@chromium.org/
>> >> > >> the QEMU project said NAK. This matches the expectation that I expressed
>> >> > >> repeatedly.
>> >> > >>
>> >> > >> Why don't you mention the QEMU reply in this patch series and adjust
>> >> > >> your design accordingly?
>> >> > >
>> >> > > The QEMU maintainer may react when he sees a problem.
>> >> >
>> >> > Why are you unwilling to admit the problem? QEMU will never support
>> >> > U-Boot specific stuff.
>> >> >
>> >> > Please, develop concepts that solve U-Boot's needs within U-Boot.
>> >>
>> >> So you are saying that because QEMU wrote it's devicetree support with
>> >> Linux in mind, we should, what...? Spent 500ms merging devicetrees
>> >> before relocation? Move back to platdata? Delete driver model? Rewrite
>> >> U-Boot?
>> >
>> > heinrich did not said that. He said that QEMU team said it doesn’t want to deal with specifics of *any* payload, be it a Linux kernel, a hypervisor, TFA, U-Boot, Coreboot or *Boot.
>>
>> Except that QEMU does deal with the Linux specifics. See the
>> qemu-arm.dts file in this series, which is directly taken from QEMU.
>> It has linux, properties and a chosen node. I wasn't even suggesting
>> that it deal with U-Boot specifics, just provide a way to adjust the
>> DT that it creates out of whole cloth.
>>
>> > In that spirit, TFA made sure they can have the DT they need in the FIP.
>> > I add now: U-Boot when loaded by SPL in QEMU can follow the same pattern and have a FIT contain U-Boot and the control DTs it needs and deal with it. Binman should be used to assemble that image. Something along those lines…
>>
>> Yes, except U-Boot cannot even boot from SPL without some DT
>> properties. See my patch
>>
>> https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-sjg@chromium.org/
>
>
> what is the purpose of
>
> + pl011@9000000 {
> + u-boot,dm-spl;
> + };
>
> is it to do the same as stdout-path ?
It's so the console works in SPL - the UART needs to be set up.
https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html#pre-relocation-support
>
> Why do you need to place SPL in the ROM space ?
I believe address 0 is the ROM. We need to put it somewhere where it
can be started by QEMU. When we run U-Boot proper we put it there, so
with SPL we put it there also. I believe this is how things normally
work with QEMU, although I am not an expert on that.
>
[..]
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
2021-12-06 15:23 ` Simon Glass
@ 2021-12-07 22:02 ` François Ozog
0 siblings, 0 replies; 136+ messages in thread
From: François Ozog @ 2021-12-07 22:02 UTC (permalink / raw)
To: Simon Glass
Cc: Heinrich Schuchardt, Ilias Apalodimas, Marcel Ziswiler,
Mark Kettenis, Sean Anderson, Tom Rini, U-Boot Mailing List
Hi Simon
On Mon, 6 Dec 2021 at 16:23, Simon Glass <sjg@chromium.org> wrote:
> Hi François,
>
> On Sat, 4 Dec 2021 at 18:15, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> > Hi Simon
> >
> > Le sam. 4 déc. 2021 à 18:42, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> Hi François,
> >>
> >> On Sat, 4 Dec 2021 at 04:06, François Ozog <francois.ozog@linaro.org>
> wrote:
> >> >
> >> > Hi Simon
> >> >
> >> > Le sam. 4 déc. 2021 à 02:02, Simon Glass <sjg@chromium.org> a écrit :
> >> >>
> >> >> Hi Heinrich,
> >> >>
> >> >> On Fri, 3 Dec 2021 at 13:28, Heinrich Schuchardt <xypron.glpk@gmx.de>
> wrote:
> >> >> >
> >> >> > On 12/3/21 9:13 PM, Simon Glass wrote:
> >> >> > > Hi Heinrich,
> >> >> > >
> >> >> > > On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt <
> xypron.glpk@gmx.de> wrote:
> >> >> > >>
> >> >> > >> On 12/3/21 13:34, Heinrich Schuchardt wrote:
> >> >> > >>> On 12/2/21 16:58, Simon Glass 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 v6:
> >> >> > >>>> - Fix description of OF_BOARD so it refers just to the
> current state
> >> >> > >>>> - Explain that the 'two devicetrees' refers to two *control*
> devicetrees
> >> >> > >>>>
> >> >> > >>>> 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 | 555
> +++++++++++++++++++++++++++
> >> >> > >>>> doc/develop/devicetree/index.rst | 1 +
> >> >> > >>>> 2 files changed, 556 insertions(+)
> >> >> > >>>> create mode 100644 doc/develop/devicetree/dt_update.rst
> >> >> > >>>>
> >> >> > > [..]
> >> >> > >
> >> >> > >>>> +
> >> >> > >>>> +- 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
> >> >> > >>>
> >> >> > >>> Even if you remove these lines in 17/25 I would prefer not to
> introduce
> >> >> > >>> typos here:
> >> >> > >>>
> >> >> > >>> %s/linst/list/
> >> >> > >>>
> >> >> > >
> >> >> > > OK I can fix that.
> >> >> > >
> >> >> > > [..]
> >> >> > >
> >> >> > >>>> +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.
> >> >> > >>>
> >> >> > >>> Did you ever ask the QEMU community what they think about your
> ideas?
> >> >> > >>> What was the reply?
> >> >> > >>
> >> >> > >> Looking at the thread
> >> >> > >>
> https://lore.kernel.org/all/20210926183410.256484-1-sjg@chromium.org/
> >> >> > >> the QEMU project said NAK. This matches the expectation that I
> expressed
> >> >> > >> repeatedly.
> >> >> > >>
> >> >> > >> Why don't you mention the QEMU reply in this patch series and
> adjust
> >> >> > >> your design accordingly?
> >> >> > >
> >> >> > > The QEMU maintainer may react when he sees a problem.
> >> >> >
> >> >> > Why are you unwilling to admit the problem? QEMU will never support
> >> >> > U-Boot specific stuff.
> >> >> >
> >> >> > Please, develop concepts that solve U-Boot's needs within U-Boot.
> >> >>
> >> >> So you are saying that because QEMU wrote it's devicetree support
> with
> >> >> Linux in mind, we should, what...? Spent 500ms merging devicetrees
> >> >> before relocation? Move back to platdata? Delete driver model?
> Rewrite
> >> >> U-Boot?
> >> >
> >> > heinrich did not said that. He said that QEMU team said it doesn’t
> want to deal with specifics of *any* payload, be it a Linux kernel, a
> hypervisor, TFA, U-Boot, Coreboot or *Boot.
> >>
> >> Except that QEMU does deal with the Linux specifics. See the
> >> qemu-arm.dts file in this series, which is directly taken from QEMU.
> >> It has linux, properties and a chosen node. I wasn't even suggesting
> >> that it deal with U-Boot specifics, just provide a way to adjust the
> >> DT that it creates out of whole cloth.
> >>
> >> > In that spirit, TFA made sure they can have the DT they need in the
> FIP.
> >> > I add now: U-Boot when loaded by SPL in QEMU can follow the same
> pattern and have a FIT contain U-Boot and the control DTs it needs and deal
> with it. Binman should be used to assemble that image. Something along
> those lines…
> >>
> >> Yes, except U-Boot cannot even boot from SPL without some DT
> >> properties. See my patch
> >>
> >>
> https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-sjg@chromium.org/
> >
> >
> > what is the purpose of
> >
> > + pl011@9000000 {
> > + u-boot,dm-spl;
> > + };
> >
> > is it to do the same as stdout-path ?
>
> It's so the console works in SPL - the UART needs to be set up.
>
>
> https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html#pre-relocation-support
I don't see why not using "stdout-path". It was once a linux property but
was promoted to component agnostic. I think I have seen some discussions in
TFA to also have different consoles (secure world...) if you have different
UARTs available. May be a discussion to have with them to have an official
binding for consoles, not just a U-Boot one.
>
>
> >
> > Why do you need to place SPL in the ROM space ?
>
> I believe address 0 is the ROM. We need to put it somewhere where it
> can be started by QEMU. When we run U-Boot proper we put it there, so
> with SPL we put it there also. I believe this is how things normally
> work with QEMU, although I am not an expert on that.
>
So SPL relocates itself in RAM ?
The size thing looks like it could be handled differently: have a branch
instruction at address 0, and the following bytes could be filled by binman
to provide the info or something similar (reserve enough bytes to squeeze
in the DT fragment you showed; or other possible ways)
>
> >
> [..]
>
> Regards,
> Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v6 02/25] arm: qemu: Mention -nographic in the docs
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
2021-12-02 15:58 ` [PATCH v6 01/25] doc: Add documentation about devicetree usage Simon Glass
@ 2021-12-02 15:58 ` Simon Glass
2021-12-02 15:58 ` [PATCH v6 03/25] arm: riscv: qemu: Explain how to extract the generated dt Simon Glass
` (24 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:58 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Albert Aribaud
Without this option QEMU appears to hang. Add it to avoid confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
doc/board/emulation/qemu-arm.rst | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
index 584ef0a7e15..8bd7b60cdb4 100644
--- a/doc/board/emulation/qemu-arm.rst
+++ b/doc/board/emulation/qemu-arm.rst
@@ -41,14 +41,15 @@ The minimal QEMU command line to get U-Boot up and running is:
- For ARM::
- qemu-system-arm -machine virt -bios u-boot.bin
+ qemu-system-arm -machine virt -nographic -bios u-boot.bin
- For AArch64::
- qemu-system-aarch64 -machine virt -cpu cortex-a57 -bios u-boot.bin
+ qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 -bios u-boot.bin
Note that for some odd reason qemu-system-aarch64 needs to be explicitly
-told to use a 64-bit CPU or it will boot in 32-bit mode.
+told to use a 64-bit CPU or it will boot in 32-bit mode. The -nographic argument
+ensures that output appears on the terminal. Use Ctrl-A X to quit.
Additional persistent U-boot environment support can be added as follows:
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 03/25] arm: riscv: qemu: Explain how to extract the generated dt
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
2021-12-02 15:58 ` [PATCH v6 01/25] doc: Add documentation about devicetree usage Simon Glass
2021-12-02 15:58 ` [PATCH v6 02/25] arm: qemu: Mention -nographic in the docs Simon Glass
@ 2021-12-02 15:58 ` Simon Glass
2021-12-02 16:30 ` Heinrich Schuchardt
2021-12-02 15:58 ` [PATCH v6 04/25] arm: qemu: Add a devicetree file for qemu_arm Simon Glass
` (23 subsequent siblings)
26 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:58 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Albert Aribaud
QEMU currently generates a devicetree for use with U-Boot. Explain how to
obtain it.
Also explain how to merge it to produce a devicetree with the U-Boot
features included.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v5)
Changes in v5:
- Merge RISC-V and ARM patches since they are similar
doc/board/emulation/qemu-arm.rst | 3 ++
doc/board/emulation/qemu-riscv.rst | 3 ++
doc/develop/devicetree/dt_qemu.rst | 48 ++++++++++++++++++++++++++++++
doc/develop/devicetree/index.rst | 1 +
4 files changed, 55 insertions(+)
create mode 100644 doc/develop/devicetree/dt_qemu.rst
diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
index 8bd7b60cdb4..ff64ec08c3e 100644
--- a/doc/board/emulation/qemu-arm.rst
+++ b/doc/board/emulation/qemu-arm.rst
@@ -21,6 +21,9 @@ The 'virt' platform provides the following as the basic functionality:
Additionally, a number of optional peripherals can be added to the PCI bus.
+See :doc:`../../develop/devicetree/dt_qemu` for information on how to see
+the devicetree actually generated by QEMU.
+
Building U-Boot
---------------
Set the CROSS_COMPILE environment variable as usual, and run:
diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst
index 4b8e104a215..3409fff8117 100644
--- a/doc/board/emulation/qemu-riscv.rst
+++ b/doc/board/emulation/qemu-riscv.rst
@@ -13,6 +13,9 @@ The QEMU virt machine models a generic RISC-V virtual machine with support for
the VirtIO standard networking and block storage devices. It has CLINT, PLIC,
16550A UART devices in addition to VirtIO and it also uses device-tree to pass
configuration information to guest software. It implements RISC-V privileged
+
+See :doc:`../../develop/devicetree/dt_qemu` for information on how to see
+the devicetree actually generated by QEMU.
architecture spec v1.10.
Building U-Boot
diff --git a/doc/develop/devicetree/dt_qemu.rst b/doc/develop/devicetree/dt_qemu.rst
new file mode 100644
index 00000000000..1392a2cae97
--- /dev/null
+++ b/doc/develop/devicetree/dt_qemu.rst
@@ -0,0 +1,48 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Devicetree in QEMU
+==================
+
+For QEMU on ARM, RISC-V and one PPC target, the devicetree is created on the
+fly by QEMU. It is intended for use in Linux but can be used by U-Boot also,
+so long as any nodes/properties needed by U-Boot are merged in.
+
+When `CONFIG_OF_BOARD` is enabled
+
+
+Obtaining the QEMU devicetree
+-----------------------------
+
+Where QEMU generates its own devicetree to pass to U-Boot tou can use
+`-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version.
+
+To obtain the devicetree that qemu generates, add `-machine dumpdtb=qemu.dtb`,
+e.g.::
+
+ qemu-system-arm -machine virt -machine dumpdtb=qemu.dtb
+
+ qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb
+
+ qemu-system-riscv64 -machine virt -machine dumpdtb=qemu.dtb
+
+
+Merging in U-Boot nodes/properties
+----------------------------------
+
+Various U-Boot features require nodes and properties in the U-Boot devicetree
+and at present QEMU is unaware of these. To use these you must manually merge
+in the appropriate pieces.
+
+One way to do this is with dtc. This command runs dtc on each .dtb file in turn,
+to produce a text file. It drops the duplicate header on the qemu one. Then it
+joins them up and runs them through dtc to compile the output::
+
+ qemu-system-arm -machine virt -machine dumpdtb=qemu.dtb
+ cat <(dtc -I dtb qemu.dtb) <(dtc -I dtb u-boot.dtb |grep -v /dts-v1/) |dtc - -o merged.dtb
+
+You can then run qemu with the merged devicetree, e.g.::
+
+ qemu-system-arm -machine virt -nographic -bios u-boot.bin -dtb merged.dtb
+
+Note that there seems to be a bug in some versions of qemu where the output of
+dumpdtb does not quite match what is provided to U-Boot.
diff --git a/doc/develop/devicetree/index.rst b/doc/develop/devicetree/index.rst
index b5b33dfea0f..fc2fb41b1bb 100644
--- a/doc/develop/devicetree/index.rst
+++ b/doc/develop/devicetree/index.rst
@@ -12,3 +12,4 @@ build-time and runtime configuration.
intro
control
dt_update
+ dt_qemu
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* Re: [PATCH v6 03/25] arm: riscv: qemu: Explain how to extract the generated dt
2021-12-02 15:58 ` [PATCH v6 03/25] arm: riscv: qemu: Explain how to extract the generated dt Simon Glass
@ 2021-12-02 16:30 ` Heinrich Schuchardt
2021-12-02 16:51 ` Simon Glass
2021-12-02 17:03 ` Tom Rini
0 siblings, 2 replies; 136+ messages in thread
From: Heinrich Schuchardt @ 2021-12-02 16:30 UTC (permalink / raw)
To: Simon Glass
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Albert Aribaud, U-Boot Mailing List
On 12/2/21 16:58, Simon Glass wrote:
> QEMU currently generates a devicetree for use with U-Boot. Explain how to
> obtain it.
>
> Also explain how to merge it to produce a devicetree with the U-Boot
> features included.
Information like the number of CPUs and the memory must be accurate in
the devicetree and match the call parameter of QEMU.
This worked without this series and must work afterwards. How do you
achieve this?
Best regards
Heinrich
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> (no changes since v5)
>
> Changes in v5:
> - Merge RISC-V and ARM patches since they are similar
>
> doc/board/emulation/qemu-arm.rst | 3 ++
> doc/board/emulation/qemu-riscv.rst | 3 ++
> doc/develop/devicetree/dt_qemu.rst | 48 ++++++++++++++++++++++++++++++
> doc/develop/devicetree/index.rst | 1 +
> 4 files changed, 55 insertions(+)
> create mode 100644 doc/develop/devicetree/dt_qemu.rst
>
> diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
> index 8bd7b60cdb4..ff64ec08c3e 100644
> --- a/doc/board/emulation/qemu-arm.rst
> +++ b/doc/board/emulation/qemu-arm.rst
> @@ -21,6 +21,9 @@ The 'virt' platform provides the following as the basic functionality:
>
> Additionally, a number of optional peripherals can be added to the PCI bus.
>
> +See :doc:`../../develop/devicetree/dt_qemu` for information on how to see
> +the devicetree actually generated by QEMU.
> +
> Building U-Boot
> ---------------
> Set the CROSS_COMPILE environment variable as usual, and run:
> diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst
> index 4b8e104a215..3409fff8117 100644
> --- a/doc/board/emulation/qemu-riscv.rst
> +++ b/doc/board/emulation/qemu-riscv.rst
> @@ -13,6 +13,9 @@ The QEMU virt machine models a generic RISC-V virtual machine with support for
> the VirtIO standard networking and block storage devices. It has CLINT, PLIC,
> 16550A UART devices in addition to VirtIO and it also uses device-tree to pass
> configuration information to guest software. It implements RISC-V privileged
> +
> +See :doc:`../../develop/devicetree/dt_qemu` for information on how to see
> +the devicetree actually generated by QEMU.
> architecture spec v1.10.
>
> Building U-Boot
> diff --git a/doc/develop/devicetree/dt_qemu.rst b/doc/develop/devicetree/dt_qemu.rst
> new file mode 100644
> index 00000000000..1392a2cae97
> --- /dev/null
> +++ b/doc/develop/devicetree/dt_qemu.rst
> @@ -0,0 +1,48 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Devicetree in QEMU
> +==================
> +
> +For QEMU on ARM, RISC-V and one PPC target, the devicetree is created on the
> +fly by QEMU. It is intended for use in Linux but can be used by U-Boot also,
> +so long as any nodes/properties needed by U-Boot are merged in.
> +
> +When `CONFIG_OF_BOARD` is enabled
> +
> +
> +Obtaining the QEMU devicetree
> +-----------------------------
> +
> +Where QEMU generates its own devicetree to pass to U-Boot tou can use
> +`-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version.
> +
> +To obtain the devicetree that qemu generates, add `-machine dumpdtb=qemu.dtb`,
> +e.g.::
> +
> + qemu-system-arm -machine virt -machine dumpdtb=qemu.dtb
> +
> + qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb
> +
> + qemu-system-riscv64 -machine virt -machine dumpdtb=qemu.dtb
> +
> +
> +Merging in U-Boot nodes/properties
> +----------------------------------
> +
> +Various U-Boot features require nodes and properties in the U-Boot devicetree
> +and at present QEMU is unaware of these. To use these you must manually merge
> +in the appropriate pieces.
> +
> +One way to do this is with dtc. This command runs dtc on each .dtb file in turn,
> +to produce a text file. It drops the duplicate header on the qemu one. Then it
> +joins them up and runs them through dtc to compile the output::
> +
> + qemu-system-arm -machine virt -machine dumpdtb=qemu.dtb
> + cat <(dtc -I dtb qemu.dtb) <(dtc -I dtb u-boot.dtb |grep -v /dts-v1/) |dtc - -o merged.dtb
> +
> +You can then run qemu with the merged devicetree, e.g.::
> +
> + qemu-system-arm -machine virt -nographic -bios u-boot.bin -dtb merged.dtb
> +
> +Note that there seems to be a bug in some versions of qemu where the output of
> +dumpdtb does not quite match what is provided to U-Boot.
> diff --git a/doc/develop/devicetree/index.rst b/doc/develop/devicetree/index.rst
> index b5b33dfea0f..fc2fb41b1bb 100644
> --- a/doc/develop/devicetree/index.rst
> +++ b/doc/develop/devicetree/index.rst
> @@ -12,3 +12,4 @@ build-time and runtime configuration.
> intro
> control
> dt_update
> + dt_qemu
>
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 03/25] arm: riscv: qemu: Explain how to extract the generated dt
2021-12-02 16:30 ` Heinrich Schuchardt
@ 2021-12-02 16:51 ` Simon Glass
2021-12-02 17:03 ` Tom Rini
1 sibling, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 16:51 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Albert Aribaud, U-Boot Mailing List
Hi Heinrich,
On Thu, 2 Dec 2021 at 09:35, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 12/2/21 16:58, Simon Glass wrote:
> > QEMU currently generates a devicetree for use with U-Boot. Explain how to
> > obtain it.
> >
> > Also explain how to merge it to produce a devicetree with the U-Boot
> > features included.
>
> Information like the number of CPUs and the memory must be accurate in
> the devicetree and match the call parameter of QEMU.
>
> This worked without this series and must work afterwards. How do you
> achieve this?
Because it does not change how things work. Please test it for
yourself and let me know if you have any problems.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 03/25] arm: riscv: qemu: Explain how to extract the generated dt
2021-12-02 16:30 ` Heinrich Schuchardt
2021-12-02 16:51 ` Simon Glass
@ 2021-12-02 17:03 ` Tom Rini
1 sibling, 0 replies; 136+ messages in thread
From: Tom Rini @ 2021-12-02 17:03 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Simon Glass, Mark Kettenis, Sean Anderson, Ilias Apalodimas,
François Ozog, Albert Aribaud, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
On Thu, Dec 02, 2021 at 05:30:20PM +0100, Heinrich Schuchardt wrote:
> On 12/2/21 16:58, Simon Glass wrote:
> > QEMU currently generates a devicetree for use with U-Boot. Explain how to
> > obtain it.
> >
> > Also explain how to merge it to produce a devicetree with the U-Boot
> > features included.
>
> Information like the number of CPUs and the memory must be accurate in
> the devicetree and match the call parameter of QEMU.
>
> This worked without this series and must work afterwards. How do you
> achieve this?
I don't see the problem with _this_ patch. It documents how to have
QEMU dump the would-be-used device tree, and how to then modify and pass
in a new one. Perhaps it needs a sentence stressing that the included
commands are samples and need to match how QEMU is actually invoked?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v6 04/25] arm: qemu: Add a devicetree file for qemu_arm
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (2 preceding siblings ...)
2021-12-02 15:58 ` [PATCH v6 03/25] arm: riscv: qemu: Explain how to extract the generated dt Simon Glass
@ 2021-12-02 15:58 ` Simon Glass
2021-12-02 15:58 ` [PATCH v6 05/25] arm: qemu: Add a devicetree file for qemu_arm64 Simon Glass
` (22 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:58 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Albert Aribaud, Tuomas Tynkkynen
Add this file, generated from QEMU, so there is a reference devicetree
in the U-Boot tree. So long as OF_BOARD is enabled, it is overridden at
runtime by the QEMU version. However, with this change it becomes
possible to run with the U-Boot devicetree, if desired, including any
local modifications, for development and testing/CI purposes.
The exact source of the devicetree is shown at boot (with a later patch)
to avoid any confusion as to what is going on.
This allows a binman node to be added to the devicetree, so that a
firmware image can be built.
This was generated from QEMU emulator version 6.1.50
Note that this dtb is only guaranteed to work if the same QEMU version
is used, with vanilla command arguments, as documented in
doc/board/emulation/qemu-arm.rts
However in practice this devicetree is suitable for basic use at least
from QEMU 2.5 and devicetree is a stable, backwards-compatible API.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v6:
- Expand the commit message based on comments
arch/arm/dts/Makefile | 2 +
arch/arm/dts/qemu-arm.dts | 402 +++++++++++++++++++++++++++++++++++++
configs/qemu_arm_defconfig | 1 +
3 files changed, 405 insertions(+)
create mode 100644 arch/arm/dts/qemu-arm.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7f622fedbda..eaad3b679cc 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1162,6 +1162,8 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) += imx8mm-cl-iot-gate-optee.dtb
dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb
+dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb
+
targets += $(dtb-y)
# Add any required device tree compiler flags here
diff --git a/arch/arm/dts/qemu-arm.dts b/arch/arm/dts/qemu-arm.dts
new file mode 100644
index 00000000000..fed558ced98
--- /dev/null
+++ b/arch/arm/dts/qemu-arm.dts
@@ -0,0 +1,402 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu_arm
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ interrupt-parent = <0x8001>;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ compatible = "linux,dummy-virt";
+
+ psci {
+ migrate = <0x84000005>;
+ cpu_on = <0x84000003>;
+ cpu_off = <0x84000002>;
+ cpu_suspend = <0x84000001>;
+ method = "hvc";
+ compatible = "arm,psci-0.2\0arm,psci";
+ };
+
+ memory@40000000 {
+ reg = <0x00 0x40000000 0x00 0x8000000>;
+ device_type = "memory";
+ };
+
+ platform@c000000 {
+ interrupt-parent = <0x8001>;
+ ranges = <0x00 0x00 0xc000000 0x2000000>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ fw-cfg@9020000 {
+ dma-coherent;
+ reg = <0x00 0x9020000 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ virtio_mmio@a000000 {
+ dma-coherent;
+ interrupts = <0x00 0x10 0x01>;
+ reg = <0x00 0xa000000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000200 {
+ dma-coherent;
+ interrupts = <0x00 0x11 0x01>;
+ reg = <0x00 0xa000200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000400 {
+ dma-coherent;
+ interrupts = <0x00 0x12 0x01>;
+ reg = <0x00 0xa000400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000600 {
+ dma-coherent;
+ interrupts = <0x00 0x13 0x01>;
+ reg = <0x00 0xa000600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000800 {
+ dma-coherent;
+ interrupts = <0x00 0x14 0x01>;
+ reg = <0x00 0xa000800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000a00 {
+ dma-coherent;
+ interrupts = <0x00 0x15 0x01>;
+ reg = <0x00 0xa000a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000c00 {
+ dma-coherent;
+ interrupts = <0x00 0x16 0x01>;
+ reg = <0x00 0xa000c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000e00 {
+ dma-coherent;
+ interrupts = <0x00 0x17 0x01>;
+ reg = <0x00 0xa000e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001000 {
+ dma-coherent;
+ interrupts = <0x00 0x18 0x01>;
+ reg = <0x00 0xa001000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001200 {
+ dma-coherent;
+ interrupts = <0x00 0x19 0x01>;
+ reg = <0x00 0xa001200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001400 {
+ dma-coherent;
+ interrupts = <0x00 0x1a 0x01>;
+ reg = <0x00 0xa001400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001600 {
+ dma-coherent;
+ interrupts = <0x00 0x1b 0x01>;
+ reg = <0x00 0xa001600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001800 {
+ dma-coherent;
+ interrupts = <0x00 0x1c 0x01>;
+ reg = <0x00 0xa001800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001a00 {
+ dma-coherent;
+ interrupts = <0x00 0x1d 0x01>;
+ reg = <0x00 0xa001a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001c00 {
+ dma-coherent;
+ interrupts = <0x00 0x1e 0x01>;
+ reg = <0x00 0xa001c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001e00 {
+ dma-coherent;
+ interrupts = <0x00 0x1f 0x01>;
+ reg = <0x00 0xa001e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002000 {
+ dma-coherent;
+ interrupts = <0x00 0x20 0x01>;
+ reg = <0x00 0xa002000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002200 {
+ dma-coherent;
+ interrupts = <0x00 0x21 0x01>;
+ reg = <0x00 0xa002200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002400 {
+ dma-coherent;
+ interrupts = <0x00 0x22 0x01>;
+ reg = <0x00 0xa002400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002600 {
+ dma-coherent;
+ interrupts = <0x00 0x23 0x01>;
+ reg = <0x00 0xa002600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002800 {
+ dma-coherent;
+ interrupts = <0x00 0x24 0x01>;
+ reg = <0x00 0xa002800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002a00 {
+ dma-coherent;
+ interrupts = <0x00 0x25 0x01>;
+ reg = <0x00 0xa002a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002c00 {
+ dma-coherent;
+ interrupts = <0x00 0x26 0x01>;
+ reg = <0x00 0xa002c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002e00 {
+ dma-coherent;
+ interrupts = <0x00 0x27 0x01>;
+ reg = <0x00 0xa002e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003000 {
+ dma-coherent;
+ interrupts = <0x00 0x28 0x01>;
+ reg = <0x00 0xa003000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003200 {
+ dma-coherent;
+ interrupts = <0x00 0x29 0x01>;
+ reg = <0x00 0xa003200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003400 {
+ dma-coherent;
+ interrupts = <0x00 0x2a 0x01>;
+ reg = <0x00 0xa003400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003600 {
+ dma-coherent;
+ interrupts = <0x00 0x2b 0x01>;
+ reg = <0x00 0xa003600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003800 {
+ dma-coherent;
+ interrupts = <0x00 0x2c 0x01>;
+ reg = <0x00 0xa003800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003a00 {
+ dma-coherent;
+ interrupts = <0x00 0x2d 0x01>;
+ reg = <0x00 0xa003a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003c00 {
+ dma-coherent;
+ interrupts = <0x00 0x2e 0x01>;
+ reg = <0x00 0xa003c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003e00 {
+ dma-coherent;
+ interrupts = <0x00 0x2f 0x01>;
+ reg = <0x00 0xa003e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ gpio-keys {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ compatible = "gpio-keys";
+
+ poweroff {
+ gpios = <0x8003 0x03 0x00>;
+ linux,code = <0x74>;
+ label = "GPIO Key Poweroff";
+ };
+ };
+
+ pl061@9030000 {
+ phandle = <0x8003>;
+ clock-names = "apb_pclk";
+ clocks = <0x8000>;
+ interrupts = <0x00 0x07 0x04>;
+ gpio-controller;
+ #gpio-cells = <0x02>;
+ compatible = "arm,pl061\0arm,primecell";
+ reg = <0x00 0x9030000 0x00 0x1000>;
+ };
+
+ pcie@10000000 {
+ interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x03 0x04 0x00 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x04 0x04 0x00 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x05 0x04 0x00 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x06 0x04
+ 0x800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x04 0x04 0x800 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x05 0x04 0x800 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x06 0x04 0x800 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x03 0x04
+ 0x1000 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x05 0x04 0x1000 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x06 0x04 0x1000 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x03 0x04 0x1000 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x04 0x04
+ 0x1800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x06 0x04 0x1800 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x03 0x04 0x1800 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x04 0x04 0x1800 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x05 0x04>;
+ #interrupt-cells = <0x01>;
+ ranges = <0x1000000 0x00 0x00 0x00
+ 0x3eff0000 0x00 0x10000 0x2000000
+ 0x00 0x10000000 0x00 0x10000000
+ 0x00 0x2eff0000 0x3000000 0x80
+ 0x00 0x80 0x00 0x80
+ 0x00>;
+ reg = <0x00000000 0x3f000000 0x00000000 0x01000000>;
+ msi-parent = <0x8002>;
+ dma-coherent;
+ bus-range = <0x00 0x0f>;
+ linux,pci-domain = <0x00>;
+ #size-cells = <0x02>;
+ #address-cells = <0x03>;
+ device_type = "pci";
+ compatible = "pci-host-ecam-generic";
+ };
+
+ pl031@9010000 {
+ clock-names = "apb_pclk";
+ clocks = <0x8000>;
+ interrupts = <0x00 0x02 0x04>;
+ reg = <0x00 0x9010000 0x00 0x1000>;
+ compatible = "arm,pl031\0arm,primecell";
+ };
+
+ pl011@9000000 {
+ clock-names = "uartclk\0apb_pclk";
+ clocks = <0x8000 0x8000>;
+ interrupts = <0x00 0x01 0x04>;
+ reg = <0x00 0x9000000 0x00 0x1000>;
+ compatible = "arm,pl011\0arm,primecell";
+ };
+
+ pmu {
+ };
+
+ intc@8000000 {
+ phandle = <0x8001>;
+ reg = <0x00 0x8000000 0x00 0x10000 0x00 0x8010000 0x00 0x10000>;
+ compatible = "arm,cortex-a15-gic";
+ ranges;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ interrupt-controller;
+ #interrupt-cells = <0x03>;
+
+ v2m@8020000 {
+ phandle = <0x8002>;
+ reg = <0x00 0x8020000 0x00 0x1000>;
+ msi-controller;
+ compatible = "arm,gic-v2m-frame";
+ };
+ };
+
+ flash@0 {
+ bank-width = <0x04>;
+ reg = <0x00 0x00 0x00 0x4000000 0x00 0x4000000 0x00 0x4000000>;
+ compatible = "cfi-flash";
+ };
+
+ cpus {
+ #size-cells = <0x00>;
+ #address-cells = <0x01>;
+
+ cpu@0 {
+ reg = <0x00>;
+ compatible = "arm,cortex-a15";
+ device_type = "cpu";
+ };
+ };
+
+ timer {
+ interrupts = <0x01 0x0d 0x104 0x01 0x0e 0x104 0x01 0x0b 0x104 0x01 0x0a 0x104>;
+ always-on;
+ compatible = "arm,armv7-timer";
+ };
+
+ apb-pclk {
+ phandle = <0x8000>;
+ clock-output-names = "clk24mhz";
+ clock-frequency = <0x16e3600>;
+ #clock-cells = <0x00>;
+ compatible = "fixed-clock";
+ };
+
+ chosen {
+ stdout-path = "/pl011@9000000";
+ };
+};
diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index d4f6d0b4373..a644a5f3e79 100644
--- a/configs/qemu_arm_defconfig
+++ b/configs/qemu_arm_defconfig
@@ -5,6 +5,7 @@ CONFIG_SYS_MALLOC_LEN=0x1000000
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x40000
CONFIG_ENV_SECT_SIZE=0x40000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-arm"
CONFIG_TARGET_QEMU_ARM_32BIT=y
CONFIG_DEBUG_UART_BASE=0x9000000
CONFIG_DEBUG_UART_CLOCK=0
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 05/25] arm: qemu: Add a devicetree file for qemu_arm64
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (3 preceding siblings ...)
2021-12-02 15:58 ` [PATCH v6 04/25] arm: qemu: Add a devicetree file for qemu_arm Simon Glass
@ 2021-12-02 15:58 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 06/25] riscv: qemu: Add devicetree files for qemu_riscv32/64 Simon Glass
` (21 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:58 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Albert Aribaud, Tuomas Tynkkynen
Add this file, generated from QEMU, so there is a reference devicetree
in the U-Boot tree. So long as OF_BOARD is enabled, it is overridden at
runtime by the QEMU version. However, with this change it becomes
possible to run with the U-Boot devicetree, if desired, including any
local modifications, for development and testing/CI purposes.
The exact source of the devicetree is shown at boot (with a later patch)
to avoid any confusion as to what is going on.
This allows a binman node to be added to the devicetree, so that a
firmware image can be built.
This was generated from QEMU emulator version 6.1.50
Note that this dtb is only guaranteed to work if the same QEMU version
is used, with vanilla command arguments, as documented in
doc/board/emulation/qemu-arm.rts
However in practice this devicetree is suitable for basic use at least
from QEMU 2.5 and devicetree is a stable, backwards-compatible API.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v6:
- Expand the commit message based on comments
arch/arm/dts/Makefile | 2 +-
arch/arm/dts/qemu-arm64.dts | 381 +++++++++++++++++++++++++++++++++++
configs/qemu_arm64_defconfig | 1 +
3 files changed, 383 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/qemu-arm64.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index eaad3b679cc..2d92b2f940d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1162,7 +1162,7 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) += imx8mm-cl-iot-gate-optee.dtb
dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb
-dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb
+dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb qemu-arm64.dtb
targets += $(dtb-y)
diff --git a/arch/arm/dts/qemu-arm64.dts b/arch/arm/dts/qemu-arm64.dts
new file mode 100644
index 00000000000..7590e49cc84
--- /dev/null
+++ b/arch/arm/dts/qemu-arm64.dts
@@ -0,0 +1,381 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu_arm64
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ interrupt-parent = <0x8001>;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ compatible = "linux,dummy-virt";
+
+ psci {
+ migrate = <0xc4000005>;
+ cpu_on = <0xc4000003>;
+ cpu_off = <0x84000002>;
+ cpu_suspend = <0xc4000001>;
+ method = "hvc";
+ compatible = "arm,psci-0.2\0arm,psci";
+ };
+
+ memory@40000000 {
+ reg = <0x00 0x40000000 0x00 0x8000000>;
+ device_type = "memory";
+ };
+
+ platform@c000000 {
+ interrupt-parent = <0x8001>;
+ ranges = <0x00 0x00 0xc000000 0x2000000>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ fw-cfg@9020000 {
+ dma-coherent;
+ reg = <0x00 0x9020000 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ virtio_mmio@a000000 {
+ dma-coherent;
+ interrupts = <0x00 0x10 0x01>;
+ reg = <0x00 0xa000000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000200 {
+ dma-coherent;
+ interrupts = <0x00 0x11 0x01>;
+ reg = <0x00 0xa000200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000400 {
+ dma-coherent;
+ interrupts = <0x00 0x12 0x01>;
+ reg = <0x00 0xa000400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000600 {
+ dma-coherent;
+ interrupts = <0x00 0x13 0x01>;
+ reg = <0x00 0xa000600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000800 {
+ dma-coherent;
+ interrupts = <0x00 0x14 0x01>;
+ reg = <0x00 0xa000800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000a00 {
+ dma-coherent;
+ interrupts = <0x00 0x15 0x01>;
+ reg = <0x00 0xa000a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000c00 {
+ dma-coherent;
+ interrupts = <0x00 0x16 0x01>;
+ reg = <0x00 0xa000c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000e00 {
+ dma-coherent;
+ interrupts = <0x00 0x17 0x01>;
+ reg = <0x00 0xa000e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001000 {
+ dma-coherent;
+ interrupts = <0x00 0x18 0x01>;
+ reg = <0x00 0xa001000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001200 {
+ dma-coherent;
+ interrupts = <0x00 0x19 0x01>;
+ reg = <0x00 0xa001200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001400 {
+ dma-coherent;
+ interrupts = <0x00 0x1a 0x01>;
+ reg = <0x00 0xa001400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001600 {
+ dma-coherent;
+ interrupts = <0x00 0x1b 0x01>;
+ reg = <0x00 0xa001600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001800 {
+ dma-coherent;
+ interrupts = <0x00 0x1c 0x01>;
+ reg = <0x00 0xa001800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001a00 {
+ dma-coherent;
+ interrupts = <0x00 0x1d 0x01>;
+ reg = <0x00 0xa001a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001c00 {
+ dma-coherent;
+ interrupts = <0x00 0x1e 0x01>;
+ reg = <0x00 0xa001c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001e00 {
+ dma-coherent;
+ interrupts = <0x00 0x1f 0x01>;
+ reg = <0x00 0xa001e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002000 {
+ dma-coherent;
+ interrupts = <0x00 0x20 0x01>;
+ reg = <0x00 0xa002000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002200 {
+ dma-coherent;
+ interrupts = <0x00 0x21 0x01>;
+ reg = <0x00 0xa002200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002400 {
+ dma-coherent;
+ interrupts = <0x00 0x22 0x01>;
+ reg = <0x00 0xa002400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002600 {
+ dma-coherent;
+ interrupts = <0x00 0x23 0x01>;
+ reg = <0x00 0xa002600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002800 {
+ dma-coherent;
+ interrupts = <0x00 0x24 0x01>;
+ reg = <0x00 0xa002800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002a00 {
+ dma-coherent;
+ interrupts = <0x00 0x25 0x01>;
+ reg = <0x00 0xa002a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002c00 {
+ dma-coherent;
+ interrupts = <0x00 0x26 0x01>;
+ reg = <0x00 0xa002c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002e00 {
+ dma-coherent;
+ interrupts = <0x00 0x27 0x01>;
+ reg = <0x00 0xa002e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003000 {
+ dma-coherent;
+ interrupts = <0x00 0x28 0x01>;
+ reg = <0x00 0xa003000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003200 {
+ dma-coherent;
+ interrupts = <0x00 0x29 0x01>;
+ reg = <0x00 0xa003200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003400 {
+ dma-coherent;
+ interrupts = <0x00 0x2a 0x01>;
+ reg = <0x00 0xa003400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003600 {
+ dma-coherent;
+ interrupts = <0x00 0x2b 0x01>;
+ reg = <0x00 0xa003600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003800 {
+ dma-coherent;
+ interrupts = <0x00 0x2c 0x01>;
+ reg = <0x00 0xa003800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003a00 {
+ dma-coherent;
+ interrupts = <0x00 0x2d 0x01>;
+ reg = <0x00 0xa003a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003c00 {
+ dma-coherent;
+ interrupts = <0x00 0x2e 0x01>;
+ reg = <0x00 0xa003c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003e00 {
+ dma-coherent;
+ interrupts = <0x00 0x2f 0x01>;
+ reg = <0x00 0xa003e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ pcie@10000000 {
+ interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x03 0x04 0x00 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x04 0x04 0x00 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x05 0x04 0x00 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x06 0x04
+ 0x800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x04 0x04 0x800 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x05 0x04 0x800 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x06 0x04 0x800 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x03 0x04
+ 0x1000 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x05 0x04 0x1000 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x06 0x04 0x1000 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x03 0x04 0x1000 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x04 0x04
+ 0x1800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x06 0x04 0x1800 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x03 0x04 0x1800 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x04 0x04 0x1800 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x05 0x04>;
+ #interrupt-cells = <0x01>;
+ ranges = <0x1000000 0x00 0x00 0x00
+ 0x3eff0000 0x00 0x10000 0x2000000
+ 0x00 0x10000000 0x00 0x10000000
+ 0x00 0x2eff0000 0x3000000 0x80
+ 0x00 0x80 0x00 0x80
+ 0x00>;
+ reg = <0x40 0x10000000 0x00 0x10000000>;
+ msi-parent = <0x8002>;
+ dma-coherent;
+ bus-range = <0x00 0xff>;
+ linux,pci-domain = <0x00>;
+ #size-cells = <0x02>;
+ #address-cells = <0x03>;
+ device_type = "pci";
+ compatible = "pci-host-ecam-generic";
+ };
+
+ pl031@9010000 {
+ clock-names = "apb_pclk";
+ clocks = <0x8000>;
+ interrupts = <0x00 0x02 0x04>;
+ reg = <0x00 0x9010000 0x00 0x1000>;
+ compatible = "arm,pl031\0arm,primecell";
+ };
+
+ pl011@9000000 {
+ clock-names = "uartclk\0apb_pclk";
+ clocks = <0x8000 0x8000>;
+ interrupts = <0x00 0x01 0x04>;
+ reg = <0x00 0x9000000 0x00 0x1000>;
+ compatible = "arm,pl011\0arm,primecell";
+ };
+
+ pmu {
+ interrupts = <0x01 0x07 0x104>;
+ compatible = "arm,armv8-pmuv3";
+ };
+
+ intc@8000000 {
+ phandle = <0x8001>;
+ reg = <0x00 0x8000000 0x00 0x10000 0x00 0x8010000 0x00 0x10000>;
+ compatible = "arm,cortex-a15-gic";
+ ranges;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ interrupt-controller;
+ #interrupt-cells = <0x03>;
+
+ v2m@8020000 {
+ phandle = <0x8002>;
+ reg = <0x00 0x8020000 0x00 0x1000>;
+ msi-controller;
+ compatible = "arm,gic-v2m-frame";
+ };
+ };
+
+ flash@0 {
+ bank-width = <0x04>;
+ reg = <0x00 0x00 0x00 0x4000000 0x00 0x4000000 0x00 0x4000000>;
+ compatible = "cfi-flash";
+ };
+
+ cpus {
+ #size-cells = <0x00>;
+ #address-cells = <0x01>;
+
+ cpu@0 {
+ reg = <0x00>;
+ compatible = "arm,cortex-a57";
+ device_type = "cpu";
+ };
+ };
+
+ timer {
+ interrupts = <0x01 0x0d 0x104 0x01 0x0e 0x104 0x01 0x0b 0x104 0x01 0x0a 0x104>;
+ always-on;
+ compatible = "arm,armv8-timer\0arm,armv7-timer";
+ };
+
+ apb-pclk {
+ phandle = <0x8000>;
+ clock-output-names = "clk24mhz";
+ clock-frequency = <0x16e3600>;
+ #clock-cells = <0x00>;
+ compatible = "fixed-clock";
+ };
+
+ chosen {
+ stdout-path = "/pl011@9000000";
+ };
+};
diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig
index 02a5e940c41..a8652f871ca 100644
--- a/configs/qemu_arm64_defconfig
+++ b/configs/qemu_arm64_defconfig
@@ -8,6 +8,7 @@ CONFIG_ENV_SECT_SIZE=0x40000
CONFIG_DEBUG_UART_BASE=0x9000000
CONFIG_DEBUG_UART_CLOCK=0
CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_DEVICE_TREE="qemu-arm64"
CONFIG_AHCI=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0x40200000
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 06/25] riscv: qemu: Add devicetree files for qemu_riscv32/64
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (4 preceding siblings ...)
2021-12-02 15:58 ` [PATCH v6 05/25] arm: qemu: Add a devicetree file for qemu_arm64 Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4 Simon Glass
` (20 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass, Bin Meng
Add these files, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Split the existing qemu-virt into two, since we need a different
devicetree for 32- and 64-bit machines.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/riscv/dts/Makefile | 2 +-
arch/riscv/dts/qemu-virt.dts | 8 -
arch/riscv/dts/qemu-virt32.dts | 217 +++++++++++++++++++++++++++
arch/riscv/dts/qemu-virt64.dts | 217 +++++++++++++++++++++++++++
configs/qemu-riscv32_defconfig | 1 +
configs/qemu-riscv32_smode_defconfig | 1 +
configs/qemu-riscv32_spl_defconfig | 2 +-
configs/qemu-riscv64_defconfig | 1 +
configs/qemu-riscv64_smode_defconfig | 1 +
configs/qemu-riscv64_spl_defconfig | 2 +-
10 files changed, 441 insertions(+), 11 deletions(-)
delete mode 100644 arch/riscv/dts/qemu-virt.dts
create mode 100644 arch/riscv/dts/qemu-virt32.dts
create mode 100644 arch/riscv/dts/qemu-virt64.dts
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index b6e9166767b..90d3f35e6e3 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -2,7 +2,7 @@
dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb
-dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt.dtb
+dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt32.dtb qemu-virt64.dtb
dtb-$(CONFIG_TARGET_OPENPITON_RISCV64) += openpiton-riscv64.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNLEASHED) += hifive-unleashed-a00.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-unmatched-a00.dtb
diff --git a/arch/riscv/dts/qemu-virt.dts b/arch/riscv/dts/qemu-virt.dts
deleted file mode 100644
index fecff542b91..00000000000
--- a/arch/riscv/dts/qemu-virt.dts
+++ /dev/null
@@ -1,8 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
- */
-
-/dts-v1/;
-
-#include "binman.dtsi"
diff --git a/arch/riscv/dts/qemu-virt32.dts b/arch/riscv/dts/qemu-virt32.dts
new file mode 100644
index 00000000000..3c449413523
--- /dev/null
+++ b/arch/riscv/dts/qemu-virt32.dts
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "binman.dtsi"
+
+/ {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "riscv-virtio";
+ model = "riscv-virtio,qemu";
+
+ fw-cfg@10100000 {
+ dma-coherent;
+ reg = <0x00 0x10100000 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ flash@20000000 {
+ bank-width = <0x04>;
+ reg = <0x00 0x20000000 0x00 0x2000000
+ 0x00 0x22000000 0x00 0x2000000>;
+ compatible = "cfi-flash";
+ };
+
+ chosen {
+ bootargs = [00];
+ stdout-path = "/soc/uart@10000000";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x00 0x80000000 0x00 0x8000000>;
+ };
+
+ cpus {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ timebase-frequency = <0x989680>;
+
+ cpu@0 {
+ phandle = <0x01>;
+ device_type = "cpu";
+ reg = <0x00>;
+ status = "okay";
+ compatible = "riscv";
+ riscv,isa = "rv32imafdcsu";
+ mmu-type = "riscv,sv32";
+
+ interrupt-controller {
+ #interrupt-cells = <0x01>;
+ interrupt-controller;
+ compatible = "riscv,cpu-intc";
+ phandle = <0x02>;
+ };
+ };
+
+ cpu-map {
+
+ cluster0 {
+
+ core0 {
+ cpu = <0x01>;
+ };
+ };
+ };
+ };
+
+ soc {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "simple-bus";
+ ranges;
+
+ rtc@101000 {
+ interrupts = <0x0b>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x101000 0x00 0x1000>;
+ compatible = "google,goldfish-rtc";
+ };
+
+ uart@10000000 {
+ interrupts = <0x0a>;
+ interrupt-parent = <0x03>;
+ clock-frequency = <0x384000>;
+ reg = <0x00 0x10000000 0x00 0x100>;
+ compatible = "ns16550a";
+ };
+
+ poweroff {
+ value = <0x5555>;
+ offset = <0x00>;
+ regmap = <0x04>;
+ compatible = "syscon-poweroff";
+ };
+
+ reboot {
+ value = <0x7777>;
+ offset = <0x00>;
+ regmap = <0x04>;
+ compatible = "syscon-reboot";
+ };
+
+ test@100000 {
+ phandle = <0x04>;
+ reg = <0x00 0x100000 0x00 0x1000>;
+ compatible = "sifive,test1\0sifive,test0\0syscon";
+ };
+
+ pci@30000000 {
+ interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x03 0x20 0x00 0x00
+ 0x00 0x02 0x03 0x21 0x00 0x00 0x00 0x03
+ 0x03 0x22 0x00 0x00 0x00 0x04 0x03 0x23
+ 0x800 0x00 0x00 0x01 0x03 0x21 0x800 0x00
+ 0x00 0x02 0x03 0x22 0x800 0x00 0x00 0x03
+ 0x03 0x23 0x800 0x00 0x00 0x04 0x03 0x20
+ 0x1000 0x00 0x00 0x01 0x03 0x22 0x1000 0x00
+ 0x00 0x02 0x03 0x23 0x1000 0x00 0x00 0x03
+ 0x03 0x20 0x1000 0x00 0x00 0x04 0x03 0x21
+ 0x1800 0x00 0x00 0x01 0x03 0x23 0x1800 0x00
+ 0x00 0x02 0x03 0x20 0x1800 0x00 0x00 0x03
+ 0x03 0x21 0x1800 0x00 0x00 0x04 0x03 0x22>;
+ ranges = <0x1000000 0x00 0x00 0x00
+ 0x3000000 0x00 0x10000 0x2000000
+ 0x00 0x40000000 0x00 0x40000000
+ 0x00 0x40000000 0x3000000 0x03
+ 0x00 0x03 0x00 0x01
+ 0x00>;
+ reg = <0x00 0x30000000 0x00 0x10000000>;
+ dma-coherent;
+ bus-range = <0x00 0xff>;
+ linux,pci-domain = <0x00>;
+ device_type = "pci";
+ compatible = "pci-host-ecam-generic";
+ #size-cells = <0x02>;
+ #interrupt-cells = <0x01>;
+ #address-cells = <0x03>;
+ };
+
+ virtio_mmio@10008000 {
+ interrupts = <0x08>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10008000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10007000 {
+ interrupts = <0x07>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10007000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10006000 {
+ interrupts = <0x06>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10006000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10005000 {
+ interrupts = <0x05>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10005000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10004000 {
+ interrupts = <0x04>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10004000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10003000 {
+ interrupts = <0x03>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10003000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10002000 {
+ interrupts = <0x02>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10002000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10001000 {
+ interrupts = <0x01>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10001000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ plic@c000000 {
+ phandle = <0x03>;
+ riscv,ndev = <0x35>;
+ reg = <0x00 0xc000000 0x00 0x210000>;
+ interrupts-extended = <0x02 0x0b 0x02 0x09>;
+ interrupt-controller;
+ compatible = "sifive,plic-1.0.0\0riscv,plic0";
+ #interrupt-cells = <0x01>;
+ #address-cells = <0x00>;
+ };
+
+ clint@2000000 {
+ interrupts-extended = <0x02 0x03 0x02 0x07>;
+ reg = <0x00 0x2000000 0x00 0x10000>;
+ compatible = "sifive,clint0\0riscv,clint0";
+ };
+ };
+};
diff --git a/arch/riscv/dts/qemu-virt64.dts b/arch/riscv/dts/qemu-virt64.dts
new file mode 100644
index 00000000000..61bc084e280
--- /dev/null
+++ b/arch/riscv/dts/qemu-virt64.dts
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "binman.dtsi"
+
+/ {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "riscv-virtio";
+ model = "riscv-virtio,qemu";
+
+ fw-cfg@10100000 {
+ dma-coherent;
+ reg = <0x00 0x10100000 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ flash@20000000 {
+ bank-width = <0x04>;
+ reg = <0x00 0x20000000 0x00 0x2000000
+ 0x00 0x22000000 0x00 0x2000000>;
+ compatible = "cfi-flash";
+ };
+
+ chosen {
+ bootargs = [00];
+ stdout-path = "/soc/uart@10000000";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x00 0x80000000 0x00 0x8000000>;
+ };
+
+ cpus {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ timebase-frequency = <0x989680>;
+
+ cpu@0 {
+ phandle = <0x01>;
+ device_type = "cpu";
+ reg = <0x00>;
+ status = "okay";
+ compatible = "riscv";
+ riscv,isa = "rv64imafdcsu";
+ mmu-type = "riscv,sv48";
+
+ interrupt-controller {
+ #interrupt-cells = <0x01>;
+ interrupt-controller;
+ compatible = "riscv,cpu-intc";
+ phandle = <0x02>;
+ };
+ };
+
+ cpu-map {
+
+ cluster0 {
+
+ core0 {
+ cpu = <0x01>;
+ };
+ };
+ };
+ };
+
+ soc {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "simple-bus";
+ ranges;
+
+ rtc@101000 {
+ interrupts = <0x0b>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x101000 0x00 0x1000>;
+ compatible = "google,goldfish-rtc";
+ };
+
+ uart@10000000 {
+ interrupts = <0x0a>;
+ interrupt-parent = <0x03>;
+ clock-frequency = <0x384000>;
+ reg = <0x00 0x10000000 0x00 0x100>;
+ compatible = "ns16550a";
+ };
+
+ poweroff {
+ value = <0x5555>;
+ offset = <0x00>;
+ regmap = <0x04>;
+ compatible = "syscon-poweroff";
+ };
+
+ reboot {
+ value = <0x7777>;
+ offset = <0x00>;
+ regmap = <0x04>;
+ compatible = "syscon-reboot";
+ };
+
+ test@100000 {
+ phandle = <0x04>;
+ reg = <0x00 0x100000 0x00 0x1000>;
+ compatible = "sifive,test1\0sifive,test0\0syscon";
+ };
+
+ pci@30000000 {
+ interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x03 0x20 0x00 0x00
+ 0x00 0x02 0x03 0x21 0x00 0x00 0x00 0x03
+ 0x03 0x22 0x00 0x00 0x00 0x04 0x03 0x23
+ 0x800 0x00 0x00 0x01 0x03 0x21 0x800 0x00
+ 0x00 0x02 0x03 0x22 0x800 0x00 0x00 0x03
+ 0x03 0x23 0x800 0x00 0x00 0x04 0x03 0x20
+ 0x1000 0x00 0x00 0x01 0x03 0x22 0x1000 0x00
+ 0x00 0x02 0x03 0x23 0x1000 0x00 0x00 0x03
+ 0x03 0x20 0x1000 0x00 0x00 0x04 0x03 0x21
+ 0x1800 0x00 0x00 0x01 0x03 0x23 0x1800 0x00
+ 0x00 0x02 0x03 0x20 0x1800 0x00 0x00 0x03
+ 0x03 0x21 0x1800 0x00 0x00 0x04 0x03 0x22>;
+ ranges = <0x1000000 0x00 0x00 0x00
+ 0x3000000 0x00 0x10000 0x2000000
+ 0x00 0x40000000 0x00 0x40000000
+ 0x00 0x40000000 0x3000000 0x03
+ 0x00 0x03 0x00 0x01
+ 0x00>;
+ reg = <0x00 0x30000000 0x00 0x10000000>;
+ dma-coherent;
+ bus-range = <0x00 0xff>;
+ linux,pci-domain = <0x00>;
+ device_type = "pci";
+ compatible = "pci-host-ecam-generic";
+ #size-cells = <0x02>;
+ #interrupt-cells = <0x01>;
+ #address-cells = <0x03>;
+ };
+
+ virtio_mmio@10008000 {
+ interrupts = <0x08>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10008000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10007000 {
+ interrupts = <0x07>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10007000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10006000 {
+ interrupts = <0x06>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10006000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10005000 {
+ interrupts = <0x05>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10005000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10004000 {
+ interrupts = <0x04>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10004000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10003000 {
+ interrupts = <0x03>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10003000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10002000 {
+ interrupts = <0x02>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10002000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10001000 {
+ interrupts = <0x01>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10001000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ plic@c000000 {
+ phandle = <0x03>;
+ riscv,ndev = <0x35>;
+ reg = <0x00 0xc000000 0x00 0x210000>;
+ interrupts-extended = <0x02 0x0b 0x02 0x09>;
+ interrupt-controller;
+ compatible = "sifive,plic-1.0.0\0riscv,plic0";
+ #interrupt-cells = <0x01>;
+ #address-cells = <0x00>;
+ };
+
+ clint@2000000 {
+ interrupts-extended = <0x02 0x03 0x02 0x07>;
+ reg = <0x00 0x2000000 0x00 0x10000>;
+ compatible = "sifive,clint0\0riscv,clint0";
+ };
+ };
+};
diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig
index 0b8cd191618..4c0f51bd2aa 100644
--- a/configs/qemu-riscv32_defconfig
+++ b/configs/qemu-riscv32_defconfig
@@ -2,6 +2,7 @@ CONFIG_RISCV=y
CONFIG_SYS_MALLOC_LEN=0x800000
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0x80200000
diff --git a/configs/qemu-riscv32_smode_defconfig b/configs/qemu-riscv32_smode_defconfig
index 4d65104f7b4..19406080100 100644
--- a/configs/qemu-riscv32_smode_defconfig
+++ b/configs/qemu-riscv32_smode_defconfig
@@ -2,6 +2,7 @@ CONFIG_RISCV=y
CONFIG_SYS_MALLOC_LEN=0x800000
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_RISCV_SMODE=y
CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/qemu-riscv32_spl_defconfig b/configs/qemu-riscv32_spl_defconfig
index eb64c51a214..c4422969c61 100644
--- a/configs/qemu-riscv32_spl_defconfig
+++ b/configs/qemu-riscv32_spl_defconfig
@@ -2,7 +2,7 @@ CONFIG_RISCV=y
CONFIG_SYS_MALLOC_LEN=0x800000
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
-CONFIG_DEFAULT_DEVICE_TREE="qemu-virt"
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
CONFIG_SPL=y
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_RISCV_SMODE=y
diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig
index 4faa6dad8d6..cba975d703d 100644
--- a/configs/qemu-riscv64_defconfig
+++ b/configs/qemu-riscv64_defconfig
@@ -2,6 +2,7 @@ CONFIG_RISCV=y
CONFIG_SYS_MALLOC_LEN=0x800000
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64"
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_ARCH_RV64I=y
CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/qemu-riscv64_smode_defconfig b/configs/qemu-riscv64_smode_defconfig
index f575c127b7c..6b7771488fe 100644
--- a/configs/qemu-riscv64_smode_defconfig
+++ b/configs/qemu-riscv64_smode_defconfig
@@ -2,6 +2,7 @@ CONFIG_RISCV=y
CONFIG_SYS_MALLOC_LEN=0x800000
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64"
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_ARCH_RV64I=y
CONFIG_RISCV_SMODE=y
diff --git a/configs/qemu-riscv64_spl_defconfig b/configs/qemu-riscv64_spl_defconfig
index 0fbdb7564c6..e02ca3a1465 100644
--- a/configs/qemu-riscv64_spl_defconfig
+++ b/configs/qemu-riscv64_spl_defconfig
@@ -2,7 +2,7 @@ CONFIG_RISCV=y
CONFIG_SYS_MALLOC_LEN=0x800000
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
-CONFIG_DEFAULT_DEVICE_TREE="qemu-virt"
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64"
CONFIG_SPL=y
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_ARCH_RV64I=y
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (5 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 06/25] riscv: qemu: Add devicetree files for qemu_riscv32/64 Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 17:34 ` Mark Kettenis
2021-12-02 15:59 ` [PATCH v6 08/25] arm: vexpress: Add a devicetree file for juno Simon Glass
` (19 subsequent siblings)
26 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Albert Aribaud, Matthias Brugger, Stephen Warren, Stephen Warren
Add this file, obtained from the Raspbian boot disk, so there is a
reference devicetree in the U-Boot tree. The same one is used for
32- and 64-bit variants.
Note that U-Boot does not normally need this at runtime, since
CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
devicetree at runtime.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++++++++
configs/rpi_4_32b_defconfig | 1 +
configs/rpi_4_defconfig | 1 +
configs/rpi_arm64_defconfig | 1 +
5 files changed, 1963 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 2d92b2f940d..9cddab37207 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1077,7 +1077,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
bcm2837-rpi-3-a-plus.dtb \
bcm2837-rpi-3-b.dtb \
bcm2837-rpi-3-b-plus.dtb \
- bcm2837-rpi-cm3-io3.dtb
+ bcm2837-rpi-cm3-io3.dtb \
+ bcm2711-rpi-4-b.dtb
dtb-$(CONFIG_ARCH_BCM63158) += \
bcm963158.dtb
diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts b/arch/arm/dts/bcm2711-rpi-4-b.dts
new file mode 100644
index 00000000000..425e9fb91c4
--- /dev/null
+++ b/arch/arm/dts/bcm2711-rpi-4-b.dts
@@ -0,0 +1,1958 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for rpi_4
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/memreserve/ 0x0000000000000000 0x0000000000001000;
+/ {
+ compatible = "raspberrypi,4-model-b\0brcm,bcm2838\0brcm,bcm2837";
+ model = "Raspberry Pi 4 Model B";
+ interrupt-parent = <0x01>;
+ #address-cells = <0x02>;
+ #size-cells = <0x01>;
+
+ aliases {
+ serial0 = "/soc/serial@7e215040";
+ serial1 = "/soc/serial@7e201000";
+ audio = "/soc/audio";
+ aux = "/soc/aux@7e215000";
+ sound = "/soc/sound";
+ soc = "/soc";
+ dma = "/soc/dma@7e007000";
+ watchdog = "/soc/watchdog@7e100000";
+ random = "/soc/rng@7e104000";
+ mailbox = "/soc/mailbox@7e00b880";
+ gpio = "/soc/gpio@7e200000";
+ uart0 = "/soc/serial@7e201000";
+ sdhost = "/soc/mmc@7e202000";
+ mmc0 = "/soc/emmc2@7e340000";
+ i2s = "/soc/i2s@7e203000";
+ spi0 = "/soc/spi@7e204000";
+ i2c0 = "/soc/i2c@7e205000";
+ uart1 = "/soc/serial@7e215040";
+ spi1 = "/soc/spi@7e215080";
+ spi2 = "/soc/spi@7e2150c0";
+ mmc = "/soc/mmc@7e300000";
+ mmc1 = "/soc/mmcnr@7e300000";
+ i2c1 = "/soc/i2c@7e804000";
+ i2c2 = "/soc/i2c@7e805000";
+ usb = "/soc/usb@7e980000";
+ leds = "/leds";
+ fb = "/soc/fb";
+ thermal = "/soc/thermal@7d5d2200";
+ axiperf = "/soc/axiperf";
+ mmc2 = "/soc/mmc@7e202000";
+ ethernet0 = "/scb/genet@7d580000";
+ };
+
+ chosen {
+ bootargs = "8250.nr_uarts=1 cma=64M";
+ };
+
+ thermal-zones {
+
+ cpu-thermal {
+ polling-delay-passive = <0x00>;
+ polling-delay = <0x3e8>;
+ thermal-sensors = <0x02>;
+ coefficients = <0xfffffe19 0x641b8>;
+ phandle = <0x2f>;
+
+ cooling-maps {
+ };
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ ranges = <0x7e000000 0x00 0xfe000000 0x1800000
+ 0x7c000000 0x00 0xfc000000 0x2000000
+ 0x40000000 0x00 0xff800000 0x800000>;
+ dma-ranges = <0xc0000000 0x00 0x00 0x3c000000>;
+ phandle = <0x30>;
+
+ txp@7e004000 {
+ compatible = "brcm,bcm2835-txp";
+ reg = <0x7e004000 0x20>;
+ interrupts = <0x00 0x4b 0x04>;
+ status = "disabled";
+ phandle = <0x31>;
+ };
+
+ dma@7e007000 {
+ compatible = "brcm,bcm2835-dma";
+ reg = <0x7e007000 0xb00>;
+ interrupts = <0x00 0x50 0x04 0x00 0x51 0x04 0x00 0x52
+ 0x04 0x00 0x53 0x04 0x00 0x54 0x04 0x00
+ 0x55 0x04 0x00 0x56 0x04 0x00 0x57 0x04
+ 0x00 0x57 0x04 0x00 0x58 0x04 0x00 0x58
+ 0x04>;
+ interrupt-names = "dma0\0dma1\0dma2\0dma3\0dma4\0dma5\0dma6\0dma7\0dma8\0dma9\0dma10";
+ #dma-cells = <0x01>;
+ brcm,dma-channel-mask = <0x7ef5>;
+ phandle = <0x0a>;
+ };
+
+ watchdog@7e100000 {
+ compatible = "brcm,bcm2835-pm\0brcm,bcm2835-pm-wdt";
+ #power-domain-cells = <0x01>;
+ #reset-cells = <0x01>;
+ reg = <0x7e100000 0x114 0x7e00a000 0x24 0x7ec11000 0x20>;
+ clocks = <0x03 0x15 0x03 0x1d 0x03 0x17 0x03 0x16>;
+ clock-names = "v3d\0peri_image\0h264\0isp";
+ system-power-controller;
+ phandle = <0x1c>;
+ };
+
+ cprman@7e101000 {
+ compatible = "brcm,bcm2838-cprman";
+ #clock-cells = <0x01>;
+ reg = <0x7e101000 0x2000>;
+ clocks = <0x04 0x05 0x00 0x05 0x01 0x05 0x02 0x06
+ 0x00 0x06 0x01 0x06 0x02>;
+ firmware = <0x07>;
+ phandle = <0x03>;
+ };
+
+ rng@7e104000 {
+ compatible = "brcm,bcm2838-rng200";
+ reg = <0x7e104000 0x10>;
+ interrupts = <0x00 0x7d 0x04>;
+ phandle = <0x26>;
+ };
+
+ mailbox@7e00b880 {
+ compatible = "brcm,bcm2835-mbox";
+ reg = <0x7e00b880 0x40>;
+ interrupts = <0x00 0x21 0x04>;
+ #mbox-cells = <0x00>;
+ phandle = <0x1a>;
+ };
+
+ gpio: gpio@7e200000 {
+ compatible = "brcm,bcm2835-gpio";
+ reg = <0x7e200000 0xb4>;
+ interrupts = <0x00 0x71 0x04 0x00 0x72 0x04>;
+ gpio-controller;
+ #gpio-cells = <0x02>;
+ interrupt-controller;
+ #interrupt-cells = <0x02>;
+ phandle = <0x0f>;
+
+ dpi_gpio0 {
+ brcm,pins = <0x00 0x01 0x02 0x03 0x04
+ 0x05 0x06 0x07 0x08 0x09
+ 0x0a 0x0b 0x0c 0x0d 0x0e
+ 0x0f 0x10 0x11 0x12 0x13
+ 0x14 0x15 0x16 0x17 0x18
+ 0x19 0x1a 0x1b>;
+ brcm,function = <0x06>;
+ phandle = <0x32>;
+ };
+
+ emmc_gpio22 {
+ brcm,pins = <0x16 0x17 0x18 0x19 0x1a 0x1b>;
+ brcm,function = <0x07>;
+ phandle = <0x33>;
+ };
+
+ emmc_gpio34 {
+ brcm,pins = <0x22 0x23 0x24 0x25 0x26 0x27>;
+ brcm,function = <0x07>;
+ brcm,pull = <0x00 0x02 0x02 0x02 0x02 0x02>;
+ phandle = <0x34>;
+ };
+
+ emmc_gpio48 {
+ brcm,pins = <0x30 0x31 0x32 0x33 0x34 0x35>;
+ brcm,function = <0x07>;
+ phandle = <0x35>;
+ };
+
+ gpclk0_gpio4 {
+ brcm,pins = <0x04>;
+ brcm,function = <0x04>;
+ phandle = <0x36>;
+ };
+
+ gpclk1_gpio5 {
+ brcm,pins = <0x05>;
+ brcm,function = <0x04>;
+ phandle = <0x37>;
+ };
+
+ gpclk1_gpio42 {
+ brcm,pins = <0x2a>;
+ brcm,function = <0x04>;
+ phandle = <0x38>;
+ };
+
+ gpclk1_gpio44 {
+ brcm,pins = <0x2c>;
+ brcm,function = <0x04>;
+ phandle = <0x39>;
+ };
+
+ gpclk2_gpio6 {
+ brcm,pins = <0x06>;
+ brcm,function = <0x04>;
+ phandle = <0x3a>;
+ };
+
+ gpclk2_gpio43 {
+ brcm,pins = <0x2b>;
+ brcm,function = <0x04>;
+ brcm,pull = <0x00>;
+ phandle = <0x3b>;
+ };
+
+ i2c0_gpio0 {
+ brcm,pins = <0x00 0x01>;
+ brcm,function = <0x04>;
+ phandle = <0x3c>;
+ };
+
+ i2c0_gpio28 {
+ brcm,pins = <0x1c 0x1d>;
+ brcm,function = <0x04>;
+ phandle = <0x3d>;
+ };
+
+ i2c0_gpio44 {
+ brcm,pins = <0x2c 0x2d>;
+ brcm,function = <0x05>;
+ phandle = <0x3e>;
+ };
+
+ i2c1_gpio2 {
+ brcm,pins = <0x02 0x03>;
+ brcm,function = <0x04>;
+ phandle = <0x3f>;
+ };
+
+ i2c1_gpio44 {
+ brcm,pins = <0x2c 0x2d>;
+ brcm,function = <0x06>;
+ phandle = <0x40>;
+ };
+
+ jtag_gpio22 {
+ brcm,pins = <0x16 0x17 0x18 0x19 0x1a 0x1b>;
+ brcm,function = <0x03>;
+ phandle = <0x41>;
+ };
+
+ pcm_gpio18 {
+ brcm,pins = <0x12 0x13 0x14 0x15>;
+ brcm,function = <0x04>;
+ phandle = <0x42>;
+ };
+
+ pcm_gpio28 {
+ brcm,pins = <0x1c 0x1d 0x1e 0x1f>;
+ brcm,function = <0x06>;
+ phandle = <0x43>;
+ };
+
+ pwm0_gpio12 {
+ brcm,pins = <0x0c>;
+ brcm,function = <0x04>;
+ phandle = <0x44>;
+ };
+
+ pwm0_gpio18 {
+ brcm,pins = <0x12>;
+ brcm,function = <0x02>;
+ phandle = <0x45>;
+ };
+
+ pwm0_gpio40 {
+ brcm,pins = <0x28>;
+ brcm,function = <0x04>;
+ phandle = <0x46>;
+ };
+
+ pwm1_gpio13 {
+ brcm,pins = <0x0d>;
+ brcm,function = <0x04>;
+ phandle = <0x47>;
+ };
+
+ pwm1_gpio19 {
+ brcm,pins = <0x13>;
+ brcm,function = <0x02>;
+ phandle = <0x48>;
+ };
+
+ pwm1_gpio41 {
+ brcm,pins = <0x29>;
+ brcm,function = <0x04>;
+ phandle = <0x49>;
+ };
+
+ pwm1_gpio45 {
+ brcm,pins = <0x2d>;
+ brcm,function = <0x04>;
+ phandle = <0x4a>;
+ };
+
+ sdhost_gpio48 {
+ brcm,pins = <0x16 0x17 0x18 0x19 0x1a 0x1b>;
+ brcm,function = <0x04>;
+ phandle = <0x0b>;
+ };
+
+ spi0_gpio7 {
+ brcm,pins = <0x07 0x08 0x09 0x0a 0x0b>;
+ brcm,function = <0x04>;
+ phandle = <0x4b>;
+ };
+
+ spi0_gpio35 {
+ brcm,pins = <0x23 0x24 0x25 0x26 0x27>;
+ brcm,function = <0x04>;
+ phandle = <0x4c>;
+ };
+
+ spi1_gpio16 {
+ brcm,pins = <0x10 0x11 0x12 0x13 0x14 0x15>;
+ brcm,function = <0x03>;
+ phandle = <0x4d>;
+ };
+
+ spi2_gpio40 {
+ brcm,pins = <0x28 0x29 0x2a 0x2b 0x2c 0x2d>;
+ brcm,function = <0x03>;
+ phandle = <0x4e>;
+ };
+
+ uart0_gpio14: uart0_gpio14 {
+ brcm,pins = <0x0e 0x0f>;
+ brcm,function = <0x04>;
+ phandle = <0x4f>;
+ };
+
+ uart0: uart0_ctsrts_gpio16 {
+ brcm,pins = <0x10 0x11>;
+ brcm,function = <0x07>;
+ phandle = <0x50>;
+ };
+
+ uart0_ctsrts_gpio30 {
+ brcm,pins = <0x1e 0x1f>;
+ brcm,function = <0x07>;
+ brcm,pull = <0x02 0x00>;
+ phandle = <0x51>;
+ };
+
+ uart0_gpio32 {
+ brcm,pins = <0x20 0x21>;
+ brcm,function = <0x07>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x52>;
+ };
+
+ uart0_gpio36 {
+ brcm,pins = <0x24 0x25>;
+ brcm,function = <0x06>;
+ phandle = <0x53>;
+ };
+
+ uart0_ctsrts_gpio38 {
+ brcm,pins = <0x26 0x27>;
+ brcm,function = <0x06>;
+ phandle = <0x54>;
+ };
+
+ uart1_gpio14: uart1_gpio14 {
+ brcm,pins = <0x0e 0x0f>;
+ brcm,function = <0x02>;
+ phandle = <0x55>;
+ };
+
+ uart1: uart1_ctsrts_gpio16 {
+ brcm,pins = <0x10 0x11>;
+ brcm,function = <0x02>;
+ phandle = <0x56>;
+ };
+
+ uart1_gpio32 {
+ brcm,pins = <0x20 0x21>;
+ brcm,function = <0x02>;
+ phandle = <0x57>;
+ };
+
+ uart1_ctsrts_gpio30 {
+ brcm,pins = <0x1e 0x1f>;
+ brcm,function = <0x02>;
+ phandle = <0x58>;
+ };
+
+ uart1_gpio40 {
+ brcm,pins = <0x28 0x29>;
+ brcm,function = <0x02>;
+ phandle = <0x59>;
+ };
+
+ uart1_ctsrts_gpio42 {
+ brcm,pins = <0x2a 0x2b>;
+ brcm,function = <0x02>;
+ phandle = <0x5a>;
+ };
+
+ gpclk0_gpio49 {
+ brcm,pins = <0x31>;
+ brcm,function = <0x05>;
+ brcm,pull = <0x00>;
+ phandle = <0x5b>;
+ };
+
+ gpclk1_gpio50 {
+ brcm,pins = <0x32>;
+ brcm,function = <0x05>;
+ brcm,pull = <0x00>;
+ phandle = <0x5c>;
+ };
+
+ gpclk2_gpio51 {
+ brcm,pins = <0x33>;
+ brcm,function = <0x05>;
+ brcm,pull = <0x00>;
+ phandle = <0x5d>;
+ };
+
+ i2c0_gpio46 {
+ brcm,pins = <0x2e 0x2f>;
+ brcm,function = <0x04>;
+ phandle = <0x5e>;
+ };
+
+ i2c1_gpio46 {
+ brcm,pins = <0x2e 0x2f>;
+ brcm,function = <0x05>;
+ phandle = <0x5f>;
+ };
+
+ i2c3_gpio2 {
+ brcm,pins = <0x02 0x03>;
+ brcm,function = <0x02>;
+ phandle = <0x60>;
+ };
+
+ i2c3_gpio4 {
+ brcm,pins = <0x04 0x05>;
+ brcm,function = <0x02>;
+ phandle = <0x61>;
+ };
+
+ i2c4_gpio6 {
+ brcm,pins = <0x06 0x07>;
+ brcm,function = <0x02>;
+ phandle = <0x62>;
+ };
+
+ i2c4_gpio8 {
+ brcm,pins = <0x08 0x09>;
+ brcm,function = <0x02>;
+ phandle = <0x63>;
+ };
+
+ i2c5_gpio10 {
+ brcm,pins = <0x0a 0x0b>;
+ brcm,function = <0x02>;
+ phandle = <0x64>;
+ };
+
+ i2c5_gpio12 {
+ brcm,pins = <0x0c 0x0d>;
+ brcm,function = <0x02>;
+ phandle = <0x65>;
+ };
+
+ i2c6_gpio0 {
+ brcm,pins = <0x00 0x01>;
+ brcm,function = <0x02>;
+ phandle = <0x66>;
+ };
+
+ i2c6_gpio22 {
+ brcm,pins = <0x16 0x17>;
+ brcm,function = <0x02>;
+ phandle = <0x67>;
+ };
+
+ i2c_slave_gpio8 {
+ brcm,pins = <0x08 0x09 0x0a 0x0b>;
+ brcm,function = <0x07>;
+ phandle = <0x68>;
+ };
+
+ jtag_gpio48 {
+ brcm,pins = <0x30 0x31 0x32 0x33 0x34 0x35>;
+ brcm,function = <0x03>;
+ phandle = <0x69>;
+ };
+
+ mii_gpio28 {
+ brcm,pins = <0x1c 0x1d 0x1e 0x1f>;
+ brcm,function = <0x03>;
+ phandle = <0x6a>;
+ };
+
+ mii_gpio36 {
+ brcm,pins = <0x24 0x25 0x26 0x27>;
+ brcm,function = <0x02>;
+ phandle = <0x6b>;
+ };
+
+ pcm_gpio50 {
+ brcm,pins = <0x32 0x33 0x34 0x35>;
+ brcm,function = <0x06>;
+ phandle = <0x6c>;
+ };
+
+ pwm0_gpio52 {
+ brcm,pins = <0x34>;
+ brcm,function = <0x05>;
+ brcm,pull = <0x00>;
+ phandle = <0x6d>;
+ };
+
+ pwm1_gpio53 {
+ brcm,pins = <0x35>;
+ brcm,function = <0x05>;
+ brcm,pull = <0x00>;
+ phandle = <0x6e>;
+ };
+
+ rgmii_gpio35 {
+ brcm,pins = <0x23 0x24>;
+ brcm,function = <0x03>;
+ phandle = <0x6f>;
+ };
+
+ rgmii_irq_gpio34 {
+ brcm,pins = <0x22>;
+ brcm,function = <0x02>;
+ phandle = <0x70>;
+ };
+
+ rgmii_irq_gpio39 {
+ brcm,pins = <0x27>;
+ brcm,function = <0x03>;
+ phandle = <0x71>;
+ };
+
+ rgmii_mdio_gpio28 {
+ brcm,pins = <0x1c 0x1d>;
+ brcm,function = <0x02>;
+ phandle = <0x72>;
+ };
+
+ rgmii_mdio_gpio37 {
+ brcm,pins = <0x25 0x26>;
+ brcm,function = <0x03>;
+ phandle = <0x73>;
+ };
+
+ spi0_gpio46 {
+ brcm,pins = <0x2e 0x2f 0x30 0x31>;
+ brcm,function = <0x06>;
+ phandle = <0x74>;
+ };
+
+ spi2_gpio46 {
+ brcm,pins = <0x2e 0x2f 0x30 0x31 0x32>;
+ brcm,function = <0x02>;
+ phandle = <0x75>;
+ };
+
+ spi3_gpio0 {
+ brcm,pins = <0x00 0x01 0x02 0x03>;
+ brcm,function = <0x07>;
+ phandle = <0x76>;
+ };
+
+ spi4_gpio4 {
+ brcm,pins = <0x04 0x05 0x06 0x07>;
+ brcm,function = <0x07>;
+ phandle = <0x77>;
+ };
+
+ spi5_gpio12 {
+ brcm,pins = <0x0c 0x0d 0x0e 0x0f>;
+ brcm,function = <0x07>;
+ phandle = <0x78>;
+ };
+
+ spi6_gpio18 {
+ brcm,pins = <0x12 0x13 0x14 0x15>;
+ brcm,function = <0x07>;
+ phandle = <0x79>;
+ };
+
+ uart2_gpio0 {
+ brcm,pins = <0x00 0x01>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x7a>;
+ };
+
+ uart2_ctsrts_gpio2 {
+ brcm,pins = <0x02 0x03>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x02 0x00>;
+ phandle = <0x7b>;
+ };
+
+ uart3_gpio4 {
+ brcm,pins = <0x04 0x05>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x7c>;
+ };
+
+ uart3_ctsrts_gpio6 {
+ brcm,pins = <0x06 0x07>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x02 0x00>;
+ phandle = <0x7d>;
+ };
+
+ uart4_gpio8 {
+ brcm,pins = <0x08 0x09>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x7e>;
+ };
+
+ uart4_ctsrts_gpio10 {
+ brcm,pins = <0x0a 0x0b>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x02 0x00>;
+ phandle = <0x7f>;
+ };
+
+ uart5_gpio12 {
+ brcm,pins = <0x0c 0x0d>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x80>;
+ };
+
+ uart5_ctsrts_gpio14 {
+ brcm,pins = <0x0e 0x0f>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x02 0x00>;
+ phandle = <0x81>;
+ };
+
+ dpi_18bit_gpio0 {
+ brcm,pins = <0x00 0x01 0x02 0x03
+ 0x04 0x05 0x06 0x07
+ 0x08 0x09 0x0a 0x0b
+ 0x0c 0x0d 0x0e 0x0f
+ 0x10 0x11 0x12 0x13
+ 0x14 0x15>;
+ brcm,function = <0x06>;
+ phandle = <0x82>;
+ };
+
+ spi0_pins {
+ brcm,pins = <0x09 0x0a 0x0b>;
+ brcm,function = <0x04>;
+ phandle = <0x0d>;
+ };
+
+ spi0_cs_pins {
+ brcm,pins = <0x08 0x07>;
+ brcm,function = <0x01>;
+ phandle = <0x0e>;
+ };
+
+ spi3_pins {
+ brcm,pins = <0x01 0x02 0x03>;
+ brcm,function = <0x07>;
+ phandle = <0x83>;
+ };
+
+ spi3_cs_pins {
+ brcm,pins = <0x00 0x18>;
+ brcm,function = <0x01>;
+ phandle = <0x84>;
+ };
+
+ spi4_pins {
+ brcm,pins = <0x05 0x06 0x07>;
+ brcm,function = <0x07>;
+ phandle = <0x85>;
+ };
+
+ spi4_cs_pins {
+ brcm,pins = <0x04 0x19>;
+ brcm,function = <0x01>;
+ phandle = <0x86>;
+ };
+
+ spi5_pins {
+ brcm,pins = <0x0d 0x0e 0x0f>;
+ brcm,function = <0x07>;
+ phandle = <0x87>;
+ };
+
+ spi5_cs_pins {
+ brcm,pins = <0x0c 0x1a>;
+ brcm,function = <0x01>;
+ phandle = <0x88>;
+ };
+
+ spi6_pins {
+ brcm,pins = <0x13 0x14 0x15>;
+ brcm,function = <0x07>;
+ phandle = <0x89>;
+ };
+
+ spi6_cs_pins {
+ brcm,pins = <0x12 0x1b>;
+ brcm,function = <0x01>;
+ phandle = <0x8a>;
+ };
+
+ i2c0 {
+ brcm,pins = <0x00 0x01>;
+ brcm,function = <0x04>;
+ phandle = <0x10>;
+ };
+
+ i2c1 {
+ brcm,pins = <0x02 0x03>;
+ brcm,function = <0x04>;
+ phandle = <0x14>;
+ };
+
+ i2c3 {
+ brcm,pins = <0x04 0x05>;
+ brcm,function = <0x02>;
+ phandle = <0x8b>;
+ };
+
+ i2c4 {
+ brcm,pins = <0x08 0x09>;
+ brcm,function = <0x02>;
+ phandle = <0x8c>;
+ };
+
+ i2c5 {
+ brcm,pins = <0x0c 0x0d>;
+ brcm,function = <0x02>;
+ phandle = <0x8d>;
+ };
+
+ i2c6 {
+ brcm,pins = <0x16 0x17>;
+ brcm,function = <0x02>;
+ phandle = <0x8e>;
+ };
+
+ i2s {
+ brcm,pins = <0x12 0x13 0x14 0x15>;
+ brcm,function = <0x04>;
+ phandle = <0x0c>;
+ };
+
+ sdio_pins {
+ brcm,pins = <0x22 0x23 0x24 0x25 0x26 0x27>;
+ brcm,function = <0x07>;
+ brcm,pull = <0x00 0x02 0x02 0x02 0x02 0x02>;
+ phandle = <0x19>;
+ };
+
+ bt_pins {
+ brcm,pins = [2d 00];
+ brcm,function = <0x00>;
+ brcm,pull = <0x02>;
+ phandle = <0x09>;
+ };
+
+ uart0_pins {
+ brcm,pins = <0x20 0x21>;
+ brcm,function = <0x07>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x08>;
+ };
+
+ uart1_pins {
+ brcm,pins;
+ brcm,function;
+ brcm,pull;
+ phandle = <0x12>;
+ };
+
+ uart2_pins {
+ brcm,pins = <0x00 0x01>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x8f>;
+ };
+
+ uart3_pins {
+ brcm,pins = <0x04 0x05>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x90>;
+ };
+
+ uart4_pins {
+ brcm,pins = <0x08 0x09>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x91>;
+ };
+
+ uart5_pins {
+ brcm,pins = <0x0c 0x0d>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x92>;
+ };
+
+ audio_pins {
+ brcm,pins = <0x28 0x29>;
+ brcm,function = <0x04>;
+ phandle = <0x1b>;
+ };
+ };
+
+ serial@7e201000 {
+ compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
+ reg = <0x7e201000 0x200>;
+ interrupts = <0x00 0x79 0x04>;
+ clocks = <0x03 0x13 0x03 0x14>;
+ clock-names = "uartclk\0apb_pclk";
+ arm,primecell-periphid = <0x241011>;
+ cts-event-workaround;
+ pinctrl-names = "default";
+ pinctrl-0 = <0x08 0x09>;
+ status = "okay";
+ phandle = <0x1f>;
+ };
+
+ mmc@7e202000 {
+ compatible = "brcm,bcm2835-sdhost";
+ reg = <0x7e202000 0x100>;
+ interrupts = <0x00 0x78 0x04>;
+ clocks = <0x03 0x14>;
+ dmas = <0x0a 0x2000000d>;
+ dma-names = "rx-tx";
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <0x0b>;
+ bus-width = <0x04>;
+ brcm,overclock-50 = <0x00>;
+ brcm,pio-limit = <0x01>;
+ phandle = <0x27>;
+ };
+
+ i2s@7e203000 {
+ compatible = "brcm,bcm2835-i2s";
+ reg = <0x7e203000 0x24>;
+ clocks = <0x03 0x1f>;
+ dmas = <0x0a 0x02 0x0a 0x03>;
+ dma-names = "tx\0rx";
+ status = "disabled";
+ #sound-dai-cells = <0x00>;
+ pinctrl-names = "default";
+ pinctrl-0 = <0x0c>;
+ phandle = <0x21>;
+ };
+
+ spi@7e204000 {
+ compatible = "brcm,bcm2835-spi";
+ reg = <0x7e204000 0x200>;
+ interrupts = <0x00 0x76 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ dmas = <0x0a 0x06 0x0a 0x07>;
+ dma-names = "tx\0rx";
+ pinctrl-names = "default";
+ pinctrl-0 = <0x0d 0x0e>;
+ cs-gpios = <0x0f 0x08 0x01 0x0f 0x07 0x01>;
+ phandle = <0x22>;
+
+ spidev@0 {
+ compatible = "spidev";
+ reg = <0x00>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ spi-max-frequency = <0x7735940>;
+ phandle = <0x93>;
+ };
+
+ spidev@1 {
+ compatible = "spidev";
+ reg = <0x01>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ spi-max-frequency = <0x7735940>;
+ phandle = <0x94>;
+ };
+ };
+
+ i2c@7e205000 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e205000 0x200>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <0x10>;
+ clock-frequency = <0x186a0>;
+ phandle = <0x23>;
+ };
+
+ pixelvalve@7e206000 {
+ compatible = "brcm,bcm2835-pixelvalve0";
+ reg = <0x7e206000 0x100>;
+ interrupts = <0x00 0x6d 0x04>;
+ status = "disabled";
+ phandle = <0x95>;
+ };
+
+ pixelvalve@7e207000 {
+ compatible = "brcm,bcm2835-pixelvalve1";
+ reg = <0x7e207000 0x100>;
+ interrupts = <0x00 0x6e 0x04>;
+ status = "disabled";
+ phandle = <0x96>;
+ };
+
+ dpi@7e208000 {
+ compatible = "brcm,bcm2835-dpi";
+ reg = <0x7e208000 0x8c>;
+ clocks = <0x03 0x14 0x03 0x2c>;
+ clock-names = "core\0pixel";
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0x97>;
+ };
+
+ dsi@7e209000 {
+ compatible = "brcm,bcm2835-dsi0";
+ reg = <0x7e209000 0x78>;
+ interrupts = <0x00 0x64 0x04>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ #clock-cells = <0x01>;
+ clocks = <0x03 0x20 0x03 0x2f 0x03 0x31>;
+ clock-names = "phy\0escape\0pixel";
+ clock-output-names = "dsi0_byte\0dsi0_ddr2\0dsi0_ddr";
+ phandle = <0x05>;
+ };
+
+ aux@7e215000 {
+ compatible = "brcm,bcm2835-aux";
+ #clock-cells = <0x01>;
+ reg = <0x7e215000 0x08>;
+ clocks = <0x03 0x14>;
+ phandle = <0x11>;
+ };
+
+ serial@7e215040 {
+ compatible = "brcm,bcm2835-aux-uart";
+ reg = <0x7e215040 0x40>;
+ interrupts = <0x00 0x5d 0x04>;
+ clocks = <0x11 0x00>;
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <0x12>;
+ phandle = <0x20>;
+ };
+
+ spi@7e215080 {
+ compatible = "brcm,bcm2835-aux-spi";
+ reg = <0x7e215080 0x40>;
+ interrupts = <0x00 0x5d 0x04>;
+ clocks = <0x11 0x01>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0x98>;
+ };
+
+ spi@7e2150c0 {
+ compatible = "brcm,bcm2835-aux-spi";
+ reg = <0x7e2150c0 0x40>;
+ interrupts = <0x00 0x5d 0x04>;
+ clocks = <0x11 0x02>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0x99>;
+ };
+
+ pwm@7e20c000 {
+ compatible = "brcm,bcm2835-pwm";
+ reg = <0x7e20c000 0x28>;
+ clocks = <0x03 0x1e>;
+ assigned-clocks = <0x03 0x1e>;
+ assigned-clock-rates = <0x989680>;
+ #pwm-cells = <0x02>;
+ status = "disabled";
+ phandle = <0x9a>;
+ };
+
+ hvs@7e400000 {
+ compatible = "brcm,bcm2835-hvs";
+ reg = <0x7e400000 0x6000>;
+ interrupts = <0x00 0x61 0x04>;
+ status = "disabled";
+ phandle = <0x9b>;
+ };
+
+ dsi@7e700000 {
+ compatible = "brcm,bcm2835-dsi1";
+ reg = <0x7e700000 0x8c>;
+ interrupts = <0x00 0x6c 0x04>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ #clock-cells = <0x01>;
+ clocks = <0x03 0x23 0x03 0x30 0x03 0x32>;
+ clock-names = "phy\0escape\0pixel";
+ clock-output-names = "dsi1_byte\0dsi1_ddr2\0dsi1_ddr";
+ status = "disabled";
+ phandle = <0x06>;
+ };
+
+ csi@7e800000 {
+ compatible = "brcm,bcm2835-unicam";
+ reg = <0x7e800000 0x800 0x7e802000 0x04>;
+ interrupts = <0x00 0x66 0x04>;
+ clocks = <0x03 0x2d>;
+ clock-names = "lp";
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ #clock-cells = <0x01>;
+ status = "disabled";
+ power-domains = <0x13 0x0c>;
+ phandle = <0x9c>;
+ };
+
+ csi@7e801000 {
+ compatible = "brcm,bcm2835-unicam";
+ reg = <0x7e801000 0x800 0x7e802004 0x04>;
+ interrupts = <0x00 0x67 0x04>;
+ clocks = <0x03 0x2e>;
+ clock-names = "lp";
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ #clock-cells = <0x01>;
+ status = "disabled";
+ power-domains = <0x13 0x0d>;
+ phandle = <0x9d>;
+
+ port {
+
+ endpoint {
+ data-lanes = <0x01 0x02>;
+ };
+ };
+ };
+
+ i2c@7e804000 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e804000 0x1000>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <0x14>;
+ clock-frequency = <0x186a0>;
+ phandle = <0x24>;
+ };
+
+ i2c@7e805000 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e805000 0x1000>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ clock-frequency = <0x186a0>;
+ phandle = <0x15>;
+ };
+
+ vec@7e806000 {
+ compatible = "brcm,bcm2835-vec";
+ reg = <0x7e806000 0x1000>;
+ clocks = <0x03 0x18>;
+ interrupts = <0x00 0x7b 0x04>;
+ status = "disabled";
+ phandle = <0x9e>;
+ };
+
+ pixelvalve@7e807000 {
+ compatible = "brcm,bcm2835-pixelvalve2";
+ reg = <0x7e807000 0x100>;
+ interrupts = <0x00 0x6a 0x04>;
+ status = "disabled";
+ phandle = <0x9f>;
+ };
+
+ hdmi@7e902000 {
+ compatible = "brcm,bcm2835-hdmi";
+ reg = <0x7e902000 0x600 0x7e808000 0x100>;
+ interrupts = <0x00 0x68 0x04 0x00 0x69 0x04>;
+ ddc = <0x15>;
+ clocks = <0x03 0x10 0x03 0x19>;
+ clock-names = "pixel\0hdmi";
+ dmas = <0x0a 0x11>;
+ dma-names = "audio-rx";
+ status = "disabled";
+ power-domains = <0x13 0x05>;
+ phandle = <0xa0>;
+ };
+
+ usb@7e980000 {
+ compatible = "brcm,bcm2708-usb";
+ reg = <0x7e980000 0x10000 0x7e00b200 0x200>;
+ interrupts = <0x00 0x49 0x04 0x00 0x28 0x04>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ clocks = <0x16>;
+ clock-names = "otg";
+ phys = <0x17>;
+ phy-names = "usb2-phy";
+ interrupt-names = "usb\0soft";
+ power-domains = <0x13 0x06>;
+ phandle = <0xa1>;
+ };
+
+ gpu {
+ compatible = "brcm,bcm2835-vc4";
+ status = "disabled";
+ phandle = <0xa2>;
+ };
+
+ local_intc@40000000 {
+ compatible = "brcm,bcm2836-l1-intc";
+ reg = <0x40000000 0x100>;
+ phandle = <0xa3>;
+ };
+
+ gic400@40041000 {
+ interrupt-controller;
+ #interrupt-cells = <0x03>;
+ compatible = "arm,gic-400";
+ reg = <0x40041000 0x1000 0x40042000 0x2000 0x40046000 0x2000 0x40048000 0x2000>;
+ phandle = <0x01>;
+ };
+
+ thermal@7d5d2200 {
+ compatible = "brcm,avs-tmon-bcm2838";
+ reg = <0x7d5d2200 0x2c>;
+ interrupts = <0x00 0x89 0x04>;
+ interrupt-names = "tmon";
+ clocks = <0x03 0x1b>;
+ #thermal-sensor-cells = <0x00>;
+ status = "okay";
+ phandle = <0x02>;
+ };
+
+ serial@7e201400 {
+ compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
+ reg = <0x7e201400 0x200>;
+ interrupts = <0x00 0x79 0x04>;
+ clocks = <0x03 0x13 0x03 0x14>;
+ clock-names = "uartclk\0apb_pclk";
+ arm,primecell-periphid = <0x241011>;
+ status = "disabled";
+ phandle = <0xa4>;
+ };
+
+ serial@7e201600 {
+ compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
+ reg = <0x7e201600 0x200>;
+ interrupts = <0x00 0x79 0x04>;
+ clocks = <0x03 0x13 0x03 0x14>;
+ clock-names = "uartclk\0apb_pclk";
+ arm,primecell-periphid = <0x241011>;
+ status = "disabled";
+ phandle = <0xa5>;
+ };
+
+ serial@7e201800 {
+ compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
+ reg = <0x7e201800 0x200>;
+ interrupts = <0x00 0x79 0x04>;
+ clocks = <0x03 0x13 0x03 0x14>;
+ clock-names = "uartclk\0apb_pclk";
+ arm,primecell-periphid = <0x241011>;
+ status = "disabled";
+ phandle = <0xa6>;
+ };
+
+ serial@7e201a00 {
+ compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
+ reg = <0x7e201a00 0x200>;
+ interrupts = <0x00 0x79 0x04>;
+ clocks = <0x03 0x13 0x03 0x14>;
+ clock-names = "uartclk\0apb_pclk";
+ arm,primecell-periphid = <0x241011>;
+ status = "disabled";
+ phandle = <0xa7>;
+ };
+
+ spi@7e204600 {
+ compatible = "brcm,bcm2835-spi";
+ reg = <0x7e204600 0x200>;
+ interrupts = <0x00 0x76 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xa8>;
+ };
+
+ spi@7e204800 {
+ compatible = "brcm,bcm2835-spi";
+ reg = <0x7e204800 0x200>;
+ interrupts = <0x00 0x76 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xa9>;
+ };
+
+ spi@7e204a00 {
+ compatible = "brcm,bcm2835-spi";
+ reg = <0x7e204a00 0x200>;
+ interrupts = <0x00 0x76 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xaa>;
+ };
+
+ spi@7e204c00 {
+ compatible = "brcm,bcm2835-spi";
+ reg = <0x7e204c00 0x200>;
+ interrupts = <0x00 0x76 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xab>;
+ };
+
+ i2c@7e205600 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e205600 0x200>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xac>;
+ };
+
+ i2c@7e205800 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e205800 0x200>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xad>;
+ };
+
+ i2c@7e205a00 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e205a00 0x200>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xae>;
+ };
+
+ i2c@7e205c00 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e205c00 0x200>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xaf>;
+ };
+
+ emmc2@7e340000 {
+ compatible = "brcm,bcm2711-emmc2";
+ status = "okay";
+ interrupts = <0x00 0x7e 0x04>;
+ clocks = <0x03 0x33>;
+ reg = <0x7e340000 0x100>;
+ broken-cd;
+ vqmmc-supply = <0x18>;
+ phandle = <0xb0>;
+ };
+
+ mmc@7e300000 {
+ compatible = "brcm,bcm2835-mmc\0brcm,bcm2835-sdhci";
+ reg = <0x7e300000 0x100>;
+ interrupts = <0x00 0x7e 0x04>;
+ clocks = <0x03 0x1c>;
+ dmas = <0x0a 0x0b>;
+ dma-names = "rx-tx";
+ brcm,overclock-50 = <0x00>;
+ status = "disabled";
+ phandle = <0x28>;
+ };
+
+ mmcnr@7e300000 {
+ compatible = "brcm,bcm2835-mmc\0brcm,bcm2835-sdhci";
+ reg = <0x7e300000 0x100>;
+ interrupts = <0x00 0x7e 0x04>;
+ clocks = <0x03 0x1c>;
+ dmas = <0x0a 0x0b>;
+ dma-names = "rx-tx";
+ brcm,overclock-50 = <0x00>;
+ non-removable;
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <0x19>;
+ bus-width = <0x04>;
+ phandle = <0x29>;
+ };
+
+ firmwarekms@7e600000 {
+ compatible = "raspberrypi,rpi-firmware-kms";
+ reg = <0x7e600000 0x100>;
+ interrupts = <0x00 0x70 0x04>;
+ brcm,firmware = <0x07>;
+ status = "disabled";
+ phandle = <0xb1>;
+ };
+
+ smi@7e600000 {
+ compatible = "brcm,bcm2835-smi";
+ reg = <0x7e600000 0x100>;
+ interrupts = <0x00 0x70 0x04>;
+ clocks = <0x03 0x2a>;
+ assigned-clocks = <0x03 0x2a>;
+ assigned-clock-rates = <0x7735940>;
+ dmas = <0x0a 0x04>;
+ dma-names = "rx-tx";
+ status = "disabled";
+ phandle = <0xb2>;
+ };
+
+ axiperf {
+ compatible = "brcm,bcm2835-axiperf";
+ reg = <0x7e009800 0x100 0x7ee08000 0x100>;
+ firmware = <0x07>;
+ status = "disabled";
+ phandle = <0x2a>;
+ };
+
+ gpiomem {
+ compatible = "brcm,bcm2835-gpiomem";
+ reg = <0x7e200000 0x1000>;
+ };
+
+ firmware {
+ compatible = "raspberrypi,bcm2835-firmware\0simple-bus";
+ #address-cells = <0x00>;
+ #size-cells = <0x00>;
+ mboxes = <0x1a>;
+ phandle = <0x07>;
+
+ expgpio {
+ compatible = "raspberrypi,firmware-gpio";
+ gpio-controller;
+ #gpio-cells = <0x02>;
+ status = "okay";
+ phandle = <0x2d>;
+ };
+ };
+
+ power {
+ compatible = "raspberrypi,bcm2835-power";
+ firmware = <0x07>;
+ #power-domain-cells = <0x01>;
+ phandle = <0x13>;
+ };
+
+ fb {
+ compatible = "brcm,bcm2708-fb";
+ firmware = <0x07>;
+ status = "okay";
+ phandle = <0xb3>;
+ };
+
+ vcsm {
+ compatible = "raspberrypi,bcm2835-vcsm";
+ firmware = <0x07>;
+ status = "okay";
+ phandle = <0xb4>;
+ };
+
+ audio {
+ compatible = "brcm,bcm2835-audio";
+ brcm,pwm-channels = <0x08>;
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <0x1b>;
+ phandle = <0x25>;
+ };
+
+ sound {
+ status = "disabled";
+ phandle = <0xb5>;
+ };
+
+ virtgpio {
+ compatible = "brcm,bcm2835-virtgpio";
+ gpio-controller;
+ #gpio-cells = <0x02>;
+ firmware = <0x07>;
+ status = "okay";
+ phandle = <0xb6>;
+ };
+ };
+
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+
+ clock@3 {
+ compatible = "fixed-clock";
+ reg = <0x03>;
+ #clock-cells = <0x00>;
+ clock-output-names = "osc";
+ clock-frequency = <0x337f980>;
+ phandle = <0x04>;
+ };
+
+ clock@4 {
+ compatible = "fixed-clock";
+ reg = <0x04>;
+ #clock-cells = <0x00>;
+ clock-output-names = "otg";
+ clock-frequency = <0x1c9c3800>;
+ phandle = <0x16>;
+ };
+ };
+
+ phy {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0x00>;
+ phandle = <0x17>;
+ };
+
+ arm-pmu {
+ compatible = "arm,cortex-a72-pmu\0arm,cortex-a53-pmu";
+ interrupts = <0x00 0x10 0x04 0x00 0x11 0x04 0x00 0x12 0x04 0x00 0x13 0x04>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <0x01 0x0d 0xf08 0x01 0x0e 0xf08 0x01 0x0b 0xf08 0x01 0x0a 0xf08>;
+ arm,cpu-registers-not-fw-configured;
+ always-on;
+ };
+
+ cpus {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ enable-method = "brcm,bcm2836-smp";
+ phandle = <0xb7>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x00>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x00 0xd8>;
+ phandle = <0xb8>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x01>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x00 0xe0>;
+ phandle = <0xb9>;
+ };
+
+ cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x02>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x00 0xe8>;
+ phandle = <0xba>;
+ };
+
+ cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x03>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x00 0xf0>;
+ phandle = <0xbb>;
+ };
+ };
+
+ v3dbus {
+ compatible = "simple-bus";
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ ranges = <0x7c500000 0x00 0xfc500000 0x3300000 0x40000000 0x00 0xff800000 0x800000>;
+ dma-ranges = <0x00 0x00 0x00 0x3c000000>;
+
+ v3d@7ec04000 {
+ compatible = "brcm,2711-v3d";
+ reg = <0x7ec00000 0x4000 0x7ec04000 0x4000>;
+ reg-names = "hub\0core0";
+ power-domains = <0x1c 0x01>;
+ resets = <0x1c 0x00>;
+ clocks = <0x03 0x15>;
+ interrupts = <0x00 0x4a 0x04>;
+ status = "okay";
+ phandle = <0xbc>;
+ };
+ };
+
+ scb {
+ compatible = "simple-bus";
+ #address-cells = <0x02>;
+ #size-cells = <0x01>;
+ ranges = <0x00 0x7c000000 0x00 0xfc000000
+ 0x3800000 0x00 0x40000000 0x00
+ 0xff800000 0x800000 0x06 0x00
+ 0x06 0x00 0x40000000 0x00
+ 0x00 0x00 0x00 0xfc000000>;
+ dma-ranges = <0x00 0x00 0x00 0x00 0xfc000000>;
+ phandle = <0xbd>;
+
+ pcie@7d500000 {
+ reg = <0x00 0x7d500000 0x9310 0x00 0x7e00f300 0x20>;
+ msi-controller;
+ msi-parent = <0x1d>;
+ #address-cells = <0x03>;
+ #interrupt-cells = <0x01>;
+ #size-cells = <0x02>;
+ bus-range = <0x00 0x01>;
+ compatible = "brcm,bcm7211-pcie\0brcm,bcm7445-pcie\0brcm,pci-plat-dev";
+ max-link-speed = <0x02>;
+ tot-num-pcie = <0x01>;
+ linux,pci-domain = <0x00>;
+ interrupts = <0x00 0x94 0x04 0x00 0x94 0x04>;
+ interrupt-names = "pcie\0msi";
+ interrupt-map-mask = <0x00 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01
+ 0x01 0x00 0x8f 0x04 0x00 0x00 0x00 0x02
+ 0x01 0x00 0x90 0x04 0x00 0x00 0x00 0x03
+ 0x01 0x00 0x91 0x04 0x00 0x00 0x00 0x04
+ 0x01 0x00 0x92 0x04>;
+ ranges = <0x2000000 0x00 0xf8000000 0x06 0x00 0x00 0x4000000>;
+ dma-ranges = <0x2000000 0x00 0x00 0x00 0x00 0x01 0x00>;
+ status = "okay";
+ phandle = <0x1d>;
+ };
+
+ genet@7d580000 {
+ compatible = "brcm,genet-v5";
+ reg = <0x00 0x7d580000 0x10000>;
+ status = "okay";
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ interrupts = <0x00 0x9d 0x04 0x00 0x9e 0x04>;
+ phy-handle = <0x1e>;
+ phy-mode = "rgmii";
+ phandle = <0xbe>;
+
+ mdio@e14 {
+ #address-cells = <0x00>;
+ #size-cells = <0x01>;
+ compatible = "brcm,genet-mdio-v5";
+ reg = <0xe14 0x08>;
+ reg-names = "mdio";
+
+ genet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ max-speed = <0x3e8>;
+ reg = <0x01>;
+ phandle = <0x1e>;
+ };
+ };
+ };
+
+ dma@7e007b00 {
+ compatible = "brcm,bcm2838-dma";
+ reg = <0x00 0x7e007b00 0x400>;
+ interrupts = <0x00 0x59 0x04 0x00 0x5a 0x04 0x00 0x5b
+ 0x04 0x00 0x5c 0x04>;
+ interrupt-names = "dma11\0dma12\0dma13\0dma14";
+ #dma-cells = <0x01>;
+ brcm,dma-channel-mask = <0x7000>;
+ phandle = <0xbf>;
+ };
+
+ xhci@7e9c0000 {
+ compatible = "generic-xhci";
+ status = "disabled";
+ reg = <0x00 0x7e9c0000 0x100000>;
+ interrupts = <0x00 0xb0 0x04>;
+ phandle = <0xc0>;
+ };
+
+ mailbox@7e00b840 {
+ compatible = "brcm,bcm2838-vchiq";
+ reg = <0x00 0x7e00b840 0x3c>;
+ interrupts = <0x00 0x22 0x04>;
+ phandle = <0xc1>;
+ };
+
+ hevc-decoder@7eb00000 {
+ compatible = "raspberrypi,argon-hevc-decoder";
+ reg = <0x00 0x7eb00000 0x10000>;
+ status = "okay";
+ };
+
+ argon-local-intc@7eb10000 {
+ compatible = "raspberrypi,argon-local-intc";
+ reg = <0x00 0x7eb10000 0x1000>;
+ status = "okay";
+ interrupts = <0x00 0x62 0x04>;
+ };
+
+ h264-decoder@7eb20000 {
+ compatible = "raspberrypi,argon-h264-decoder";
+ reg = <0x00 0x7eb20000 0x10000>;
+ status = "okay";
+ };
+
+ vp9-decoder@7eb30000 {
+ compatible = "raspberrypi,argon-vp9-decoder";
+ reg = <0x00 0x7eb30000 0x10000>;
+ status = "okay";
+ };
+ };
+
+ fixedregulator_5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "5v0";
+ regulator-min-microvolt = <0x4c4b40>;
+ regulator-max-microvolt = <0x4c4b40>;
+ regulator-always-on;
+ phandle = <0x2e>;
+ };
+
+ fixedregulator_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <0x325aa0>;
+ regulator-max-microvolt = <0x325aa0>;
+ regulator-always-on;
+ phandle = <0xc2>;
+ };
+
+ __overrides__ {
+ cam0-pwdn-ctrl;
+ cam0-pwdn;
+ cam0-led-ctrl;
+ cam0-led;
+ cache_line_size;
+ uart0 = [00 00 00 1f 73 74 61 74 75 73 00];
+ uart1 = "\0\0\0 status";
+ i2s = "\0\0\0!status";
+ spi = "\0\0\0\"status";
+ i2c0 = "\0\0\0#status";
+ i2c1 = "\0\0\0$status";
+ i2c2_iknowwhatimdoing = [00 00 00 15 73 74 61 74 75 73 00];
+ i2c0_baudrate = "\0\0\0#clock-frequency:0";
+ i2c1_baudrate = "\0\0\0$clock-frequency:0";
+ i2c2_baudrate = [00 00 00 15 63 6c 6f 63
+ 6b 2d 66 72 65 71 75 65
+ 6e 63 79 3a 30 00];
+ audio = "\0\0\0%status";
+ watchdog = [00 00 00 1c 73 74 61 74 75 73 00];
+ random = "\0\0\0&status";
+ sd_overclock = "\0\0\0'brcm,overclock-50:0";
+ sd_force_pio = "\0\0\0'brcm,force-pio?";
+ sd_pio_limit = "\0\0\0'brcm,pio-limit:0";
+ sd_debug = "\0\0\0'brcm,debug";
+ sdio_overclock = "\0\0\0(brcm,overclock-50:0\0\0\0\0)brcm,overclock-50:0";
+ axiperf = "\0\0\0*status";
+ arm_freq;
+ act_led_gpio = "\0\0\0+gpios:4";
+ act_led_activelow = "\0\0\0+gpios:8";
+ act_led_trigger = "\0\0\0+linux,default-trigger";
+ pwr_led_gpio = "\0\0\0,gpios:4";
+ pwr_led_activelow = "\0\0\0,gpios:8";
+ pwr_led_trigger = "\0\0\0,linux,default-trigger";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00 0x00 0x00>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ phandle = <0xc3>;
+
+ act {
+ label = "led0";
+ linux,default-trigger = "mmc0";
+ gpios = <0x0f 0x2a 0x00>;
+ phandle = <0x2b>;
+ };
+
+ pwr {
+ label = "led1";
+ linux,default-trigger = "input";
+ gpios = <0x2d 0x02 0x00>;
+ phandle = <0x2c>;
+ };
+ };
+
+ sd_io_1v8_reg {
+ status = "okay";
+ compatible = "regulator-gpio";
+ vin-supply = <0x2e>;
+ regulator-name = "vdd-sd-io";
+ regulator-min-microvolt = <0x1b7740>;
+ regulator-max-microvolt = <0x325aa0>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-settling-time-us = <0x1388>;
+ gpios = <0x2d 0x04 0x00>;
+ states = <0x1b7740 0x01 0x325aa0 0x00>;
+ phandle = <0x18>;
+ };
+
+ __symbols__ {
+ cpu_thermal = "/thermal-zones/cpu-thermal";
+ soc = "/soc";
+ txp = "/soc/txp@7e004000";
+ dma = "/soc/dma@7e007000";
+ watchdog = "/soc/watchdog@7e100000";
+ pm = "/soc/watchdog@7e100000";
+ clocks = "/soc/cprman@7e101000";
+ random = "/soc/rng@7e104000";
+ rng = "/soc/rng@7e104000";
+ mailbox = "/soc/mailbox@7e00b880";
+ gpio = "/soc/gpio@7e200000";
+ dpi_gpio0 = "/soc/gpio@7e200000/dpi_gpio0";
+ emmc_gpio22 = "/soc/gpio@7e200000/emmc_gpio22";
+ emmc_gpio34 = "/soc/gpio@7e200000/emmc_gpio34";
+ emmc_gpio48 = "/soc/gpio@7e200000/emmc_gpio48";
+ gpclk0_gpio4 = "/soc/gpio@7e200000/gpclk0_gpio4";
+ gpclk1_gpio5 = "/soc/gpio@7e200000/gpclk1_gpio5";
+ gpclk1_gpio42 = "/soc/gpio@7e200000/gpclk1_gpio42";
+ gpclk1_gpio44 = "/soc/gpio@7e200000/gpclk1_gpio44";
+ gpclk2_gpio6 = "/soc/gpio@7e200000/gpclk2_gpio6";
+ gpclk2_gpio43 = "/soc/gpio@7e200000/gpclk2_gpio43";
+ i2c0_gpio0 = "/soc/gpio@7e200000/i2c0_gpio0";
+ i2c0_gpio28 = "/soc/gpio@7e200000/i2c0_gpio28";
+ i2c0_gpio44 = "/soc/gpio@7e200000/i2c0_gpio44";
+ i2c1_gpio2 = "/soc/gpio@7e200000/i2c1_gpio2";
+ i2c1_gpio44 = "/soc/gpio@7e200000/i2c1_gpio44";
+ jtag_gpio22 = "/soc/gpio@7e200000/jtag_gpio22";
+ pcm_gpio18 = "/soc/gpio@7e200000/pcm_gpio18";
+ pcm_gpio28 = "/soc/gpio@7e200000/pcm_gpio28";
+ pwm0_gpio12 = "/soc/gpio@7e200000/pwm0_gpio12";
+ pwm0_gpio18 = "/soc/gpio@7e200000/pwm0_gpio18";
+ pwm0_gpio40 = "/soc/gpio@7e200000/pwm0_gpio40";
+ pwm1_gpio13 = "/soc/gpio@7e200000/pwm1_gpio13";
+ pwm1_gpio19 = "/soc/gpio@7e200000/pwm1_gpio19";
+ pwm1_gpio41 = "/soc/gpio@7e200000/pwm1_gpio41";
+ pwm1_gpio45 = "/soc/gpio@7e200000/pwm1_gpio45";
+ sdhost_pins = "/soc/gpio@7e200000/sdhost_gpio48";
+ sdhost_gpio48 = "/soc/gpio@7e200000/sdhost_gpio48";
+ spi0_gpio7 = "/soc/gpio@7e200000/spi0_gpio7";
+ spi0_gpio35 = "/soc/gpio@7e200000/spi0_gpio35";
+ spi1_gpio16 = "/soc/gpio@7e200000/spi1_gpio16";
+ spi2_gpio40 = "/soc/gpio@7e200000/spi2_gpio40";
+ uart0_gpio14 = "/soc/gpio@7e200000/uart0_gpio14";
+ uart0_ctsrts_gpio16 = "/soc/gpio@7e200000/uart0_ctsrts_gpio16";
+ uart0_ctsrts_gpio30 = "/soc/gpio@7e200000/uart0_ctsrts_gpio30";
+ uart0_gpio32 = "/soc/gpio@7e200000/uart0_gpio32";
+ uart0_gpio36 = "/soc/gpio@7e200000/uart0_gpio36";
+ uart0_ctsrts_gpio38 = "/soc/gpio@7e200000/uart0_ctsrts_gpio38";
+ uart1_gpio14 = "/soc/gpio@7e200000/uart1_gpio14";
+ uart1_ctsrts_gpio16 = "/soc/gpio@7e200000/uart1_ctsrts_gpio16";
+ uart1_gpio32 = "/soc/gpio@7e200000/uart1_gpio32";
+ uart1_ctsrts_gpio30 = "/soc/gpio@7e200000/uart1_ctsrts_gpio30";
+ uart1_gpio40 = "/soc/gpio@7e200000/uart1_gpio40";
+ uart1_ctsrts_gpio42 = "/soc/gpio@7e200000/uart1_ctsrts_gpio42";
+ gpclk0_gpio49 = "/soc/gpio@7e200000/gpclk0_gpio49";
+ gpclk1_gpio50 = "/soc/gpio@7e200000/gpclk1_gpio50";
+ gpclk2_gpio51 = "/soc/gpio@7e200000/gpclk2_gpio51";
+ i2c0_gpio46 = "/soc/gpio@7e200000/i2c0_gpio46";
+ i2c1_gpio46 = "/soc/gpio@7e200000/i2c1_gpio46";
+ i2c3_gpio2 = "/soc/gpio@7e200000/i2c3_gpio2";
+ i2c3_gpio4 = "/soc/gpio@7e200000/i2c3_gpio4";
+ i2c4_gpio6 = "/soc/gpio@7e200000/i2c4_gpio6";
+ i2c4_gpio8 = "/soc/gpio@7e200000/i2c4_gpio8";
+ i2c5_gpio10 = "/soc/gpio@7e200000/i2c5_gpio10";
+ i2c5_gpio12 = "/soc/gpio@7e200000/i2c5_gpio12";
+ i2c6_gpio0 = "/soc/gpio@7e200000/i2c6_gpio0";
+ i2c6_gpio22 = "/soc/gpio@7e200000/i2c6_gpio22";
+ i2c_slave_gpio8 = "/soc/gpio@7e200000/i2c_slave_gpio8";
+ jtag_gpio48 = "/soc/gpio@7e200000/jtag_gpio48";
+ mii_gpio28 = "/soc/gpio@7e200000/mii_gpio28";
+ mii_gpio36 = "/soc/gpio@7e200000/mii_gpio36";
+ pcm_gpio50 = "/soc/gpio@7e200000/pcm_gpio50";
+ pwm0_gpio52 = "/soc/gpio@7e200000/pwm0_gpio52";
+ pwm1_gpio53 = "/soc/gpio@7e200000/pwm1_gpio53";
+ rgmii_gpio35 = "/soc/gpio@7e200000/rgmii_gpio35";
+ rgmii_irq_gpio34 = "/soc/gpio@7e200000/rgmii_irq_gpio34";
+ rgmii_irq_gpio39 = "/soc/gpio@7e200000/rgmii_irq_gpio39";
+ rgmii_mdio_gpio28 = "/soc/gpio@7e200000/rgmii_mdio_gpio28";
+ rgmii_mdio_gpio37 = "/soc/gpio@7e200000/rgmii_mdio_gpio37";
+ spi0_gpio46 = "/soc/gpio@7e200000/spi0_gpio46";
+ spi2_gpio46 = "/soc/gpio@7e200000/spi2_gpio46";
+ spi3_gpio0 = "/soc/gpio@7e200000/spi3_gpio0";
+ spi4_gpio4 = "/soc/gpio@7e200000/spi4_gpio4";
+ spi5_gpio12 = "/soc/gpio@7e200000/spi5_gpio12";
+ spi6_gpio18 = "/soc/gpio@7e200000/spi6_gpio18";
+ uart2_gpio0 = "/soc/gpio@7e200000/uart2_gpio0";
+ uart2_ctsrts_gpio2 = "/soc/gpio@7e200000/uart2_ctsrts_gpio2";
+ uart3_gpio4 = "/soc/gpio@7e200000/uart3_gpio4";
+ uart3_ctsrts_gpio6 = "/soc/gpio@7e200000/uart3_ctsrts_gpio6";
+ uart4_gpio8 = "/soc/gpio@7e200000/uart4_gpio8";
+ uart4_ctsrts_gpio10 = "/soc/gpio@7e200000/uart4_ctsrts_gpio10";
+ uart5_gpio12 = "/soc/gpio@7e200000/uart5_gpio12";
+ uart5_ctsrts_gpio14 = "/soc/gpio@7e200000/uart5_ctsrts_gpio14";
+ dpi_18bit_gpio0 = "/soc/gpio@7e200000/dpi_18bit_gpio0";
+ spi0_pins = "/soc/gpio@7e200000/spi0_pins";
+ spi0_cs_pins = "/soc/gpio@7e200000/spi0_cs_pins";
+ spi3_pins = "/soc/gpio@7e200000/spi3_pins";
+ spi3_cs_pins = "/soc/gpio@7e200000/spi3_cs_pins";
+ spi4_pins = "/soc/gpio@7e200000/spi4_pins";
+ spi4_cs_pins = "/soc/gpio@7e200000/spi4_cs_pins";
+ spi5_pins = "/soc/gpio@7e200000/spi5_pins";
+ spi5_cs_pins = "/soc/gpio@7e200000/spi5_cs_pins";
+ spi6_pins = "/soc/gpio@7e200000/spi6_pins";
+ spi6_cs_pins = "/soc/gpio@7e200000/spi6_cs_pins";
+ i2c0_pins = "/soc/gpio@7e200000/i2c0";
+ i2c1_pins = "/soc/gpio@7e200000/i2c1";
+ i2c3_pins = "/soc/gpio@7e200000/i2c3";
+ i2c4_pins = "/soc/gpio@7e200000/i2c4";
+ i2c5_pins = "/soc/gpio@7e200000/i2c5";
+ i2c6_pins = "/soc/gpio@7e200000/i2c6";
+ i2s_pins = "/soc/gpio@7e200000/i2s";
+ sdio_pins = "/soc/gpio@7e200000/sdio_pins";
+ bt_pins = "/soc/gpio@7e200000/bt_pins";
+ uart0_pins = "/soc/gpio@7e200000/uart0_pins";
+ uart1_pins = "/soc/gpio@7e200000/uart1_pins";
+ uart2_pins = "/soc/gpio@7e200000/uart2_pins";
+ uart3_pins = "/soc/gpio@7e200000/uart3_pins";
+ uart4_pins = "/soc/gpio@7e200000/uart4_pins";
+ uart5_pins = "/soc/gpio@7e200000/uart5_pins";
+ audio_pins = "/soc/gpio@7e200000/audio_pins";
+ uart0 = "/soc/serial@7e201000";
+ sdhost = "/soc/mmc@7e202000";
+ i2s = "/soc/i2s@7e203000";
+ spi0 = "/soc/spi@7e204000";
+ spi = "/soc/spi@7e204000";
+ spidev0 = "/soc/spi@7e204000/spidev@0";
+ spidev1 = "/soc/spi@7e204000/spidev@1";
+ i2c0 = "/soc/i2c@7e205000";
+ pixelvalve0 = "/soc/pixelvalve@7e206000";
+ pixelvalve1 = "/soc/pixelvalve@7e207000";
+ dpi = "/soc/dpi@7e208000";
+ dsi0 = "/soc/dsi@7e209000";
+ aux = "/soc/aux@7e215000";
+ uart1 = "/soc/serial@7e215040";
+ spi1 = "/soc/spi@7e215080";
+ spi2 = "/soc/spi@7e2150c0";
+ pwm = "/soc/pwm@7e20c000";
+ hvs = "/soc/hvs@7e400000";
+ dsi1 = "/soc/dsi@7e700000";
+ csi0 = "/soc/csi@7e800000";
+ csi1 = "/soc/csi@7e801000";
+ i2c1 = "/soc/i2c@7e804000";
+ i2c2 = "/soc/i2c@7e805000";
+ vec = "/soc/vec@7e806000";
+ pixelvalve2 = "/soc/pixelvalve@7e807000";
+ hdmi = "/soc/hdmi@7e902000";
+ usb = "/soc/usb@7e980000";
+ vc4 = "/soc/gpu";
+ local_intc = "/soc/local_intc@40000000";
+ gicv2 = "/soc/gic400@40041000";
+ thermal = "/soc/thermal@7d5d2200";
+ uart2 = "/soc/serial@7e201400";
+ uart3 = "/soc/serial@7e201600";
+ uart4 = "/soc/serial@7e201800";
+ uart5 = "/soc/serial@7e201a00";
+ spi3 = "/soc/spi@7e204600";
+ spi4 = "/soc/spi@7e204800";
+ spi5 = "/soc/spi@7e204a00";
+ spi6 = "/soc/spi@7e204c00";
+ i2c3 = "/soc/i2c@7e205600";
+ i2c4 = "/soc/i2c@7e205800";
+ i2c5 = "/soc/i2c@7e205a00";
+ i2c6 = "/soc/i2c@7e205c00";
+ emmc2 = "/soc/emmc2@7e340000";
+ mmc = "/soc/mmc@7e300000";
+ mmcnr = "/soc/mmcnr@7e300000";
+ firmwarekms = "/soc/firmwarekms@7e600000";
+ smi = "/soc/smi@7e600000";
+ axiperf = "/soc/axiperf";
+ firmware = "/soc/firmware";
+ expgpio = "/soc/firmware/expgpio";
+ power = "/soc/power";
+ fb = "/soc/fb";
+ vcsm = "/soc/vcsm";
+ audio = "/soc/audio";
+ sound = "/soc/sound";
+ virtgpio = "/soc/virtgpio";
+ clk_osc = "/clocks/clock@3";
+ clk_usb = "/clocks/clock@4";
+ usbphy = "/phy";
+ cpus = "/cpus";
+ cpu0 = "/cpus/cpu@0";
+ cpu1 = "/cpus/cpu@1";
+ cpu2 = "/cpus/cpu@2";
+ cpu3 = "/cpus/cpu@3";
+ v3d = "/v3dbus/v3d@7ec04000";
+ scb = "/scb";
+ pcie_0 = "/scb/pcie@7d500000";
+ genet = "/scb/genet@7d580000";
+ phy1 = "/scb/genet@7d580000/mdio@e14/genet-phy@0";
+ dma40 = "/scb/dma@7e007b00";
+ xhci = "/scb/xhci@7e9c0000";
+ vchiq = "/scb/mailbox@7e00b840";
+ vdd_5v0_reg = "/fixedregulator_5v0";
+ vdd_3v3_reg = "/fixedregulator_3v3";
+ leds = "/leds";
+ act_led = "/leds/act";
+ pwr_led = "/leds/pwr";
+ sd_io_1v8_reg = "/sd_io_1v8_reg";
+ };
+};
diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
index 88f7504a60f..0d534b8a28d 100644
--- a/configs/rpi_4_32b_defconfig
+++ b/configs/rpi_4_32b_defconfig
@@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x00008000
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_TARGET_RPI_4_32B=y
CONFIG_ENV_SIZE=0x4000
+CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b"
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0x1000000
CONFIG_OF_BOARD_SETUP=y
diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
index 59a71031540..0b3cadaced2 100644
--- a/configs/rpi_4_defconfig
+++ b/configs/rpi_4_defconfig
@@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x00080000
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_TARGET_RPI_4=y
CONFIG_ENV_SIZE=0x4000
+CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b"
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0x1000000
CONFIG_OF_BOARD_SETUP=y
diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index 67dbf094ef7..07f67394ac2 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -6,6 +6,7 @@ CONFIG_TARGET_RPI_ARM64=y
CONFIG_ENV_SIZE=0x4000
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0x1000000
+CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b"
CONFIG_OF_BOARD_SETUP=y
CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="pci enum; usb start;"
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* Re: [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4
2021-12-02 15:59 ` [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4 Simon Glass
@ 2021-12-02 17:34 ` Mark Kettenis
2021-12-02 18:20 ` François Ozog
2021-12-02 18:25 ` Simon Glass
0 siblings, 2 replies; 136+ messages in thread
From: Mark Kettenis @ 2021-12-02 17:34 UTC (permalink / raw)
To: Simon Glass
Cc: u-boot, seanga2, ilias.apalodimas, trini, francois.ozog,
xypron.glpk, sjg, albert.u.boot, mbrugger, swarren, swarren
> From: Simon Glass <sjg@chromium.org>
> Date: Thu, 2 Dec 2021 08:59:01 -0700
>
> Add this file, obtained from the Raspbian boot disk, so there is a
> reference devicetree in the U-Boot tree. The same one is used for
> 32- and 64-bit variants.
>
> Note that U-Boot does not normally need this at runtime, since
> CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
> devicetree at runtime.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> (no changes since v1)
>
> arch/arm/dts/Makefile | 3 +-
> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++++++++
> configs/rpi_4_32b_defconfig | 1 +
> configs/rpi_4_defconfig | 1 +
> configs/rpi_arm64_defconfig | 1 +
> 5 files changed, 1963 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 2d92b2f940d..9cddab37207 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1077,7 +1077,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> bcm2837-rpi-3-a-plus.dtb \
> bcm2837-rpi-3-b.dtb \
> bcm2837-rpi-3-b-plus.dtb \
> - bcm2837-rpi-cm3-io3.dtb
> + bcm2837-rpi-cm3-io3.dtb \
> + bcm2711-rpi-4-b.dtb
>
> dtb-$(CONFIG_ARCH_BCM63158) += \
> bcm963158.dtb
> diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts b/arch/arm/dts/bcm2711-rpi-4-b.dts
> new file mode 100644
> index 00000000000..425e9fb91c4
> --- /dev/null
> +++ b/arch/arm/dts/bcm2711-rpi-4-b.dts
> @@ -0,0 +1,1958 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +/*
> + * Sample device tree for rpi_4
> +
> + * Copyright 2021 Google LLC
> + */
This is of course an utter lie. This wasn't written from scratch by a
Google employee.
The original copyright and license for the dtb files you
"disassembled" applies. You don't specify exactly where you obtained
the file from, but it probably came from here:
https://github.com/raspberrypi/firmware
And the README.md for that repo states that:
"The dtbs, overlays and associated README are built from Linux
kernel sources, released under the GPL (see boot/COPYING.linux)"
They're probably talking about their own fork of the Linux kernel
sources here as there are still differences between their device trees
and the the device trees in the official Linux tree. But if you
insist on having a device tree in the U-Boot tree, that's where you
should look.
> +
> +/dts-v1/;
> +
> +/memreserve/ 0x0000000000000000 0x0000000000001000;
> +/ {
> + compatible = "raspberrypi,4-model-b\0brcm,bcm2838\0brcm,bcm2837";
> + model = "Raspberry Pi 4 Model B";
> + interrupt-parent = <0x01>;
> + #address-cells = <0x02>;
> + #size-cells = <0x01>;
> +
> + aliases {
> + serial0 = "/soc/serial@7e215040";
> + serial1 = "/soc/serial@7e201000";
> + audio = "/soc/audio";
> + aux = "/soc/aux@7e215000";
> + sound = "/soc/sound";
> + soc = "/soc";
> + dma = "/soc/dma@7e007000";
> + watchdog = "/soc/watchdog@7e100000";
> + random = "/soc/rng@7e104000";
> + mailbox = "/soc/mailbox@7e00b880";
> + gpio = "/soc/gpio@7e200000";
> + uart0 = "/soc/serial@7e201000";
> + sdhost = "/soc/mmc@7e202000";
> + mmc0 = "/soc/emmc2@7e340000";
> + i2s = "/soc/i2s@7e203000";
> + spi0 = "/soc/spi@7e204000";
> + i2c0 = "/soc/i2c@7e205000";
> + uart1 = "/soc/serial@7e215040";
> + spi1 = "/soc/spi@7e215080";
> + spi2 = "/soc/spi@7e2150c0";
> + mmc = "/soc/mmc@7e300000";
> + mmc1 = "/soc/mmcnr@7e300000";
> + i2c1 = "/soc/i2c@7e804000";
> + i2c2 = "/soc/i2c@7e805000";
> + usb = "/soc/usb@7e980000";
> + leds = "/leds";
> + fb = "/soc/fb";
> + thermal = "/soc/thermal@7d5d2200";
> + axiperf = "/soc/axiperf";
> + mmc2 = "/soc/mmc@7e202000";
> + ethernet0 = "/scb/genet@7d580000";
> + };
> +
> + chosen {
> + bootargs = "8250.nr_uarts=1 cma=64M";
> + };
> +
> + thermal-zones {
> +
> + cpu-thermal {
> + polling-delay-passive = <0x00>;
> + polling-delay = <0x3e8>;
> + thermal-sensors = <0x02>;
> + coefficients = <0xfffffe19 0x641b8>;
> + phandle = <0x2f>;
> +
> + cooling-maps {
> + };
> + };
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <0x01>;
> + #size-cells = <0x01>;
> + ranges = <0x7e000000 0x00 0xfe000000 0x1800000
> + 0x7c000000 0x00 0xfc000000 0x2000000
> + 0x40000000 0x00 0xff800000 0x800000>;
> + dma-ranges = <0xc0000000 0x00 0x00 0x3c000000>;
> + phandle = <0x30>;
> +
> + txp@7e004000 {
> + compatible = "brcm,bcm2835-txp";
> + reg = <0x7e004000 0x20>;
> + interrupts = <0x00 0x4b 0x04>;
> + status = "disabled";
> + phandle = <0x31>;
> + };
> +
> + dma@7e007000 {
> + compatible = "brcm,bcm2835-dma";
> + reg = <0x7e007000 0xb00>;
> + interrupts = <0x00 0x50 0x04 0x00 0x51 0x04 0x00 0x52
> + 0x04 0x00 0x53 0x04 0x00 0x54 0x04 0x00
> + 0x55 0x04 0x00 0x56 0x04 0x00 0x57 0x04
> + 0x00 0x57 0x04 0x00 0x58 0x04 0x00 0x58
> + 0x04>;
> + interrupt-names = "dma0\0dma1\0dma2\0dma3\0dma4\0dma5\0dma6\0dma7\0dma8\0dma9\0dma10";
> + #dma-cells = <0x01>;
> + brcm,dma-channel-mask = <0x7ef5>;
> + phandle = <0x0a>;
> + };
> +
> + watchdog@7e100000 {
> + compatible = "brcm,bcm2835-pm\0brcm,bcm2835-pm-wdt";
> + #power-domain-cells = <0x01>;
> + #reset-cells = <0x01>;
> + reg = <0x7e100000 0x114 0x7e00a000 0x24 0x7ec11000 0x20>;
> + clocks = <0x03 0x15 0x03 0x1d 0x03 0x17 0x03 0x16>;
> + clock-names = "v3d\0peri_image\0h264\0isp";
> + system-power-controller;
> + phandle = <0x1c>;
> + };
> +
> + cprman@7e101000 {
> + compatible = "brcm,bcm2838-cprman";
> + #clock-cells = <0x01>;
> + reg = <0x7e101000 0x2000>;
> + clocks = <0x04 0x05 0x00 0x05 0x01 0x05 0x02 0x06
> + 0x00 0x06 0x01 0x06 0x02>;
> + firmware = <0x07>;
> + phandle = <0x03>;
> + };
> +
> + rng@7e104000 {
> + compatible = "brcm,bcm2838-rng200";
> + reg = <0x7e104000 0x10>;
> + interrupts = <0x00 0x7d 0x04>;
> + phandle = <0x26>;
> + };
> +
> + mailbox@7e00b880 {
> + compatible = "brcm,bcm2835-mbox";
> + reg = <0x7e00b880 0x40>;
> + interrupts = <0x00 0x21 0x04>;
> + #mbox-cells = <0x00>;
> + phandle = <0x1a>;
> + };
> +
> + gpio: gpio@7e200000 {
> + compatible = "brcm,bcm2835-gpio";
> + reg = <0x7e200000 0xb4>;
> + interrupts = <0x00 0x71 0x04 0x00 0x72 0x04>;
> + gpio-controller;
> + #gpio-cells = <0x02>;
> + interrupt-controller;
> + #interrupt-cells = <0x02>;
> + phandle = <0x0f>;
> +
> + dpi_gpio0 {
> + brcm,pins = <0x00 0x01 0x02 0x03 0x04
> + 0x05 0x06 0x07 0x08 0x09
> + 0x0a 0x0b 0x0c 0x0d 0x0e
> + 0x0f 0x10 0x11 0x12 0x13
> + 0x14 0x15 0x16 0x17 0x18
> + 0x19 0x1a 0x1b>;
> + brcm,function = <0x06>;
> + phandle = <0x32>;
> + };
> +
> + emmc_gpio22 {
> + brcm,pins = <0x16 0x17 0x18 0x19 0x1a 0x1b>;
> + brcm,function = <0x07>;
> + phandle = <0x33>;
> + };
> +
> + emmc_gpio34 {
> + brcm,pins = <0x22 0x23 0x24 0x25 0x26 0x27>;
> + brcm,function = <0x07>;
> + brcm,pull = <0x00 0x02 0x02 0x02 0x02 0x02>;
> + phandle = <0x34>;
> + };
> +
> + emmc_gpio48 {
> + brcm,pins = <0x30 0x31 0x32 0x33 0x34 0x35>;
> + brcm,function = <0x07>;
> + phandle = <0x35>;
> + };
> +
> + gpclk0_gpio4 {
> + brcm,pins = <0x04>;
> + brcm,function = <0x04>;
> + phandle = <0x36>;
> + };
> +
> + gpclk1_gpio5 {
> + brcm,pins = <0x05>;
> + brcm,function = <0x04>;
> + phandle = <0x37>;
> + };
> +
> + gpclk1_gpio42 {
> + brcm,pins = <0x2a>;
> + brcm,function = <0x04>;
> + phandle = <0x38>;
> + };
> +
> + gpclk1_gpio44 {
> + brcm,pins = <0x2c>;
> + brcm,function = <0x04>;
> + phandle = <0x39>;
> + };
> +
> + gpclk2_gpio6 {
> + brcm,pins = <0x06>;
> + brcm,function = <0x04>;
> + phandle = <0x3a>;
> + };
> +
> + gpclk2_gpio43 {
> + brcm,pins = <0x2b>;
> + brcm,function = <0x04>;
> + brcm,pull = <0x00>;
> + phandle = <0x3b>;
> + };
> +
> + i2c0_gpio0 {
> + brcm,pins = <0x00 0x01>;
> + brcm,function = <0x04>;
> + phandle = <0x3c>;
> + };
> +
> + i2c0_gpio28 {
> + brcm,pins = <0x1c 0x1d>;
> + brcm,function = <0x04>;
> + phandle = <0x3d>;
> + };
> +
> + i2c0_gpio44 {
> + brcm,pins = <0x2c 0x2d>;
> + brcm,function = <0x05>;
> + phandle = <0x3e>;
> + };
> +
> + i2c1_gpio2 {
> + brcm,pins = <0x02 0x03>;
> + brcm,function = <0x04>;
> + phandle = <0x3f>;
> + };
> +
> + i2c1_gpio44 {
> + brcm,pins = <0x2c 0x2d>;
> + brcm,function = <0x06>;
> + phandle = <0x40>;
> + };
> +
> + jtag_gpio22 {
> + brcm,pins = <0x16 0x17 0x18 0x19 0x1a 0x1b>;
> + brcm,function = <0x03>;
> + phandle = <0x41>;
> + };
> +
> + pcm_gpio18 {
> + brcm,pins = <0x12 0x13 0x14 0x15>;
> + brcm,function = <0x04>;
> + phandle = <0x42>;
> + };
> +
> + pcm_gpio28 {
> + brcm,pins = <0x1c 0x1d 0x1e 0x1f>;
> + brcm,function = <0x06>;
> + phandle = <0x43>;
> + };
> +
> + pwm0_gpio12 {
> + brcm,pins = <0x0c>;
> + brcm,function = <0x04>;
> + phandle = <0x44>;
> + };
> +
> + pwm0_gpio18 {
> + brcm,pins = <0x12>;
> + brcm,function = <0x02>;
> + phandle = <0x45>;
> + };
> +
> + pwm0_gpio40 {
> + brcm,pins = <0x28>;
> + brcm,function = <0x04>;
> + phandle = <0x46>;
> + };
> +
> + pwm1_gpio13 {
> + brcm,pins = <0x0d>;
> + brcm,function = <0x04>;
> + phandle = <0x47>;
> + };
> +
> + pwm1_gpio19 {
> + brcm,pins = <0x13>;
> + brcm,function = <0x02>;
> + phandle = <0x48>;
> + };
> +
> + pwm1_gpio41 {
> + brcm,pins = <0x29>;
> + brcm,function = <0x04>;
> + phandle = <0x49>;
> + };
> +
> + pwm1_gpio45 {
> + brcm,pins = <0x2d>;
> + brcm,function = <0x04>;
> + phandle = <0x4a>;
> + };
> +
> + sdhost_gpio48 {
> + brcm,pins = <0x16 0x17 0x18 0x19 0x1a 0x1b>;
> + brcm,function = <0x04>;
> + phandle = <0x0b>;
> + };
> +
> + spi0_gpio7 {
> + brcm,pins = <0x07 0x08 0x09 0x0a 0x0b>;
> + brcm,function = <0x04>;
> + phandle = <0x4b>;
> + };
> +
> + spi0_gpio35 {
> + brcm,pins = <0x23 0x24 0x25 0x26 0x27>;
> + brcm,function = <0x04>;
> + phandle = <0x4c>;
> + };
> +
> + spi1_gpio16 {
> + brcm,pins = <0x10 0x11 0x12 0x13 0x14 0x15>;
> + brcm,function = <0x03>;
> + phandle = <0x4d>;
> + };
> +
> + spi2_gpio40 {
> + brcm,pins = <0x28 0x29 0x2a 0x2b 0x2c 0x2d>;
> + brcm,function = <0x03>;
> + phandle = <0x4e>;
> + };
> +
> + uart0_gpio14: uart0_gpio14 {
> + brcm,pins = <0x0e 0x0f>;
> + brcm,function = <0x04>;
> + phandle = <0x4f>;
> + };
> +
> + uart0: uart0_ctsrts_gpio16 {
> + brcm,pins = <0x10 0x11>;
> + brcm,function = <0x07>;
> + phandle = <0x50>;
> + };
> +
> + uart0_ctsrts_gpio30 {
> + brcm,pins = <0x1e 0x1f>;
> + brcm,function = <0x07>;
> + brcm,pull = <0x02 0x00>;
> + phandle = <0x51>;
> + };
> +
> + uart0_gpio32 {
> + brcm,pins = <0x20 0x21>;
> + brcm,function = <0x07>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x52>;
> + };
> +
> + uart0_gpio36 {
> + brcm,pins = <0x24 0x25>;
> + brcm,function = <0x06>;
> + phandle = <0x53>;
> + };
> +
> + uart0_ctsrts_gpio38 {
> + brcm,pins = <0x26 0x27>;
> + brcm,function = <0x06>;
> + phandle = <0x54>;
> + };
> +
> + uart1_gpio14: uart1_gpio14 {
> + brcm,pins = <0x0e 0x0f>;
> + brcm,function = <0x02>;
> + phandle = <0x55>;
> + };
> +
> + uart1: uart1_ctsrts_gpio16 {
> + brcm,pins = <0x10 0x11>;
> + brcm,function = <0x02>;
> + phandle = <0x56>;
> + };
> +
> + uart1_gpio32 {
> + brcm,pins = <0x20 0x21>;
> + brcm,function = <0x02>;
> + phandle = <0x57>;
> + };
> +
> + uart1_ctsrts_gpio30 {
> + brcm,pins = <0x1e 0x1f>;
> + brcm,function = <0x02>;
> + phandle = <0x58>;
> + };
> +
> + uart1_gpio40 {
> + brcm,pins = <0x28 0x29>;
> + brcm,function = <0x02>;
> + phandle = <0x59>;
> + };
> +
> + uart1_ctsrts_gpio42 {
> + brcm,pins = <0x2a 0x2b>;
> + brcm,function = <0x02>;
> + phandle = <0x5a>;
> + };
> +
> + gpclk0_gpio49 {
> + brcm,pins = <0x31>;
> + brcm,function = <0x05>;
> + brcm,pull = <0x00>;
> + phandle = <0x5b>;
> + };
> +
> + gpclk1_gpio50 {
> + brcm,pins = <0x32>;
> + brcm,function = <0x05>;
> + brcm,pull = <0x00>;
> + phandle = <0x5c>;
> + };
> +
> + gpclk2_gpio51 {
> + brcm,pins = <0x33>;
> + brcm,function = <0x05>;
> + brcm,pull = <0x00>;
> + phandle = <0x5d>;
> + };
> +
> + i2c0_gpio46 {
> + brcm,pins = <0x2e 0x2f>;
> + brcm,function = <0x04>;
> + phandle = <0x5e>;
> + };
> +
> + i2c1_gpio46 {
> + brcm,pins = <0x2e 0x2f>;
> + brcm,function = <0x05>;
> + phandle = <0x5f>;
> + };
> +
> + i2c3_gpio2 {
> + brcm,pins = <0x02 0x03>;
> + brcm,function = <0x02>;
> + phandle = <0x60>;
> + };
> +
> + i2c3_gpio4 {
> + brcm,pins = <0x04 0x05>;
> + brcm,function = <0x02>;
> + phandle = <0x61>;
> + };
> +
> + i2c4_gpio6 {
> + brcm,pins = <0x06 0x07>;
> + brcm,function = <0x02>;
> + phandle = <0x62>;
> + };
> +
> + i2c4_gpio8 {
> + brcm,pins = <0x08 0x09>;
> + brcm,function = <0x02>;
> + phandle = <0x63>;
> + };
> +
> + i2c5_gpio10 {
> + brcm,pins = <0x0a 0x0b>;
> + brcm,function = <0x02>;
> + phandle = <0x64>;
> + };
> +
> + i2c5_gpio12 {
> + brcm,pins = <0x0c 0x0d>;
> + brcm,function = <0x02>;
> + phandle = <0x65>;
> + };
> +
> + i2c6_gpio0 {
> + brcm,pins = <0x00 0x01>;
> + brcm,function = <0x02>;
> + phandle = <0x66>;
> + };
> +
> + i2c6_gpio22 {
> + brcm,pins = <0x16 0x17>;
> + brcm,function = <0x02>;
> + phandle = <0x67>;
> + };
> +
> + i2c_slave_gpio8 {
> + brcm,pins = <0x08 0x09 0x0a 0x0b>;
> + brcm,function = <0x07>;
> + phandle = <0x68>;
> + };
> +
> + jtag_gpio48 {
> + brcm,pins = <0x30 0x31 0x32 0x33 0x34 0x35>;
> + brcm,function = <0x03>;
> + phandle = <0x69>;
> + };
> +
> + mii_gpio28 {
> + brcm,pins = <0x1c 0x1d 0x1e 0x1f>;
> + brcm,function = <0x03>;
> + phandle = <0x6a>;
> + };
> +
> + mii_gpio36 {
> + brcm,pins = <0x24 0x25 0x26 0x27>;
> + brcm,function = <0x02>;
> + phandle = <0x6b>;
> + };
> +
> + pcm_gpio50 {
> + brcm,pins = <0x32 0x33 0x34 0x35>;
> + brcm,function = <0x06>;
> + phandle = <0x6c>;
> + };
> +
> + pwm0_gpio52 {
> + brcm,pins = <0x34>;
> + brcm,function = <0x05>;
> + brcm,pull = <0x00>;
> + phandle = <0x6d>;
> + };
> +
> + pwm1_gpio53 {
> + brcm,pins = <0x35>;
> + brcm,function = <0x05>;
> + brcm,pull = <0x00>;
> + phandle = <0x6e>;
> + };
> +
> + rgmii_gpio35 {
> + brcm,pins = <0x23 0x24>;
> + brcm,function = <0x03>;
> + phandle = <0x6f>;
> + };
> +
> + rgmii_irq_gpio34 {
> + brcm,pins = <0x22>;
> + brcm,function = <0x02>;
> + phandle = <0x70>;
> + };
> +
> + rgmii_irq_gpio39 {
> + brcm,pins = <0x27>;
> + brcm,function = <0x03>;
> + phandle = <0x71>;
> + };
> +
> + rgmii_mdio_gpio28 {
> + brcm,pins = <0x1c 0x1d>;
> + brcm,function = <0x02>;
> + phandle = <0x72>;
> + };
> +
> + rgmii_mdio_gpio37 {
> + brcm,pins = <0x25 0x26>;
> + brcm,function = <0x03>;
> + phandle = <0x73>;
> + };
> +
> + spi0_gpio46 {
> + brcm,pins = <0x2e 0x2f 0x30 0x31>;
> + brcm,function = <0x06>;
> + phandle = <0x74>;
> + };
> +
> + spi2_gpio46 {
> + brcm,pins = <0x2e 0x2f 0x30 0x31 0x32>;
> + brcm,function = <0x02>;
> + phandle = <0x75>;
> + };
> +
> + spi3_gpio0 {
> + brcm,pins = <0x00 0x01 0x02 0x03>;
> + brcm,function = <0x07>;
> + phandle = <0x76>;
> + };
> +
> + spi4_gpio4 {
> + brcm,pins = <0x04 0x05 0x06 0x07>;
> + brcm,function = <0x07>;
> + phandle = <0x77>;
> + };
> +
> + spi5_gpio12 {
> + brcm,pins = <0x0c 0x0d 0x0e 0x0f>;
> + brcm,function = <0x07>;
> + phandle = <0x78>;
> + };
> +
> + spi6_gpio18 {
> + brcm,pins = <0x12 0x13 0x14 0x15>;
> + brcm,function = <0x07>;
> + phandle = <0x79>;
> + };
> +
> + uart2_gpio0 {
> + brcm,pins = <0x00 0x01>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x7a>;
> + };
> +
> + uart2_ctsrts_gpio2 {
> + brcm,pins = <0x02 0x03>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x02 0x00>;
> + phandle = <0x7b>;
> + };
> +
> + uart3_gpio4 {
> + brcm,pins = <0x04 0x05>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x7c>;
> + };
> +
> + uart3_ctsrts_gpio6 {
> + brcm,pins = <0x06 0x07>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x02 0x00>;
> + phandle = <0x7d>;
> + };
> +
> + uart4_gpio8 {
> + brcm,pins = <0x08 0x09>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x7e>;
> + };
> +
> + uart4_ctsrts_gpio10 {
> + brcm,pins = <0x0a 0x0b>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x02 0x00>;
> + phandle = <0x7f>;
> + };
> +
> + uart5_gpio12 {
> + brcm,pins = <0x0c 0x0d>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x80>;
> + };
> +
> + uart5_ctsrts_gpio14 {
> + brcm,pins = <0x0e 0x0f>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x02 0x00>;
> + phandle = <0x81>;
> + };
> +
> + dpi_18bit_gpio0 {
> + brcm,pins = <0x00 0x01 0x02 0x03
> + 0x04 0x05 0x06 0x07
> + 0x08 0x09 0x0a 0x0b
> + 0x0c 0x0d 0x0e 0x0f
> + 0x10 0x11 0x12 0x13
> + 0x14 0x15>;
> + brcm,function = <0x06>;
> + phandle = <0x82>;
> + };
> +
> + spi0_pins {
> + brcm,pins = <0x09 0x0a 0x0b>;
> + brcm,function = <0x04>;
> + phandle = <0x0d>;
> + };
> +
> + spi0_cs_pins {
> + brcm,pins = <0x08 0x07>;
> + brcm,function = <0x01>;
> + phandle = <0x0e>;
> + };
> +
> + spi3_pins {
> + brcm,pins = <0x01 0x02 0x03>;
> + brcm,function = <0x07>;
> + phandle = <0x83>;
> + };
> +
> + spi3_cs_pins {
> + brcm,pins = <0x00 0x18>;
> + brcm,function = <0x01>;
> + phandle = <0x84>;
> + };
> +
> + spi4_pins {
> + brcm,pins = <0x05 0x06 0x07>;
> + brcm,function = <0x07>;
> + phandle = <0x85>;
> + };
> +
> + spi4_cs_pins {
> + brcm,pins = <0x04 0x19>;
> + brcm,function = <0x01>;
> + phandle = <0x86>;
> + };
> +
> + spi5_pins {
> + brcm,pins = <0x0d 0x0e 0x0f>;
> + brcm,function = <0x07>;
> + phandle = <0x87>;
> + };
> +
> + spi5_cs_pins {
> + brcm,pins = <0x0c 0x1a>;
> + brcm,function = <0x01>;
> + phandle = <0x88>;
> + };
> +
> + spi6_pins {
> + brcm,pins = <0x13 0x14 0x15>;
> + brcm,function = <0x07>;
> + phandle = <0x89>;
> + };
> +
> + spi6_cs_pins {
> + brcm,pins = <0x12 0x1b>;
> + brcm,function = <0x01>;
> + phandle = <0x8a>;
> + };
> +
> + i2c0 {
> + brcm,pins = <0x00 0x01>;
> + brcm,function = <0x04>;
> + phandle = <0x10>;
> + };
> +
> + i2c1 {
> + brcm,pins = <0x02 0x03>;
> + brcm,function = <0x04>;
> + phandle = <0x14>;
> + };
> +
> + i2c3 {
> + brcm,pins = <0x04 0x05>;
> + brcm,function = <0x02>;
> + phandle = <0x8b>;
> + };
> +
> + i2c4 {
> + brcm,pins = <0x08 0x09>;
> + brcm,function = <0x02>;
> + phandle = <0x8c>;
> + };
> +
> + i2c5 {
> + brcm,pins = <0x0c 0x0d>;
> + brcm,function = <0x02>;
> + phandle = <0x8d>;
> + };
> +
> + i2c6 {
> + brcm,pins = <0x16 0x17>;
> + brcm,function = <0x02>;
> + phandle = <0x8e>;
> + };
> +
> + i2s {
> + brcm,pins = <0x12 0x13 0x14 0x15>;
> + brcm,function = <0x04>;
> + phandle = <0x0c>;
> + };
> +
> + sdio_pins {
> + brcm,pins = <0x22 0x23 0x24 0x25 0x26 0x27>;
> + brcm,function = <0x07>;
> + brcm,pull = <0x00 0x02 0x02 0x02 0x02 0x02>;
> + phandle = <0x19>;
> + };
> +
> + bt_pins {
> + brcm,pins = [2d 00];
> + brcm,function = <0x00>;
> + brcm,pull = <0x02>;
> + phandle = <0x09>;
> + };
> +
> + uart0_pins {
> + brcm,pins = <0x20 0x21>;
> + brcm,function = <0x07>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x08>;
> + };
> +
> + uart1_pins {
> + brcm,pins;
> + brcm,function;
> + brcm,pull;
> + phandle = <0x12>;
> + };
> +
> + uart2_pins {
> + brcm,pins = <0x00 0x01>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x8f>;
> + };
> +
> + uart3_pins {
> + brcm,pins = <0x04 0x05>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x90>;
> + };
> +
> + uart4_pins {
> + brcm,pins = <0x08 0x09>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x91>;
> + };
> +
> + uart5_pins {
> + brcm,pins = <0x0c 0x0d>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x92>;
> + };
> +
> + audio_pins {
> + brcm,pins = <0x28 0x29>;
> + brcm,function = <0x04>;
> + phandle = <0x1b>;
> + };
> + };
> +
> + serial@7e201000 {
> + compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
> + reg = <0x7e201000 0x200>;
> + interrupts = <0x00 0x79 0x04>;
> + clocks = <0x03 0x13 0x03 0x14>;
> + clock-names = "uartclk\0apb_pclk";
> + arm,primecell-periphid = <0x241011>;
> + cts-event-workaround;
> + pinctrl-names = "default";
> + pinctrl-0 = <0x08 0x09>;
> + status = "okay";
> + phandle = <0x1f>;
> + };
> +
> + mmc@7e202000 {
> + compatible = "brcm,bcm2835-sdhost";
> + reg = <0x7e202000 0x100>;
> + interrupts = <0x00 0x78 0x04>;
> + clocks = <0x03 0x14>;
> + dmas = <0x0a 0x2000000d>;
> + dma-names = "rx-tx";
> + status = "disabled";
> + pinctrl-names = "default";
> + pinctrl-0 = <0x0b>;
> + bus-width = <0x04>;
> + brcm,overclock-50 = <0x00>;
> + brcm,pio-limit = <0x01>;
> + phandle = <0x27>;
> + };
> +
> + i2s@7e203000 {
> + compatible = "brcm,bcm2835-i2s";
> + reg = <0x7e203000 0x24>;
> + clocks = <0x03 0x1f>;
> + dmas = <0x0a 0x02 0x0a 0x03>;
> + dma-names = "tx\0rx";
> + status = "disabled";
> + #sound-dai-cells = <0x00>;
> + pinctrl-names = "default";
> + pinctrl-0 = <0x0c>;
> + phandle = <0x21>;
> + };
> +
> + spi@7e204000 {
> + compatible = "brcm,bcm2835-spi";
> + reg = <0x7e204000 0x200>;
> + interrupts = <0x00 0x76 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + dmas = <0x0a 0x06 0x0a 0x07>;
> + dma-names = "tx\0rx";
> + pinctrl-names = "default";
> + pinctrl-0 = <0x0d 0x0e>;
> + cs-gpios = <0x0f 0x08 0x01 0x0f 0x07 0x01>;
> + phandle = <0x22>;
> +
> + spidev@0 {
> + compatible = "spidev";
> + reg = <0x00>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + spi-max-frequency = <0x7735940>;
> + phandle = <0x93>;
> + };
> +
> + spidev@1 {
> + compatible = "spidev";
> + reg = <0x01>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + spi-max-frequency = <0x7735940>;
> + phandle = <0x94>;
> + };
> + };
> +
> + i2c@7e205000 {
> + compatible = "brcm,bcm2835-i2c";
> + reg = <0x7e205000 0x200>;
> + interrupts = <0x00 0x75 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + pinctrl-names = "default";
> + pinctrl-0 = <0x10>;
> + clock-frequency = <0x186a0>;
> + phandle = <0x23>;
> + };
> +
> + pixelvalve@7e206000 {
> + compatible = "brcm,bcm2835-pixelvalve0";
> + reg = <0x7e206000 0x100>;
> + interrupts = <0x00 0x6d 0x04>;
> + status = "disabled";
> + phandle = <0x95>;
> + };
> +
> + pixelvalve@7e207000 {
> + compatible = "brcm,bcm2835-pixelvalve1";
> + reg = <0x7e207000 0x100>;
> + interrupts = <0x00 0x6e 0x04>;
> + status = "disabled";
> + phandle = <0x96>;
> + };
> +
> + dpi@7e208000 {
> + compatible = "brcm,bcm2835-dpi";
> + reg = <0x7e208000 0x8c>;
> + clocks = <0x03 0x14 0x03 0x2c>;
> + clock-names = "core\0pixel";
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0x97>;
> + };
> +
> + dsi@7e209000 {
> + compatible = "brcm,bcm2835-dsi0";
> + reg = <0x7e209000 0x78>;
> + interrupts = <0x00 0x64 0x04>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + #clock-cells = <0x01>;
> + clocks = <0x03 0x20 0x03 0x2f 0x03 0x31>;
> + clock-names = "phy\0escape\0pixel";
> + clock-output-names = "dsi0_byte\0dsi0_ddr2\0dsi0_ddr";
> + phandle = <0x05>;
> + };
> +
> + aux@7e215000 {
> + compatible = "brcm,bcm2835-aux";
> + #clock-cells = <0x01>;
> + reg = <0x7e215000 0x08>;
> + clocks = <0x03 0x14>;
> + phandle = <0x11>;
> + };
> +
> + serial@7e215040 {
> + compatible = "brcm,bcm2835-aux-uart";
> + reg = <0x7e215040 0x40>;
> + interrupts = <0x00 0x5d 0x04>;
> + clocks = <0x11 0x00>;
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <0x12>;
> + phandle = <0x20>;
> + };
> +
> + spi@7e215080 {
> + compatible = "brcm,bcm2835-aux-spi";
> + reg = <0x7e215080 0x40>;
> + interrupts = <0x00 0x5d 0x04>;
> + clocks = <0x11 0x01>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0x98>;
> + };
> +
> + spi@7e2150c0 {
> + compatible = "brcm,bcm2835-aux-spi";
> + reg = <0x7e2150c0 0x40>;
> + interrupts = <0x00 0x5d 0x04>;
> + clocks = <0x11 0x02>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0x99>;
> + };
> +
> + pwm@7e20c000 {
> + compatible = "brcm,bcm2835-pwm";
> + reg = <0x7e20c000 0x28>;
> + clocks = <0x03 0x1e>;
> + assigned-clocks = <0x03 0x1e>;
> + assigned-clock-rates = <0x989680>;
> + #pwm-cells = <0x02>;
> + status = "disabled";
> + phandle = <0x9a>;
> + };
> +
> + hvs@7e400000 {
> + compatible = "brcm,bcm2835-hvs";
> + reg = <0x7e400000 0x6000>;
> + interrupts = <0x00 0x61 0x04>;
> + status = "disabled";
> + phandle = <0x9b>;
> + };
> +
> + dsi@7e700000 {
> + compatible = "brcm,bcm2835-dsi1";
> + reg = <0x7e700000 0x8c>;
> + interrupts = <0x00 0x6c 0x04>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + #clock-cells = <0x01>;
> + clocks = <0x03 0x23 0x03 0x30 0x03 0x32>;
> + clock-names = "phy\0escape\0pixel";
> + clock-output-names = "dsi1_byte\0dsi1_ddr2\0dsi1_ddr";
> + status = "disabled";
> + phandle = <0x06>;
> + };
> +
> + csi@7e800000 {
> + compatible = "brcm,bcm2835-unicam";
> + reg = <0x7e800000 0x800 0x7e802000 0x04>;
> + interrupts = <0x00 0x66 0x04>;
> + clocks = <0x03 0x2d>;
> + clock-names = "lp";
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + #clock-cells = <0x01>;
> + status = "disabled";
> + power-domains = <0x13 0x0c>;
> + phandle = <0x9c>;
> + };
> +
> + csi@7e801000 {
> + compatible = "brcm,bcm2835-unicam";
> + reg = <0x7e801000 0x800 0x7e802004 0x04>;
> + interrupts = <0x00 0x67 0x04>;
> + clocks = <0x03 0x2e>;
> + clock-names = "lp";
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + #clock-cells = <0x01>;
> + status = "disabled";
> + power-domains = <0x13 0x0d>;
> + phandle = <0x9d>;
> +
> + port {
> +
> + endpoint {
> + data-lanes = <0x01 0x02>;
> + };
> + };
> + };
> +
> + i2c@7e804000 {
> + compatible = "brcm,bcm2835-i2c";
> + reg = <0x7e804000 0x1000>;
> + interrupts = <0x00 0x75 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + pinctrl-names = "default";
> + pinctrl-0 = <0x14>;
> + clock-frequency = <0x186a0>;
> + phandle = <0x24>;
> + };
> +
> + i2c@7e805000 {
> + compatible = "brcm,bcm2835-i2c";
> + reg = <0x7e805000 0x1000>;
> + interrupts = <0x00 0x75 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + clock-frequency = <0x186a0>;
> + phandle = <0x15>;
> + };
> +
> + vec@7e806000 {
> + compatible = "brcm,bcm2835-vec";
> + reg = <0x7e806000 0x1000>;
> + clocks = <0x03 0x18>;
> + interrupts = <0x00 0x7b 0x04>;
> + status = "disabled";
> + phandle = <0x9e>;
> + };
> +
> + pixelvalve@7e807000 {
> + compatible = "brcm,bcm2835-pixelvalve2";
> + reg = <0x7e807000 0x100>;
> + interrupts = <0x00 0x6a 0x04>;
> + status = "disabled";
> + phandle = <0x9f>;
> + };
> +
> + hdmi@7e902000 {
> + compatible = "brcm,bcm2835-hdmi";
> + reg = <0x7e902000 0x600 0x7e808000 0x100>;
> + interrupts = <0x00 0x68 0x04 0x00 0x69 0x04>;
> + ddc = <0x15>;
> + clocks = <0x03 0x10 0x03 0x19>;
> + clock-names = "pixel\0hdmi";
> + dmas = <0x0a 0x11>;
> + dma-names = "audio-rx";
> + status = "disabled";
> + power-domains = <0x13 0x05>;
> + phandle = <0xa0>;
> + };
> +
> + usb@7e980000 {
> + compatible = "brcm,bcm2708-usb";
> + reg = <0x7e980000 0x10000 0x7e00b200 0x200>;
> + interrupts = <0x00 0x49 0x04 0x00 0x28 0x04>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + clocks = <0x16>;
> + clock-names = "otg";
> + phys = <0x17>;
> + phy-names = "usb2-phy";
> + interrupt-names = "usb\0soft";
> + power-domains = <0x13 0x06>;
> + phandle = <0xa1>;
> + };
> +
> + gpu {
> + compatible = "brcm,bcm2835-vc4";
> + status = "disabled";
> + phandle = <0xa2>;
> + };
> +
> + local_intc@40000000 {
> + compatible = "brcm,bcm2836-l1-intc";
> + reg = <0x40000000 0x100>;
> + phandle = <0xa3>;
> + };
> +
> + gic400@40041000 {
> + interrupt-controller;
> + #interrupt-cells = <0x03>;
> + compatible = "arm,gic-400";
> + reg = <0x40041000 0x1000 0x40042000 0x2000 0x40046000 0x2000 0x40048000 0x2000>;
> + phandle = <0x01>;
> + };
> +
> + thermal@7d5d2200 {
> + compatible = "brcm,avs-tmon-bcm2838";
> + reg = <0x7d5d2200 0x2c>;
> + interrupts = <0x00 0x89 0x04>;
> + interrupt-names = "tmon";
> + clocks = <0x03 0x1b>;
> + #thermal-sensor-cells = <0x00>;
> + status = "okay";
> + phandle = <0x02>;
> + };
> +
> + serial@7e201400 {
> + compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
> + reg = <0x7e201400 0x200>;
> + interrupts = <0x00 0x79 0x04>;
> + clocks = <0x03 0x13 0x03 0x14>;
> + clock-names = "uartclk\0apb_pclk";
> + arm,primecell-periphid = <0x241011>;
> + status = "disabled";
> + phandle = <0xa4>;
> + };
> +
> + serial@7e201600 {
> + compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
> + reg = <0x7e201600 0x200>;
> + interrupts = <0x00 0x79 0x04>;
> + clocks = <0x03 0x13 0x03 0x14>;
> + clock-names = "uartclk\0apb_pclk";
> + arm,primecell-periphid = <0x241011>;
> + status = "disabled";
> + phandle = <0xa5>;
> + };
> +
> + serial@7e201800 {
> + compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
> + reg = <0x7e201800 0x200>;
> + interrupts = <0x00 0x79 0x04>;
> + clocks = <0x03 0x13 0x03 0x14>;
> + clock-names = "uartclk\0apb_pclk";
> + arm,primecell-periphid = <0x241011>;
> + status = "disabled";
> + phandle = <0xa6>;
> + };
> +
> + serial@7e201a00 {
> + compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
> + reg = <0x7e201a00 0x200>;
> + interrupts = <0x00 0x79 0x04>;
> + clocks = <0x03 0x13 0x03 0x14>;
> + clock-names = "uartclk\0apb_pclk";
> + arm,primecell-periphid = <0x241011>;
> + status = "disabled";
> + phandle = <0xa7>;
> + };
> +
> + spi@7e204600 {
> + compatible = "brcm,bcm2835-spi";
> + reg = <0x7e204600 0x200>;
> + interrupts = <0x00 0x76 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xa8>;
> + };
> +
> + spi@7e204800 {
> + compatible = "brcm,bcm2835-spi";
> + reg = <0x7e204800 0x200>;
> + interrupts = <0x00 0x76 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xa9>;
> + };
> +
> + spi@7e204a00 {
> + compatible = "brcm,bcm2835-spi";
> + reg = <0x7e204a00 0x200>;
> + interrupts = <0x00 0x76 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xaa>;
> + };
> +
> + spi@7e204c00 {
> + compatible = "brcm,bcm2835-spi";
> + reg = <0x7e204c00 0x200>;
> + interrupts = <0x00 0x76 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xab>;
> + };
> +
> + i2c@7e205600 {
> + compatible = "brcm,bcm2835-i2c";
> + reg = <0x7e205600 0x200>;
> + interrupts = <0x00 0x75 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xac>;
> + };
> +
> + i2c@7e205800 {
> + compatible = "brcm,bcm2835-i2c";
> + reg = <0x7e205800 0x200>;
> + interrupts = <0x00 0x75 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xad>;
> + };
> +
> + i2c@7e205a00 {
> + compatible = "brcm,bcm2835-i2c";
> + reg = <0x7e205a00 0x200>;
> + interrupts = <0x00 0x75 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xae>;
> + };
> +
> + i2c@7e205c00 {
> + compatible = "brcm,bcm2835-i2c";
> + reg = <0x7e205c00 0x200>;
> + interrupts = <0x00 0x75 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xaf>;
> + };
> +
> + emmc2@7e340000 {
> + compatible = "brcm,bcm2711-emmc2";
> + status = "okay";
> + interrupts = <0x00 0x7e 0x04>;
> + clocks = <0x03 0x33>;
> + reg = <0x7e340000 0x100>;
> + broken-cd;
> + vqmmc-supply = <0x18>;
> + phandle = <0xb0>;
> + };
> +
> + mmc@7e300000 {
> + compatible = "brcm,bcm2835-mmc\0brcm,bcm2835-sdhci";
> + reg = <0x7e300000 0x100>;
> + interrupts = <0x00 0x7e 0x04>;
> + clocks = <0x03 0x1c>;
> + dmas = <0x0a 0x0b>;
> + dma-names = "rx-tx";
> + brcm,overclock-50 = <0x00>;
> + status = "disabled";
> + phandle = <0x28>;
> + };
> +
> + mmcnr@7e300000 {
> + compatible = "brcm,bcm2835-mmc\0brcm,bcm2835-sdhci";
> + reg = <0x7e300000 0x100>;
> + interrupts = <0x00 0x7e 0x04>;
> + clocks = <0x03 0x1c>;
> + dmas = <0x0a 0x0b>;
> + dma-names = "rx-tx";
> + brcm,overclock-50 = <0x00>;
> + non-removable;
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <0x19>;
> + bus-width = <0x04>;
> + phandle = <0x29>;
> + };
> +
> + firmwarekms@7e600000 {
> + compatible = "raspberrypi,rpi-firmware-kms";
> + reg = <0x7e600000 0x100>;
> + interrupts = <0x00 0x70 0x04>;
> + brcm,firmware = <0x07>;
> + status = "disabled";
> + phandle = <0xb1>;
> + };
> +
> + smi@7e600000 {
> + compatible = "brcm,bcm2835-smi";
> + reg = <0x7e600000 0x100>;
> + interrupts = <0x00 0x70 0x04>;
> + clocks = <0x03 0x2a>;
> + assigned-clocks = <0x03 0x2a>;
> + assigned-clock-rates = <0x7735940>;
> + dmas = <0x0a 0x04>;
> + dma-names = "rx-tx";
> + status = "disabled";
> + phandle = <0xb2>;
> + };
> +
> + axiperf {
> + compatible = "brcm,bcm2835-axiperf";
> + reg = <0x7e009800 0x100 0x7ee08000 0x100>;
> + firmware = <0x07>;
> + status = "disabled";
> + phandle = <0x2a>;
> + };
> +
> + gpiomem {
> + compatible = "brcm,bcm2835-gpiomem";
> + reg = <0x7e200000 0x1000>;
> + };
> +
> + firmware {
> + compatible = "raspberrypi,bcm2835-firmware\0simple-bus";
> + #address-cells = <0x00>;
> + #size-cells = <0x00>;
> + mboxes = <0x1a>;
> + phandle = <0x07>;
> +
> + expgpio {
> + compatible = "raspberrypi,firmware-gpio";
> + gpio-controller;
> + #gpio-cells = <0x02>;
> + status = "okay";
> + phandle = <0x2d>;
> + };
> + };
> +
> + power {
> + compatible = "raspberrypi,bcm2835-power";
> + firmware = <0x07>;
> + #power-domain-cells = <0x01>;
> + phandle = <0x13>;
> + };
> +
> + fb {
> + compatible = "brcm,bcm2708-fb";
> + firmware = <0x07>;
> + status = "okay";
> + phandle = <0xb3>;
> + };
> +
> + vcsm {
> + compatible = "raspberrypi,bcm2835-vcsm";
> + firmware = <0x07>;
> + status = "okay";
> + phandle = <0xb4>;
> + };
> +
> + audio {
> + compatible = "brcm,bcm2835-audio";
> + brcm,pwm-channels = <0x08>;
> + status = "disabled";
> + pinctrl-names = "default";
> + pinctrl-0 = <0x1b>;
> + phandle = <0x25>;
> + };
> +
> + sound {
> + status = "disabled";
> + phandle = <0xb5>;
> + };
> +
> + virtgpio {
> + compatible = "brcm,bcm2835-virtgpio";
> + gpio-controller;
> + #gpio-cells = <0x02>;
> + firmware = <0x07>;
> + status = "okay";
> + phandle = <0xb6>;
> + };
> + };
> +
> + clocks {
> + compatible = "simple-bus";
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> +
> + clock@3 {
> + compatible = "fixed-clock";
> + reg = <0x03>;
> + #clock-cells = <0x00>;
> + clock-output-names = "osc";
> + clock-frequency = <0x337f980>;
> + phandle = <0x04>;
> + };
> +
> + clock@4 {
> + compatible = "fixed-clock";
> + reg = <0x04>;
> + #clock-cells = <0x00>;
> + clock-output-names = "otg";
> + clock-frequency = <0x1c9c3800>;
> + phandle = <0x16>;
> + };
> + };
> +
> + phy {
> + compatible = "usb-nop-xceiv";
> + #phy-cells = <0x00>;
> + phandle = <0x17>;
> + };
> +
> + arm-pmu {
> + compatible = "arm,cortex-a72-pmu\0arm,cortex-a53-pmu";
> + interrupts = <0x00 0x10 0x04 0x00 0x11 0x04 0x00 0x12 0x04 0x00 0x13 0x04>;
> + };
> +
> + timer {
> + compatible = "arm,armv7-timer";
> + interrupts = <0x01 0x0d 0xf08 0x01 0x0e 0xf08 0x01 0x0b 0xf08 0x01 0x0a 0xf08>;
> + arm,cpu-registers-not-fw-configured;
> + always-on;
> + };
> +
> + cpus {
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + enable-method = "brcm,bcm2836-smp";
> + phandle = <0xb7>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x00>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x00 0xd8>;
> + phandle = <0xb8>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x01>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x00 0xe0>;
> + phandle = <0xb9>;
> + };
> +
> + cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x02>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x00 0xe8>;
> + phandle = <0xba>;
> + };
> +
> + cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x03>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x00 0xf0>;
> + phandle = <0xbb>;
> + };
> + };
> +
> + v3dbus {
> + compatible = "simple-bus";
> + #address-cells = <0x01>;
> + #size-cells = <0x01>;
> + ranges = <0x7c500000 0x00 0xfc500000 0x3300000 0x40000000 0x00 0xff800000 0x800000>;
> + dma-ranges = <0x00 0x00 0x00 0x3c000000>;
> +
> + v3d@7ec04000 {
> + compatible = "brcm,2711-v3d";
> + reg = <0x7ec00000 0x4000 0x7ec04000 0x4000>;
> + reg-names = "hub\0core0";
> + power-domains = <0x1c 0x01>;
> + resets = <0x1c 0x00>;
> + clocks = <0x03 0x15>;
> + interrupts = <0x00 0x4a 0x04>;
> + status = "okay";
> + phandle = <0xbc>;
> + };
> + };
> +
> + scb {
> + compatible = "simple-bus";
> + #address-cells = <0x02>;
> + #size-cells = <0x01>;
> + ranges = <0x00 0x7c000000 0x00 0xfc000000
> + 0x3800000 0x00 0x40000000 0x00
> + 0xff800000 0x800000 0x06 0x00
> + 0x06 0x00 0x40000000 0x00
> + 0x00 0x00 0x00 0xfc000000>;
> + dma-ranges = <0x00 0x00 0x00 0x00 0xfc000000>;
> + phandle = <0xbd>;
> +
> + pcie@7d500000 {
> + reg = <0x00 0x7d500000 0x9310 0x00 0x7e00f300 0x20>;
> + msi-controller;
> + msi-parent = <0x1d>;
> + #address-cells = <0x03>;
> + #interrupt-cells = <0x01>;
> + #size-cells = <0x02>;
> + bus-range = <0x00 0x01>;
> + compatible = "brcm,bcm7211-pcie\0brcm,bcm7445-pcie\0brcm,pci-plat-dev";
> + max-link-speed = <0x02>;
> + tot-num-pcie = <0x01>;
> + linux,pci-domain = <0x00>;
> + interrupts = <0x00 0x94 0x04 0x00 0x94 0x04>;
> + interrupt-names = "pcie\0msi";
> + interrupt-map-mask = <0x00 0x00 0x00 0x07>;
> + interrupt-map = <0x00 0x00 0x00 0x01
> + 0x01 0x00 0x8f 0x04 0x00 0x00 0x00 0x02
> + 0x01 0x00 0x90 0x04 0x00 0x00 0x00 0x03
> + 0x01 0x00 0x91 0x04 0x00 0x00 0x00 0x04
> + 0x01 0x00 0x92 0x04>;
> + ranges = <0x2000000 0x00 0xf8000000 0x06 0x00 0x00 0x4000000>;
> + dma-ranges = <0x2000000 0x00 0x00 0x00 0x00 0x01 0x00>;
> + status = "okay";
> + phandle = <0x1d>;
> + };
> +
> + genet@7d580000 {
> + compatible = "brcm,genet-v5";
> + reg = <0x00 0x7d580000 0x10000>;
> + status = "okay";
> + #address-cells = <0x01>;
> + #size-cells = <0x01>;
> + interrupts = <0x00 0x9d 0x04 0x00 0x9e 0x04>;
> + phy-handle = <0x1e>;
> + phy-mode = "rgmii";
> + phandle = <0xbe>;
> +
> + mdio@e14 {
> + #address-cells = <0x00>;
> + #size-cells = <0x01>;
> + compatible = "brcm,genet-mdio-v5";
> + reg = <0xe14 0x08>;
> + reg-names = "mdio";
> +
> + genet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + max-speed = <0x3e8>;
> + reg = <0x01>;
> + phandle = <0x1e>;
> + };
> + };
> + };
> +
> + dma@7e007b00 {
> + compatible = "brcm,bcm2838-dma";
> + reg = <0x00 0x7e007b00 0x400>;
> + interrupts = <0x00 0x59 0x04 0x00 0x5a 0x04 0x00 0x5b
> + 0x04 0x00 0x5c 0x04>;
> + interrupt-names = "dma11\0dma12\0dma13\0dma14";
> + #dma-cells = <0x01>;
> + brcm,dma-channel-mask = <0x7000>;
> + phandle = <0xbf>;
> + };
> +
> + xhci@7e9c0000 {
> + compatible = "generic-xhci";
> + status = "disabled";
> + reg = <0x00 0x7e9c0000 0x100000>;
> + interrupts = <0x00 0xb0 0x04>;
> + phandle = <0xc0>;
> + };
> +
> + mailbox@7e00b840 {
> + compatible = "brcm,bcm2838-vchiq";
> + reg = <0x00 0x7e00b840 0x3c>;
> + interrupts = <0x00 0x22 0x04>;
> + phandle = <0xc1>;
> + };
> +
> + hevc-decoder@7eb00000 {
> + compatible = "raspberrypi,argon-hevc-decoder";
> + reg = <0x00 0x7eb00000 0x10000>;
> + status = "okay";
> + };
> +
> + argon-local-intc@7eb10000 {
> + compatible = "raspberrypi,argon-local-intc";
> + reg = <0x00 0x7eb10000 0x1000>;
> + status = "okay";
> + interrupts = <0x00 0x62 0x04>;
> + };
> +
> + h264-decoder@7eb20000 {
> + compatible = "raspberrypi,argon-h264-decoder";
> + reg = <0x00 0x7eb20000 0x10000>;
> + status = "okay";
> + };
> +
> + vp9-decoder@7eb30000 {
> + compatible = "raspberrypi,argon-vp9-decoder";
> + reg = <0x00 0x7eb30000 0x10000>;
> + status = "okay";
> + };
> + };
> +
> + fixedregulator_5v0 {
> + compatible = "regulator-fixed";
> + regulator-name = "5v0";
> + regulator-min-microvolt = <0x4c4b40>;
> + regulator-max-microvolt = <0x4c4b40>;
> + regulator-always-on;
> + phandle = <0x2e>;
> + };
> +
> + fixedregulator_3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "3v3";
> + regulator-min-microvolt = <0x325aa0>;
> + regulator-max-microvolt = <0x325aa0>;
> + regulator-always-on;
> + phandle = <0xc2>;
> + };
> +
> + __overrides__ {
> + cam0-pwdn-ctrl;
> + cam0-pwdn;
> + cam0-led-ctrl;
> + cam0-led;
> + cache_line_size;
> + uart0 = [00 00 00 1f 73 74 61 74 75 73 00];
> + uart1 = "\0\0\0 status";
> + i2s = "\0\0\0!status";
> + spi = "\0\0\0\"status";
> + i2c0 = "\0\0\0#status";
> + i2c1 = "\0\0\0$status";
> + i2c2_iknowwhatimdoing = [00 00 00 15 73 74 61 74 75 73 00];
> + i2c0_baudrate = "\0\0\0#clock-frequency:0";
> + i2c1_baudrate = "\0\0\0$clock-frequency:0";
> + i2c2_baudrate = [00 00 00 15 63 6c 6f 63
> + 6b 2d 66 72 65 71 75 65
> + 6e 63 79 3a 30 00];
> + audio = "\0\0\0%status";
> + watchdog = [00 00 00 1c 73 74 61 74 75 73 00];
> + random = "\0\0\0&status";
> + sd_overclock = "\0\0\0'brcm,overclock-50:0";
> + sd_force_pio = "\0\0\0'brcm,force-pio?";
> + sd_pio_limit = "\0\0\0'brcm,pio-limit:0";
> + sd_debug = "\0\0\0'brcm,debug";
> + sdio_overclock = "\0\0\0(brcm,overclock-50:0\0\0\0\0)brcm,overclock-50:0";
> + axiperf = "\0\0\0*status";
> + arm_freq;
> + act_led_gpio = "\0\0\0+gpios:4";
> + act_led_activelow = "\0\0\0+gpios:8";
> + act_led_trigger = "\0\0\0+linux,default-trigger";
> + pwr_led_gpio = "\0\0\0,gpios:4";
> + pwr_led_activelow = "\0\0\0,gpios:8";
> + pwr_led_trigger = "\0\0\0,linux,default-trigger";
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00 0x00 0x00>;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + phandle = <0xc3>;
> +
> + act {
> + label = "led0";
> + linux,default-trigger = "mmc0";
> + gpios = <0x0f 0x2a 0x00>;
> + phandle = <0x2b>;
> + };
> +
> + pwr {
> + label = "led1";
> + linux,default-trigger = "input";
> + gpios = <0x2d 0x02 0x00>;
> + phandle = <0x2c>;
> + };
> + };
> +
> + sd_io_1v8_reg {
> + status = "okay";
> + compatible = "regulator-gpio";
> + vin-supply = <0x2e>;
> + regulator-name = "vdd-sd-io";
> + regulator-min-microvolt = <0x1b7740>;
> + regulator-max-microvolt = <0x325aa0>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-settling-time-us = <0x1388>;
> + gpios = <0x2d 0x04 0x00>;
> + states = <0x1b7740 0x01 0x325aa0 0x00>;
> + phandle = <0x18>;
> + };
> +
> + __symbols__ {
> + cpu_thermal = "/thermal-zones/cpu-thermal";
> + soc = "/soc";
> + txp = "/soc/txp@7e004000";
> + dma = "/soc/dma@7e007000";
> + watchdog = "/soc/watchdog@7e100000";
> + pm = "/soc/watchdog@7e100000";
> + clocks = "/soc/cprman@7e101000";
> + random = "/soc/rng@7e104000";
> + rng = "/soc/rng@7e104000";
> + mailbox = "/soc/mailbox@7e00b880";
> + gpio = "/soc/gpio@7e200000";
> + dpi_gpio0 = "/soc/gpio@7e200000/dpi_gpio0";
> + emmc_gpio22 = "/soc/gpio@7e200000/emmc_gpio22";
> + emmc_gpio34 = "/soc/gpio@7e200000/emmc_gpio34";
> + emmc_gpio48 = "/soc/gpio@7e200000/emmc_gpio48";
> + gpclk0_gpio4 = "/soc/gpio@7e200000/gpclk0_gpio4";
> + gpclk1_gpio5 = "/soc/gpio@7e200000/gpclk1_gpio5";
> + gpclk1_gpio42 = "/soc/gpio@7e200000/gpclk1_gpio42";
> + gpclk1_gpio44 = "/soc/gpio@7e200000/gpclk1_gpio44";
> + gpclk2_gpio6 = "/soc/gpio@7e200000/gpclk2_gpio6";
> + gpclk2_gpio43 = "/soc/gpio@7e200000/gpclk2_gpio43";
> + i2c0_gpio0 = "/soc/gpio@7e200000/i2c0_gpio0";
> + i2c0_gpio28 = "/soc/gpio@7e200000/i2c0_gpio28";
> + i2c0_gpio44 = "/soc/gpio@7e200000/i2c0_gpio44";
> + i2c1_gpio2 = "/soc/gpio@7e200000/i2c1_gpio2";
> + i2c1_gpio44 = "/soc/gpio@7e200000/i2c1_gpio44";
> + jtag_gpio22 = "/soc/gpio@7e200000/jtag_gpio22";
> + pcm_gpio18 = "/soc/gpio@7e200000/pcm_gpio18";
> + pcm_gpio28 = "/soc/gpio@7e200000/pcm_gpio28";
> + pwm0_gpio12 = "/soc/gpio@7e200000/pwm0_gpio12";
> + pwm0_gpio18 = "/soc/gpio@7e200000/pwm0_gpio18";
> + pwm0_gpio40 = "/soc/gpio@7e200000/pwm0_gpio40";
> + pwm1_gpio13 = "/soc/gpio@7e200000/pwm1_gpio13";
> + pwm1_gpio19 = "/soc/gpio@7e200000/pwm1_gpio19";
> + pwm1_gpio41 = "/soc/gpio@7e200000/pwm1_gpio41";
> + pwm1_gpio45 = "/soc/gpio@7e200000/pwm1_gpio45";
> + sdhost_pins = "/soc/gpio@7e200000/sdhost_gpio48";
> + sdhost_gpio48 = "/soc/gpio@7e200000/sdhost_gpio48";
> + spi0_gpio7 = "/soc/gpio@7e200000/spi0_gpio7";
> + spi0_gpio35 = "/soc/gpio@7e200000/spi0_gpio35";
> + spi1_gpio16 = "/soc/gpio@7e200000/spi1_gpio16";
> + spi2_gpio40 = "/soc/gpio@7e200000/spi2_gpio40";
> + uart0_gpio14 = "/soc/gpio@7e200000/uart0_gpio14";
> + uart0_ctsrts_gpio16 = "/soc/gpio@7e200000/uart0_ctsrts_gpio16";
> + uart0_ctsrts_gpio30 = "/soc/gpio@7e200000/uart0_ctsrts_gpio30";
> + uart0_gpio32 = "/soc/gpio@7e200000/uart0_gpio32";
> + uart0_gpio36 = "/soc/gpio@7e200000/uart0_gpio36";
> + uart0_ctsrts_gpio38 = "/soc/gpio@7e200000/uart0_ctsrts_gpio38";
> + uart1_gpio14 = "/soc/gpio@7e200000/uart1_gpio14";
> + uart1_ctsrts_gpio16 = "/soc/gpio@7e200000/uart1_ctsrts_gpio16";
> + uart1_gpio32 = "/soc/gpio@7e200000/uart1_gpio32";
> + uart1_ctsrts_gpio30 = "/soc/gpio@7e200000/uart1_ctsrts_gpio30";
> + uart1_gpio40 = "/soc/gpio@7e200000/uart1_gpio40";
> + uart1_ctsrts_gpio42 = "/soc/gpio@7e200000/uart1_ctsrts_gpio42";
> + gpclk0_gpio49 = "/soc/gpio@7e200000/gpclk0_gpio49";
> + gpclk1_gpio50 = "/soc/gpio@7e200000/gpclk1_gpio50";
> + gpclk2_gpio51 = "/soc/gpio@7e200000/gpclk2_gpio51";
> + i2c0_gpio46 = "/soc/gpio@7e200000/i2c0_gpio46";
> + i2c1_gpio46 = "/soc/gpio@7e200000/i2c1_gpio46";
> + i2c3_gpio2 = "/soc/gpio@7e200000/i2c3_gpio2";
> + i2c3_gpio4 = "/soc/gpio@7e200000/i2c3_gpio4";
> + i2c4_gpio6 = "/soc/gpio@7e200000/i2c4_gpio6";
> + i2c4_gpio8 = "/soc/gpio@7e200000/i2c4_gpio8";
> + i2c5_gpio10 = "/soc/gpio@7e200000/i2c5_gpio10";
> + i2c5_gpio12 = "/soc/gpio@7e200000/i2c5_gpio12";
> + i2c6_gpio0 = "/soc/gpio@7e200000/i2c6_gpio0";
> + i2c6_gpio22 = "/soc/gpio@7e200000/i2c6_gpio22";
> + i2c_slave_gpio8 = "/soc/gpio@7e200000/i2c_slave_gpio8";
> + jtag_gpio48 = "/soc/gpio@7e200000/jtag_gpio48";
> + mii_gpio28 = "/soc/gpio@7e200000/mii_gpio28";
> + mii_gpio36 = "/soc/gpio@7e200000/mii_gpio36";
> + pcm_gpio50 = "/soc/gpio@7e200000/pcm_gpio50";
> + pwm0_gpio52 = "/soc/gpio@7e200000/pwm0_gpio52";
> + pwm1_gpio53 = "/soc/gpio@7e200000/pwm1_gpio53";
> + rgmii_gpio35 = "/soc/gpio@7e200000/rgmii_gpio35";
> + rgmii_irq_gpio34 = "/soc/gpio@7e200000/rgmii_irq_gpio34";
> + rgmii_irq_gpio39 = "/soc/gpio@7e200000/rgmii_irq_gpio39";
> + rgmii_mdio_gpio28 = "/soc/gpio@7e200000/rgmii_mdio_gpio28";
> + rgmii_mdio_gpio37 = "/soc/gpio@7e200000/rgmii_mdio_gpio37";
> + spi0_gpio46 = "/soc/gpio@7e200000/spi0_gpio46";
> + spi2_gpio46 = "/soc/gpio@7e200000/spi2_gpio46";
> + spi3_gpio0 = "/soc/gpio@7e200000/spi3_gpio0";
> + spi4_gpio4 = "/soc/gpio@7e200000/spi4_gpio4";
> + spi5_gpio12 = "/soc/gpio@7e200000/spi5_gpio12";
> + spi6_gpio18 = "/soc/gpio@7e200000/spi6_gpio18";
> + uart2_gpio0 = "/soc/gpio@7e200000/uart2_gpio0";
> + uart2_ctsrts_gpio2 = "/soc/gpio@7e200000/uart2_ctsrts_gpio2";
> + uart3_gpio4 = "/soc/gpio@7e200000/uart3_gpio4";
> + uart3_ctsrts_gpio6 = "/soc/gpio@7e200000/uart3_ctsrts_gpio6";
> + uart4_gpio8 = "/soc/gpio@7e200000/uart4_gpio8";
> + uart4_ctsrts_gpio10 = "/soc/gpio@7e200000/uart4_ctsrts_gpio10";
> + uart5_gpio12 = "/soc/gpio@7e200000/uart5_gpio12";
> + uart5_ctsrts_gpio14 = "/soc/gpio@7e200000/uart5_ctsrts_gpio14";
> + dpi_18bit_gpio0 = "/soc/gpio@7e200000/dpi_18bit_gpio0";
> + spi0_pins = "/soc/gpio@7e200000/spi0_pins";
> + spi0_cs_pins = "/soc/gpio@7e200000/spi0_cs_pins";
> + spi3_pins = "/soc/gpio@7e200000/spi3_pins";
> + spi3_cs_pins = "/soc/gpio@7e200000/spi3_cs_pins";
> + spi4_pins = "/soc/gpio@7e200000/spi4_pins";
> + spi4_cs_pins = "/soc/gpio@7e200000/spi4_cs_pins";
> + spi5_pins = "/soc/gpio@7e200000/spi5_pins";
> + spi5_cs_pins = "/soc/gpio@7e200000/spi5_cs_pins";
> + spi6_pins = "/soc/gpio@7e200000/spi6_pins";
> + spi6_cs_pins = "/soc/gpio@7e200000/spi6_cs_pins";
> + i2c0_pins = "/soc/gpio@7e200000/i2c0";
> + i2c1_pins = "/soc/gpio@7e200000/i2c1";
> + i2c3_pins = "/soc/gpio@7e200000/i2c3";
> + i2c4_pins = "/soc/gpio@7e200000/i2c4";
> + i2c5_pins = "/soc/gpio@7e200000/i2c5";
> + i2c6_pins = "/soc/gpio@7e200000/i2c6";
> + i2s_pins = "/soc/gpio@7e200000/i2s";
> + sdio_pins = "/soc/gpio@7e200000/sdio_pins";
> + bt_pins = "/soc/gpio@7e200000/bt_pins";
> + uart0_pins = "/soc/gpio@7e200000/uart0_pins";
> + uart1_pins = "/soc/gpio@7e200000/uart1_pins";
> + uart2_pins = "/soc/gpio@7e200000/uart2_pins";
> + uart3_pins = "/soc/gpio@7e200000/uart3_pins";
> + uart4_pins = "/soc/gpio@7e200000/uart4_pins";
> + uart5_pins = "/soc/gpio@7e200000/uart5_pins";
> + audio_pins = "/soc/gpio@7e200000/audio_pins";
> + uart0 = "/soc/serial@7e201000";
> + sdhost = "/soc/mmc@7e202000";
> + i2s = "/soc/i2s@7e203000";
> + spi0 = "/soc/spi@7e204000";
> + spi = "/soc/spi@7e204000";
> + spidev0 = "/soc/spi@7e204000/spidev@0";
> + spidev1 = "/soc/spi@7e204000/spidev@1";
> + i2c0 = "/soc/i2c@7e205000";
> + pixelvalve0 = "/soc/pixelvalve@7e206000";
> + pixelvalve1 = "/soc/pixelvalve@7e207000";
> + dpi = "/soc/dpi@7e208000";
> + dsi0 = "/soc/dsi@7e209000";
> + aux = "/soc/aux@7e215000";
> + uart1 = "/soc/serial@7e215040";
> + spi1 = "/soc/spi@7e215080";
> + spi2 = "/soc/spi@7e2150c0";
> + pwm = "/soc/pwm@7e20c000";
> + hvs = "/soc/hvs@7e400000";
> + dsi1 = "/soc/dsi@7e700000";
> + csi0 = "/soc/csi@7e800000";
> + csi1 = "/soc/csi@7e801000";
> + i2c1 = "/soc/i2c@7e804000";
> + i2c2 = "/soc/i2c@7e805000";
> + vec = "/soc/vec@7e806000";
> + pixelvalve2 = "/soc/pixelvalve@7e807000";
> + hdmi = "/soc/hdmi@7e902000";
> + usb = "/soc/usb@7e980000";
> + vc4 = "/soc/gpu";
> + local_intc = "/soc/local_intc@40000000";
> + gicv2 = "/soc/gic400@40041000";
> + thermal = "/soc/thermal@7d5d2200";
> + uart2 = "/soc/serial@7e201400";
> + uart3 = "/soc/serial@7e201600";
> + uart4 = "/soc/serial@7e201800";
> + uart5 = "/soc/serial@7e201a00";
> + spi3 = "/soc/spi@7e204600";
> + spi4 = "/soc/spi@7e204800";
> + spi5 = "/soc/spi@7e204a00";
> + spi6 = "/soc/spi@7e204c00";
> + i2c3 = "/soc/i2c@7e205600";
> + i2c4 = "/soc/i2c@7e205800";
> + i2c5 = "/soc/i2c@7e205a00";
> + i2c6 = "/soc/i2c@7e205c00";
> + emmc2 = "/soc/emmc2@7e340000";
> + mmc = "/soc/mmc@7e300000";
> + mmcnr = "/soc/mmcnr@7e300000";
> + firmwarekms = "/soc/firmwarekms@7e600000";
> + smi = "/soc/smi@7e600000";
> + axiperf = "/soc/axiperf";
> + firmware = "/soc/firmware";
> + expgpio = "/soc/firmware/expgpio";
> + power = "/soc/power";
> + fb = "/soc/fb";
> + vcsm = "/soc/vcsm";
> + audio = "/soc/audio";
> + sound = "/soc/sound";
> + virtgpio = "/soc/virtgpio";
> + clk_osc = "/clocks/clock@3";
> + clk_usb = "/clocks/clock@4";
> + usbphy = "/phy";
> + cpus = "/cpus";
> + cpu0 = "/cpus/cpu@0";
> + cpu1 = "/cpus/cpu@1";
> + cpu2 = "/cpus/cpu@2";
> + cpu3 = "/cpus/cpu@3";
> + v3d = "/v3dbus/v3d@7ec04000";
> + scb = "/scb";
> + pcie_0 = "/scb/pcie@7d500000";
> + genet = "/scb/genet@7d580000";
> + phy1 = "/scb/genet@7d580000/mdio@e14/genet-phy@0";
> + dma40 = "/scb/dma@7e007b00";
> + xhci = "/scb/xhci@7e9c0000";
> + vchiq = "/scb/mailbox@7e00b840";
> + vdd_5v0_reg = "/fixedregulator_5v0";
> + vdd_3v3_reg = "/fixedregulator_3v3";
> + leds = "/leds";
> + act_led = "/leds/act";
> + pwr_led = "/leds/pwr";
> + sd_io_1v8_reg = "/sd_io_1v8_reg";
> + };
> +};
> diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
> index 88f7504a60f..0d534b8a28d 100644
> --- a/configs/rpi_4_32b_defconfig
> +++ b/configs/rpi_4_32b_defconfig
> @@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x00008000
> CONFIG_SYS_MALLOC_F_LEN=0x2000
> CONFIG_TARGET_RPI_4_32B=y
> CONFIG_ENV_SIZE=0x4000
> +CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b"
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_SYS_LOAD_ADDR=0x1000000
> CONFIG_OF_BOARD_SETUP=y
> diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
> index 59a71031540..0b3cadaced2 100644
> --- a/configs/rpi_4_defconfig
> +++ b/configs/rpi_4_defconfig
> @@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x00080000
> CONFIG_SYS_MALLOC_F_LEN=0x2000
> CONFIG_TARGET_RPI_4=y
> CONFIG_ENV_SIZE=0x4000
> +CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b"
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_SYS_LOAD_ADDR=0x1000000
> CONFIG_OF_BOARD_SETUP=y
> diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
> index 67dbf094ef7..07f67394ac2 100644
> --- a/configs/rpi_arm64_defconfig
> +++ b/configs/rpi_arm64_defconfig
> @@ -6,6 +6,7 @@ CONFIG_TARGET_RPI_ARM64=y
> CONFIG_ENV_SIZE=0x4000
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_SYS_LOAD_ADDR=0x1000000
> +CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b"
> CONFIG_OF_BOARD_SETUP=y
> CONFIG_USE_PREBOOT=y
> CONFIG_PREBOOT="pci enum; usb start;"
> --
> 2.34.0.rc2.393.gf8c9666880-goog
>
>
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4
2021-12-02 17:34 ` Mark Kettenis
@ 2021-12-02 18:20 ` François Ozog
2021-12-02 18:25 ` Simon Glass
1 sibling, 0 replies; 136+ messages in thread
From: François Ozog @ 2021-12-02 18:20 UTC (permalink / raw)
To: Mark Kettenis
Cc: Simon Glass, u-boot, seanga2, ilias.apalodimas, trini,
xypron.glpk, albert.u.boot, mbrugger, swarren, swarren
Hi Mark,
On Thu, 2 Dec 2021 at 18:34, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > From: Simon Glass <sjg@chromium.org>
> > Date: Thu, 2 Dec 2021 08:59:01 -0700
> >
> > Add this file, obtained from the Raspbian boot disk, so there is a
> > reference devicetree in the U-Boot tree. The same one is used for
> > 32- and 64-bit variants.
> >
> > Note that U-Boot does not normally need this at runtime, since
> > CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
> > devicetree at runtime.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > (no changes since v1)
> >
> > arch/arm/dts/Makefile | 3 +-
> > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++++++++
> > configs/rpi_4_32b_defconfig | 1 +
> > configs/rpi_4_defconfig | 1 +
> > configs/rpi_arm64_defconfig | 1 +
> > 5 files changed, 1963 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 2d92b2f940d..9cddab37207 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -1077,7 +1077,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> > bcm2837-rpi-3-a-plus.dtb \
> > bcm2837-rpi-3-b.dtb \
> > bcm2837-rpi-3-b-plus.dtb \
> > - bcm2837-rpi-cm3-io3.dtb
> > + bcm2837-rpi-cm3-io3.dtb \
> > + bcm2711-rpi-4-b.dtb
> >
> > dtb-$(CONFIG_ARCH_BCM63158) += \
> > bcm963158.dtb
> > diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts
> b/arch/arm/dts/bcm2711-rpi-4-b.dts
> > new file mode 100644
> > index 00000000000..425e9fb91c4
> > --- /dev/null
> > +++ b/arch/arm/dts/bcm2711-rpi-4-b.dts
> > @@ -0,0 +1,1958 @@
> > +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> > +/*
> > + * Sample device tree for rpi_4
> > +
> > + * Copyright 2021 Google LLC
> > + */
>
> This is of course an utter lie. This wasn't written from scratch by a
> Google employee.
>
> The original copyright and license for the dtb files you
> "disassembled" applies. You don't specify exactly where you obtained
> the file from, but it probably came from here:
>
> https://github.com/raspberrypi/firmware
>
> And the README.md for that repo states that:
>
> "The dtbs, overlays and associated README are built from Linux
> kernel sources, released under the GPL (see boot/COPYING.linux)"
>
> That's quite a point! thanks for bringing this additional "legal"
standpoint.
> They're probably talking about their own fork of the Linux kernel
> sources here as there are still differences between their device trees
> and the the device trees in the official Linux tree. But if you
> insist on having a device tree in the U-Boot tree, that's where you
> should look.
> > +
> > +/dts-v1/;
> > +
> > +/memreserve/ 0x0000000000000000 0x0000000000001000;
> > +/ {
> > + compatible = "raspberrypi,4-model-b\0brcm,bcm2838\0brcm,bcm2837";
> > + model = "Raspberry Pi 4 Model B";
> > + interrupt-parent = <0x01>;
> > + #address-cells = <0x02>;
> > + #size-cells = <0x01>;
> > +
> > + aliases {
> > + serial0 = "/soc/serial@7e215040";
> > + serial1 = "/soc/serial@7e201000";
> > + audio = "/soc/audio";
> > + aux = "/soc/aux@7e215000";
> > + sound = "/soc/sound";
> > + soc = "/soc";
> > + dma = "/soc/dma@7e007000";
> > + watchdog = "/soc/watchdog@7e100000";
> > + random = "/soc/rng@7e104000";
> > + mailbox = "/soc/mailbox@7e00b880";
> > + gpio = "/soc/gpio@7e200000";
> > + uart0 = "/soc/serial@7e201000";
> > + sdhost = "/soc/mmc@7e202000";
> > + mmc0 = "/soc/emmc2@7e340000";
> > + i2s = "/soc/i2s@7e203000";
> > + spi0 = "/soc/spi@7e204000";
> > + i2c0 = "/soc/i2c@7e205000";
> > + uart1 = "/soc/serial@7e215040";
> > + spi1 = "/soc/spi@7e215080";
> > + spi2 = "/soc/spi@7e2150c0";
> > + mmc = "/soc/mmc@7e300000";
> > + mmc1 = "/soc/mmcnr@7e300000";
> > + i2c1 = "/soc/i2c@7e804000";
> > + i2c2 = "/soc/i2c@7e805000";
> > + usb = "/soc/usb@7e980000";
> > + leds = "/leds";
> > + fb = "/soc/fb";
> > + thermal = "/soc/thermal@7d5d2200";
> > + axiperf = "/soc/axiperf";
> > + mmc2 = "/soc/mmc@7e202000";
> > + ethernet0 = "/scb/genet@7d580000";
> > + };
> > +
> > + chosen {
> > + bootargs = "8250.nr_uarts=1 cma=64M";
> > + };
> > +
> > + thermal-zones {
> > +
> > + cpu-thermal {
> > + polling-delay-passive = <0x00>;
> > + polling-delay = <0x3e8>;
> > + thermal-sensors = <0x02>;
> > + coefficients = <0xfffffe19 0x641b8>;
> > + phandle = <0x2f>;
> > +
> > + cooling-maps {
> > + };
> > + };
> > + };
> > +
> > + soc {
> > + compatible = "simple-bus";
> > + #address-cells = <0x01>;
> > + #size-cells = <0x01>;
> > + ranges = <0x7e000000 0x00 0xfe000000 0x1800000
> > + 0x7c000000 0x00 0xfc000000 0x2000000
> > + 0x40000000 0x00 0xff800000 0x800000>;
> > + dma-ranges = <0xc0000000 0x00 0x00 0x3c000000>;
> > + phandle = <0x30>;
> > +
> > + txp@7e004000 {
> > + compatible = "brcm,bcm2835-txp";
> > + reg = <0x7e004000 0x20>;
> > + interrupts = <0x00 0x4b 0x04>;
> > + status = "disabled";
> > + phandle = <0x31>;
> > + };
> > +
> > + dma@7e007000 {
> > + compatible = "brcm,bcm2835-dma";
> > + reg = <0x7e007000 0xb00>;
> > + interrupts = <0x00 0x50 0x04 0x00 0x51 0x04 0x00
> 0x52
> > + 0x04 0x00 0x53 0x04 0x00 0x54 0x04 0x00
> > + 0x55 0x04 0x00 0x56 0x04 0x00 0x57 0x04
> > + 0x00 0x57 0x04 0x00 0x58 0x04 0x00 0x58
> > + 0x04>;
> > + interrupt-names =
> "dma0\0dma1\0dma2\0dma3\0dma4\0dma5\0dma6\0dma7\0dma8\0dma9\0dma10";
> > + #dma-cells = <0x01>;
> > + brcm,dma-channel-mask = <0x7ef5>;
> > + phandle = <0x0a>;
> > + };
> > +
> > + watchdog@7e100000 {
> > + compatible =
> "brcm,bcm2835-pm\0brcm,bcm2835-pm-wdt";
> > + #power-domain-cells = <0x01>;
> > + #reset-cells = <0x01>;
> > + reg = <0x7e100000 0x114 0x7e00a000 0x24 0x7ec11000
> 0x20>;
> > + clocks = <0x03 0x15 0x03 0x1d 0x03 0x17 0x03 0x16>;
> > + clock-names = "v3d\0peri_image\0h264\0isp";
> > + system-power-controller;
> > + phandle = <0x1c>;
> > + };
> > +
> > + cprman@7e101000 {
> > + compatible = "brcm,bcm2838-cprman";
> > + #clock-cells = <0x01>;
> > + reg = <0x7e101000 0x2000>;
> > + clocks = <0x04 0x05 0x00 0x05 0x01 0x05 0x02 0x06
> > + 0x00 0x06 0x01 0x06 0x02>;
> > + firmware = <0x07>;
> > + phandle = <0x03>;
> > + };
> > +
> > + rng@7e104000 {
> > + compatible = "brcm,bcm2838-rng200";
> > + reg = <0x7e104000 0x10>;
> > + interrupts = <0x00 0x7d 0x04>;
> > + phandle = <0x26>;
> > + };
> > +
> > + mailbox@7e00b880 {
> > + compatible = "brcm,bcm2835-mbox";
> > + reg = <0x7e00b880 0x40>;
> > + interrupts = <0x00 0x21 0x04>;
> > + #mbox-cells = <0x00>;
> > + phandle = <0x1a>;
> > + };
> > +
> > + gpio: gpio@7e200000 {
> > + compatible = "brcm,bcm2835-gpio";
> > + reg = <0x7e200000 0xb4>;
> > + interrupts = <0x00 0x71 0x04 0x00 0x72 0x04>;
> > + gpio-controller;
> > + #gpio-cells = <0x02>;
> > + interrupt-controller;
> > + #interrupt-cells = <0x02>;
> > + phandle = <0x0f>;
> > +
> > + dpi_gpio0 {
> > + brcm,pins = <0x00 0x01 0x02 0x03 0x04
> > + 0x05 0x06 0x07 0x08 0x09
> > + 0x0a 0x0b 0x0c 0x0d 0x0e
> > + 0x0f 0x10 0x11 0x12 0x13
> > + 0x14 0x15 0x16 0x17 0x18
> > + 0x19 0x1a 0x1b>;
> > + brcm,function = <0x06>;
> > + phandle = <0x32>;
> > + };
> > +
> > + emmc_gpio22 {
> > + brcm,pins = <0x16 0x17 0x18 0x19 0x1a
> 0x1b>;
> > + brcm,function = <0x07>;
> > + phandle = <0x33>;
> > + };
> > +
> > + emmc_gpio34 {
> > + brcm,pins = <0x22 0x23 0x24 0x25 0x26
> 0x27>;
> > + brcm,function = <0x07>;
> > + brcm,pull = <0x00 0x02 0x02 0x02 0x02
> 0x02>;
> > + phandle = <0x34>;
> > + };
> > +
> > + emmc_gpio48 {
> > + brcm,pins = <0x30 0x31 0x32 0x33 0x34
> 0x35>;
> > + brcm,function = <0x07>;
> > + phandle = <0x35>;
> > + };
> > +
> > + gpclk0_gpio4 {
> > + brcm,pins = <0x04>;
> > + brcm,function = <0x04>;
> > + phandle = <0x36>;
> > + };
> > +
> > + gpclk1_gpio5 {
> > + brcm,pins = <0x05>;
> > + brcm,function = <0x04>;
> > + phandle = <0x37>;
> > + };
> > +
> > + gpclk1_gpio42 {
> > + brcm,pins = <0x2a>;
> > + brcm,function = <0x04>;
> > + phandle = <0x38>;
> > + };
> > +
> > + gpclk1_gpio44 {
> > + brcm,pins = <0x2c>;
> > + brcm,function = <0x04>;
> > + phandle = <0x39>;
> > + };
> > +
> > + gpclk2_gpio6 {
> > + brcm,pins = <0x06>;
> > + brcm,function = <0x04>;
> > + phandle = <0x3a>;
> > + };
> > +
> > + gpclk2_gpio43 {
> > + brcm,pins = <0x2b>;
> > + brcm,function = <0x04>;
> > + brcm,pull = <0x00>;
> > + phandle = <0x3b>;
> > + };
> > +
> > + i2c0_gpio0 {
> > + brcm,pins = <0x00 0x01>;
> > + brcm,function = <0x04>;
> > + phandle = <0x3c>;
> > + };
> > +
> > + i2c0_gpio28 {
> > + brcm,pins = <0x1c 0x1d>;
> > + brcm,function = <0x04>;
> > + phandle = <0x3d>;
> > + };
> > +
> > + i2c0_gpio44 {
> > + brcm,pins = <0x2c 0x2d>;
> > + brcm,function = <0x05>;
> > + phandle = <0x3e>;
> > + };
> > +
> > + i2c1_gpio2 {
> > + brcm,pins = <0x02 0x03>;
> > + brcm,function = <0x04>;
> > + phandle = <0x3f>;
> > + };
> > +
> > + i2c1_gpio44 {
> > + brcm,pins = <0x2c 0x2d>;
> > + brcm,function = <0x06>;
> > + phandle = <0x40>;
> > + };
> > +
> > + jtag_gpio22 {
> > + brcm,pins = <0x16 0x17 0x18 0x19 0x1a
> 0x1b>;
> > + brcm,function = <0x03>;
> > + phandle = <0x41>;
> > + };
> > +
> > + pcm_gpio18 {
> > + brcm,pins = <0x12 0x13 0x14 0x15>;
> > + brcm,function = <0x04>;
> > + phandle = <0x42>;
> > + };
> > +
> > + pcm_gpio28 {
> > + brcm,pins = <0x1c 0x1d 0x1e 0x1f>;
> > + brcm,function = <0x06>;
> > + phandle = <0x43>;
> > + };
> > +
> > + pwm0_gpio12 {
> > + brcm,pins = <0x0c>;
> > + brcm,function = <0x04>;
> > + phandle = <0x44>;
> > + };
> > +
> > + pwm0_gpio18 {
> > + brcm,pins = <0x12>;
> > + brcm,function = <0x02>;
> > + phandle = <0x45>;
> > + };
> > +
> > + pwm0_gpio40 {
> > + brcm,pins = <0x28>;
> > + brcm,function = <0x04>;
> > + phandle = <0x46>;
> > + };
> > +
> > + pwm1_gpio13 {
> > + brcm,pins = <0x0d>;
> > + brcm,function = <0x04>;
> > + phandle = <0x47>;
> > + };
> > +
> > + pwm1_gpio19 {
> > + brcm,pins = <0x13>;
> > + brcm,function = <0x02>;
> > + phandle = <0x48>;
> > + };
> > +
> > + pwm1_gpio41 {
> > + brcm,pins = <0x29>;
> > + brcm,function = <0x04>;
> > + phandle = <0x49>;
> > + };
> > +
> > + pwm1_gpio45 {
> > + brcm,pins = <0x2d>;
> > + brcm,function = <0x04>;
> > + phandle = <0x4a>;
> > + };
> > +
> > + sdhost_gpio48 {
> > + brcm,pins = <0x16 0x17 0x18 0x19 0x1a
> 0x1b>;
> > + brcm,function = <0x04>;
> > + phandle = <0x0b>;
> > + };
> > +
> > + spi0_gpio7 {
> > + brcm,pins = <0x07 0x08 0x09 0x0a 0x0b>;
> > + brcm,function = <0x04>;
> > + phandle = <0x4b>;
> > + };
> > +
> > + spi0_gpio35 {
> > + brcm,pins = <0x23 0x24 0x25 0x26 0x27>;
> > + brcm,function = <0x04>;
> > + phandle = <0x4c>;
> > + };
> > +
> > + spi1_gpio16 {
> > + brcm,pins = <0x10 0x11 0x12 0x13 0x14
> 0x15>;
> > + brcm,function = <0x03>;
> > + phandle = <0x4d>;
> > + };
> > +
> > + spi2_gpio40 {
> > + brcm,pins = <0x28 0x29 0x2a 0x2b 0x2c
> 0x2d>;
> > + brcm,function = <0x03>;
> > + phandle = <0x4e>;
> > + };
> > +
> > + uart0_gpio14: uart0_gpio14 {
> > + brcm,pins = <0x0e 0x0f>;
> > + brcm,function = <0x04>;
> > + phandle = <0x4f>;
> > + };
> > +
> > + uart0: uart0_ctsrts_gpio16 {
> > + brcm,pins = <0x10 0x11>;
> > + brcm,function = <0x07>;
> > + phandle = <0x50>;
> > + };
> > +
> > + uart0_ctsrts_gpio30 {
> > + brcm,pins = <0x1e 0x1f>;
> > + brcm,function = <0x07>;
> > + brcm,pull = <0x02 0x00>;
> > + phandle = <0x51>;
> > + };
> > +
> > + uart0_gpio32 {
> > + brcm,pins = <0x20 0x21>;
> > + brcm,function = <0x07>;
> > + brcm,pull = <0x00 0x02>;
> > + phandle = <0x52>;
> > + };
> > +
> > + uart0_gpio36 {
> > + brcm,pins = <0x24 0x25>;
> > + brcm,function = <0x06>;
> > + phandle = <0x53>;
> > + };
> > +
> > + uart0_ctsrts_gpio38 {
> > + brcm,pins = <0x26 0x27>;
> > + brcm,function = <0x06>;
> > + phandle = <0x54>;
> > + };
> > +
> > + uart1_gpio14: uart1_gpio14 {
> > + brcm,pins = <0x0e 0x0f>;
> > + brcm,function = <0x02>;
> > + phandle = <0x55>;
> > + };
> > +
> > + uart1: uart1_ctsrts_gpio16 {
> > + brcm,pins = <0x10 0x11>;
> > + brcm,function = <0x02>;
> > + phandle = <0x56>;
> > + };
> > +
> > + uart1_gpio32 {
> > + brcm,pins = <0x20 0x21>;
> > + brcm,function = <0x02>;
> > + phandle = <0x57>;
> > + };
> > +
> > + uart1_ctsrts_gpio30 {
> > + brcm,pins = <0x1e 0x1f>;
> > + brcm,function = <0x02>;
> > + phandle = <0x58>;
> > + };
> > +
> > + uart1_gpio40 {
> > + brcm,pins = <0x28 0x29>;
> > + brcm,function = <0x02>;
> > + phandle = <0x59>;
> > + };
> > +
> > + uart1_ctsrts_gpio42 {
> > + brcm,pins = <0x2a 0x2b>;
> > + brcm,function = <0x02>;
> > + phandle = <0x5a>;
> > + };
> > +
> > + gpclk0_gpio49 {
> > + brcm,pins = <0x31>;
> > + brcm,function = <0x05>;
> > + brcm,pull = <0x00>;
> > + phandle = <0x5b>;
> > + };
> > +
> > + gpclk1_gpio50 {
> > + brcm,pins = <0x32>;
> > + brcm,function = <0x05>;
> > + brcm,pull = <0x00>;
> > + phandle = <0x5c>;
> > + };
> > +
> > + gpclk2_gpio51 {
> > + brcm,pins = <0x33>;
> > + brcm,function = <0x05>;
> > + brcm,pull = <0x00>;
> > + phandle = <0x5d>;
> > + };
> > +
> > + i2c0_gpio46 {
> > + brcm,pins = <0x2e 0x2f>;
> > + brcm,function = <0x04>;
> > + phandle = <0x5e>;
> > + };
> > +
> > + i2c1_gpio46 {
> > + brcm,pins = <0x2e 0x2f>;
> > + brcm,function = <0x05>;
> > + phandle = <0x5f>;
> > + };
> > +
> > + i2c3_gpio2 {
> > + brcm,pins = <0x02 0x03>;
> > + brcm,function = <0x02>;
> > + phandle = <0x60>;
> > + };
> > +
> > + i2c3_gpio4 {
> > + brcm,pins = <0x04 0x05>;
> > + brcm,function = <0x02>;
> > + phandle = <0x61>;
> > + };
> > +
> > + i2c4_gpio6 {
> > + brcm,pins = <0x06 0x07>;
> > + brcm,function = <0x02>;
> > + phandle = <0x62>;
> > + };
> > +
> > + i2c4_gpio8 {
> > + brcm,pins = <0x08 0x09>;
> > + brcm,function = <0x02>;
> > + phandle = <0x63>;
> > + };
> > +
> > + i2c5_gpio10 {
> > + brcm,pins = <0x0a 0x0b>;
> > + brcm,function = <0x02>;
> > + phandle = <0x64>;
> > + };
> > +
> > + i2c5_gpio12 {
> > + brcm,pins = <0x0c 0x0d>;
> > + brcm,function = <0x02>;
> > + phandle = <0x65>;
> > + };
> > +
> > + i2c6_gpio0 {
> > + brcm,pins = <0x00 0x01>;
> > + brcm,function = <0x02>;
> > + phandle = <0x66>;
> > + };
> > +
> > + i2c6_gpio22 {
> > + brcm,pins = <0x16 0x17>;
> > + brcm,function = <0x02>;
> > + phandle = <0x67>;
> > + };
> > +
> > + i2c_slave_gpio8 {
> > + brcm,pins = <0x08 0x09 0x0a 0x0b>;
> > + brcm,function = <0x07>;
> > + phandle = <0x68>;
> > + };
> > +
> > + jtag_gpio48 {
> > + brcm,pins = <0x30 0x31 0x32 0x33 0x34
> 0x35>;
> > + brcm,function = <0x03>;
> > + phandle = <0x69>;
> > + };
> > +
> > + mii_gpio28 {
> > + brcm,pins = <0x1c 0x1d 0x1e 0x1f>;
> > + brcm,function = <0x03>;
> > + phandle = <0x6a>;
> > + };
> > +
> > + mii_gpio36 {
> > + brcm,pins = <0x24 0x25 0x26 0x27>;
> > + brcm,function = <0x02>;
> > + phandle = <0x6b>;
> > + };
> > +
> > + pcm_gpio50 {
> > + brcm,pins = <0x32 0x33 0x34 0x35>;
> > + brcm,function = <0x06>;
> > + phandle = <0x6c>;
> > + };
> > +
> > + pwm0_gpio52 {
> > + brcm,pins = <0x34>;
> > + brcm,function = <0x05>;
> > + brcm,pull = <0x00>;
> > + phandle = <0x6d>;
> > + };
> > +
> > + pwm1_gpio53 {
> > + brcm,pins = <0x35>;
> > + brcm,function = <0x05>;
> > + brcm,pull = <0x00>;
> > + phandle = <0x6e>;
> > + };
> > +
> > + rgmii_gpio35 {
> > + brcm,pins = <0x23 0x24>;
> > + brcm,function = <0x03>;
> > + phandle = <0x6f>;
> > + };
> > +
> > + rgmii_irq_gpio34 {
> > + brcm,pins = <0x22>;
> > + brcm,function = <0x02>;
> > + phandle = <0x70>;
> > + };
> > +
> > + rgmii_irq_gpio39 {
> > + brcm,pins = <0x27>;
> > + brcm,function = <0x03>;
> > + phandle = <0x71>;
> > + };
> > +
> > + rgmii_mdio_gpio28 {
> > + brcm,pins = <0x1c 0x1d>;
> > + brcm,function = <0x02>;
> > + phandle = <0x72>;
> > + };
> > +
> > + rgmii_mdio_gpio37 {
> > + brcm,pins = <0x25 0x26>;
> > + brcm,function = <0x03>;
> > + phandle = <0x73>;
> > + };
> > +
> > + spi0_gpio46 {
> > + brcm,pins = <0x2e 0x2f 0x30 0x31>;
> > + brcm,function = <0x06>;
> > + phandle = <0x74>;
> > + };
> > +
> > + spi2_gpio46 {
> > + brcm,pins = <0x2e 0x2f 0x30 0x31 0x32>;
> > + brcm,function = <0x02>;
> > + phandle = <0x75>;
> > + };
> > +
> > + spi3_gpio0 {
> > + brcm,pins = <0x00 0x01 0x02 0x03>;
> > + brcm,function = <0x07>;
> > + phandle = <0x76>;
> > + };
> > +
> > + spi4_gpio4 {
> > + brcm,pins = <0x04 0x05 0x06 0x07>;
> > + brcm,function = <0x07>;
> > + phandle = <0x77>;
> > + };
> > +
> > + spi5_gpio12 {
> > + brcm,pins = <0x0c 0x0d 0x0e 0x0f>;
> > + brcm,function = <0x07>;
> > + phandle = <0x78>;
> > + };
> > +
> > + spi6_gpio18 {
> > + brcm,pins = <0x12 0x13 0x14 0x15>;
> > + brcm,function = <0x07>;
> > + phandle = <0x79>;
> > + };
> > +
> > + uart2_gpio0 {
> > + brcm,pins = <0x00 0x01>;
> > + brcm,function = <0x03>;
> > + brcm,pull = <0x00 0x02>;
> > + phandle = <0x7a>;
> > + };
> > +
> > + uart2_ctsrts_gpio2 {
> > + brcm,pins = <0x02 0x03>;
> > + brcm,function = <0x03>;
> > + brcm,pull = <0x02 0x00>;
> > + phandle = <0x7b>;
> > + };
> > +
> > + uart3_gpio4 {
> > + brcm,pins = <0x04 0x05>;
> > + brcm,function = <0x03>;
> > + brcm,pull = <0x00 0x02>;
> > + phandle = <0x7c>;
> > + };
> > +
> > + uart3_ctsrts_gpio6 {
> > + brcm,pins = <0x06 0x07>;
> > + brcm,function = <0x03>;
> > + brcm,pull = <0x02 0x00>;
> > + phandle = <0x7d>;
> > + };
> > +
> > + uart4_gpio8 {
> > + brcm,pins = <0x08 0x09>;
> > + brcm,function = <0x03>;
> > + brcm,pull = <0x00 0x02>;
> > + phandle = <0x7e>;
> > + };
> > +
> > + uart4_ctsrts_gpio10 {
> > + brcm,pins = <0x0a 0x0b>;
> > + brcm,function = <0x03>;
> > + brcm,pull = <0x02 0x00>;
> > + phandle = <0x7f>;
> > + };
> > +
> > + uart5_gpio12 {
> > + brcm,pins = <0x0c 0x0d>;
> > + brcm,function = <0x03>;
> > + brcm,pull = <0x00 0x02>;
> > + phandle = <0x80>;
> > + };
> > +
> > + uart5_ctsrts_gpio14 {
> > + brcm,pins = <0x0e 0x0f>;
> > + brcm,function = <0x03>;
> > + brcm,pull = <0x02 0x00>;
> > + phandle = <0x81>;
> > + };
> > +
> > + dpi_18bit_gpio0 {
> > + brcm,pins = <0x00 0x01 0x02 0x03
> > + 0x04 0x05 0x06 0x07
> > + 0x08 0x09 0x0a 0x0b
> > + 0x0c 0x0d 0x0e 0x0f
> > + 0x10 0x11 0x12 0x13
> > + 0x14 0x15>;
> > + brcm,function = <0x06>;
> > + phandle = <0x82>;
> > + };
> > +
> > + spi0_pins {
> > + brcm,pins = <0x09 0x0a 0x0b>;
> > + brcm,function = <0x04>;
> > + phandle = <0x0d>;
> > + };
> > +
> > + spi0_cs_pins {
> > + brcm,pins = <0x08 0x07>;
> > + brcm,function = <0x01>;
> > + phandle = <0x0e>;
> > + };
> > +
> > + spi3_pins {
> > + brcm,pins = <0x01 0x02 0x03>;
> > + brcm,function = <0x07>;
> > + phandle = <0x83>;
> > + };
> > +
> > + spi3_cs_pins {
> > + brcm,pins = <0x00 0x18>;
> > + brcm,function = <0x01>;
> > + phandle = <0x84>;
> > + };
> > +
> > + spi4_pins {
> > + brcm,pins = <0x05 0x06 0x07>;
> > + brcm,function = <0x07>;
> > + phandle = <0x85>;
> > + };
> > +
> > + spi4_cs_pins {
> > + brcm,pins = <0x04 0x19>;
> > + brcm,function = <0x01>;
> > + phandle = <0x86>;
> > + };
> > +
> > + spi5_pins {
> > + brcm,pins = <0x0d 0x0e 0x0f>;
> > + brcm,function = <0x07>;
> > + phandle = <0x87>;
> > + };
> > +
> > + spi5_cs_pins {
> > + brcm,pins = <0x0c 0x1a>;
> > + brcm,function = <0x01>;
> > + phandle = <0x88>;
> > + };
> > +
> > + spi6_pins {
> > + brcm,pins = <0x13 0x14 0x15>;
> > + brcm,function = <0x07>;
> > + phandle = <0x89>;
> > + };
> > +
> > + spi6_cs_pins {
> > + brcm,pins = <0x12 0x1b>;
> > + brcm,function = <0x01>;
> > + phandle = <0x8a>;
> > + };
> > +
> > + i2c0 {
> > + brcm,pins = <0x00 0x01>;
> > + brcm,function = <0x04>;
> > + phandle = <0x10>;
> > + };
> > +
> > + i2c1 {
> > + brcm,pins = <0x02 0x03>;
> > + brcm,function = <0x04>;
> > + phandle = <0x14>;
> > + };
> > +
> > + i2c3 {
> > + brcm,pins = <0x04 0x05>;
> > + brcm,function = <0x02>;
> > + phandle = <0x8b>;
> > + };
> > +
> > + i2c4 {
> > + brcm,pins = <0x08 0x09>;
> > + brcm,function = <0x02>;
> > + phandle = <0x8c>;
> > + };
> > +
> > + i2c5 {
> > + brcm,pins = <0x0c 0x0d>;
> > + brcm,function = <0x02>;
> > + phandle = <0x8d>;
> > + };
> > +
> > + i2c6 {
> > + brcm,pins = <0x16 0x17>;
> > + brcm,function = <0x02>;
> > + phandle = <0x8e>;
> > + };
> > +
> > + i2s {
> > + brcm,pins = <0x12 0x13 0x14 0x15>;
> > + brcm,function = <0x04>;
> > + phandle = <0x0c>;
> > + };
> > +
> > + sdio_pins {
> > + brcm,pins = <0x22 0x23 0x24 0x25 0x26
> 0x27>;
> > + brcm,function = <0x07>;
> > + brcm,pull = <0x00 0x02 0x02 0x02 0x02
> 0x02>;
> > + phandle = <0x19>;
> > + };
> > +
> > + bt_pins {
> > + brcm,pins = [2d 00];
> > + brcm,function = <0x00>;
> > + brcm,pull = <0x02>;
> > + phandle = <0x09>;
> > + };
> > +
> > + uart0_pins {
> > + brcm,pins = <0x20 0x21>;
> > + brcm,function = <0x07>;
> > + brcm,pull = <0x00 0x02>;
> > + phandle = <0x08>;
> > + };
> > +
> > + uart1_pins {
> > + brcm,pins;
> > + brcm,function;
> > + brcm,pull;
> > + phandle = <0x12>;
> > + };
> > +
> > + uart2_pins {
> > + brcm,pins = <0x00 0x01>;
> > + brcm,function = <0x03>;
> > + brcm,pull = <0x00 0x02>;
> > + phandle = <0x8f>;
> > + };
> > +
> > + uart3_pins {
> > + brcm,pins = <0x04 0x05>;
> > + brcm,function = <0x03>;
> > + brcm,pull = <0x00 0x02>;
> > + phandle = <0x90>;
> > + };
> > +
> > + uart4_pins {
> > + brcm,pins = <0x08 0x09>;
> > + brcm,function = <0x03>;
> > + brcm,pull = <0x00 0x02>;
> > + phandle = <0x91>;
> > + };
> > +
> > + uart5_pins {
> > + brcm,pins = <0x0c 0x0d>;
> > + brcm,function = <0x03>;
> > + brcm,pull = <0x00 0x02>;
> > + phandle = <0x92>;
> > + };
> > +
> > + audio_pins {
> > + brcm,pins = <0x28 0x29>;
> > + brcm,function = <0x04>;
> > + phandle = <0x1b>;
> > + };
> > + };
> > +
> > + serial@7e201000 {
> > + compatible =
> "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
> > + reg = <0x7e201000 0x200>;
> > + interrupts = <0x00 0x79 0x04>;
> > + clocks = <0x03 0x13 0x03 0x14>;
> > + clock-names = "uartclk\0apb_pclk";
> > + arm,primecell-periphid = <0x241011>;
> > + cts-event-workaround;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <0x08 0x09>;
> > + status = "okay";
> > + phandle = <0x1f>;
> > + };
> > +
> > + mmc@7e202000 {
> > + compatible = "brcm,bcm2835-sdhost";
> > + reg = <0x7e202000 0x100>;
> > + interrupts = <0x00 0x78 0x04>;
> > + clocks = <0x03 0x14>;
> > + dmas = <0x0a 0x2000000d>;
> > + dma-names = "rx-tx";
> > + status = "disabled";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <0x0b>;
> > + bus-width = <0x04>;
> > + brcm,overclock-50 = <0x00>;
> > + brcm,pio-limit = <0x01>;
> > + phandle = <0x27>;
> > + };
> > +
> > + i2s@7e203000 {
> > + compatible = "brcm,bcm2835-i2s";
> > + reg = <0x7e203000 0x24>;
> > + clocks = <0x03 0x1f>;
> > + dmas = <0x0a 0x02 0x0a 0x03>;
> > + dma-names = "tx\0rx";
> > + status = "disabled";
> > + #sound-dai-cells = <0x00>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <0x0c>;
> > + phandle = <0x21>;
> > + };
> > +
> > + spi@7e204000 {
> > + compatible = "brcm,bcm2835-spi";
> > + reg = <0x7e204000 0x200>;
> > + interrupts = <0x00 0x76 0x04>;
> > + clocks = <0x03 0x14>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + status = "disabled";
> > + dmas = <0x0a 0x06 0x0a 0x07>;
> > + dma-names = "tx\0rx";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <0x0d 0x0e>;
> > + cs-gpios = <0x0f 0x08 0x01 0x0f 0x07 0x01>;
> > + phandle = <0x22>;
> > +
> > + spidev@0 {
> > + compatible = "spidev";
> > + reg = <0x00>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + spi-max-frequency = <0x7735940>;
> > + phandle = <0x93>;
> > + };
> > +
> > + spidev@1 {
> > + compatible = "spidev";
> > + reg = <0x01>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + spi-max-frequency = <0x7735940>;
> > + phandle = <0x94>;
> > + };
> > + };
> > +
> > + i2c@7e205000 {
> > + compatible = "brcm,bcm2835-i2c";
> > + reg = <0x7e205000 0x200>;
> > + interrupts = <0x00 0x75 0x04>;
> > + clocks = <0x03 0x14>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + status = "disabled";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <0x10>;
> > + clock-frequency = <0x186a0>;
> > + phandle = <0x23>;
> > + };
> > +
> > + pixelvalve@7e206000 {
> > + compatible = "brcm,bcm2835-pixelvalve0";
> > + reg = <0x7e206000 0x100>;
> > + interrupts = <0x00 0x6d 0x04>;
> > + status = "disabled";
> > + phandle = <0x95>;
> > + };
> > +
> > + pixelvalve@7e207000 {
> > + compatible = "brcm,bcm2835-pixelvalve1";
> > + reg = <0x7e207000 0x100>;
> > + interrupts = <0x00 0x6e 0x04>;
> > + status = "disabled";
> > + phandle = <0x96>;
> > + };
> > +
> > + dpi@7e208000 {
> > + compatible = "brcm,bcm2835-dpi";
> > + reg = <0x7e208000 0x8c>;
> > + clocks = <0x03 0x14 0x03 0x2c>;
> > + clock-names = "core\0pixel";
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + status = "disabled";
> > + phandle = <0x97>;
> > + };
> > +
> > + dsi@7e209000 {
> > + compatible = "brcm,bcm2835-dsi0";
> > + reg = <0x7e209000 0x78>;
> > + interrupts = <0x00 0x64 0x04>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + #clock-cells = <0x01>;
> > + clocks = <0x03 0x20 0x03 0x2f 0x03 0x31>;
> > + clock-names = "phy\0escape\0pixel";
> > + clock-output-names =
> "dsi0_byte\0dsi0_ddr2\0dsi0_ddr";
> > + phandle = <0x05>;
> > + };
> > +
> > + aux@7e215000 {
> > + compatible = "brcm,bcm2835-aux";
> > + #clock-cells = <0x01>;
> > + reg = <0x7e215000 0x08>;
> > + clocks = <0x03 0x14>;
> > + phandle = <0x11>;
> > + };
> > +
> > + serial@7e215040 {
> > + compatible = "brcm,bcm2835-aux-uart";
> > + reg = <0x7e215040 0x40>;
> > + interrupts = <0x00 0x5d 0x04>;
> > + clocks = <0x11 0x00>;
> > + status = "okay";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <0x12>;
> > + phandle = <0x20>;
> > + };
> > +
> > + spi@7e215080 {
> > + compatible = "brcm,bcm2835-aux-spi";
> > + reg = <0x7e215080 0x40>;
> > + interrupts = <0x00 0x5d 0x04>;
> > + clocks = <0x11 0x01>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + status = "disabled";
> > + phandle = <0x98>;
> > + };
> > +
> > + spi@7e2150c0 {
> > + compatible = "brcm,bcm2835-aux-spi";
> > + reg = <0x7e2150c0 0x40>;
> > + interrupts = <0x00 0x5d 0x04>;
> > + clocks = <0x11 0x02>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + status = "disabled";
> > + phandle = <0x99>;
> > + };
> > +
> > + pwm@7e20c000 {
> > + compatible = "brcm,bcm2835-pwm";
> > + reg = <0x7e20c000 0x28>;
> > + clocks = <0x03 0x1e>;
> > + assigned-clocks = <0x03 0x1e>;
> > + assigned-clock-rates = <0x989680>;
> > + #pwm-cells = <0x02>;
> > + status = "disabled";
> > + phandle = <0x9a>;
> > + };
> > +
> > + hvs@7e400000 {
> > + compatible = "brcm,bcm2835-hvs";
> > + reg = <0x7e400000 0x6000>;
> > + interrupts = <0x00 0x61 0x04>;
> > + status = "disabled";
> > + phandle = <0x9b>;
> > + };
> > +
> > + dsi@7e700000 {
> > + compatible = "brcm,bcm2835-dsi1";
> > + reg = <0x7e700000 0x8c>;
> > + interrupts = <0x00 0x6c 0x04>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + #clock-cells = <0x01>;
> > + clocks = <0x03 0x23 0x03 0x30 0x03 0x32>;
> > + clock-names = "phy\0escape\0pixel";
> > + clock-output-names =
> "dsi1_byte\0dsi1_ddr2\0dsi1_ddr";
> > + status = "disabled";
> > + phandle = <0x06>;
> > + };
> > +
> > + csi@7e800000 {
> > + compatible = "brcm,bcm2835-unicam";
> > + reg = <0x7e800000 0x800 0x7e802000 0x04>;
> > + interrupts = <0x00 0x66 0x04>;
> > + clocks = <0x03 0x2d>;
> > + clock-names = "lp";
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + #clock-cells = <0x01>;
> > + status = "disabled";
> > + power-domains = <0x13 0x0c>;
> > + phandle = <0x9c>;
> > + };
> > +
> > + csi@7e801000 {
> > + compatible = "brcm,bcm2835-unicam";
> > + reg = <0x7e801000 0x800 0x7e802004 0x04>;
> > + interrupts = <0x00 0x67 0x04>;
> > + clocks = <0x03 0x2e>;
> > + clock-names = "lp";
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + #clock-cells = <0x01>;
> > + status = "disabled";
> > + power-domains = <0x13 0x0d>;
> > + phandle = <0x9d>;
> > +
> > + port {
> > +
> > + endpoint {
> > + data-lanes = <0x01 0x02>;
> > + };
> > + };
> > + };
> > +
> > + i2c@7e804000 {
> > + compatible = "brcm,bcm2835-i2c";
> > + reg = <0x7e804000 0x1000>;
> > + interrupts = <0x00 0x75 0x04>;
> > + clocks = <0x03 0x14>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + status = "disabled";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <0x14>;
> > + clock-frequency = <0x186a0>;
> > + phandle = <0x24>;
> > + };
> > +
> > + i2c@7e805000 {
> > + compatible = "brcm,bcm2835-i2c";
> > + reg = <0x7e805000 0x1000>;
> > + interrupts = <0x00 0x75 0x04>;
> > + clocks = <0x03 0x14>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + status = "disabled";
> > + clock-frequency = <0x186a0>;
> > + phandle = <0x15>;
> > + };
> > +
> > + vec@7e806000 {
> > + compatible = "brcm,bcm2835-vec";
> > + reg = <0x7e806000 0x1000>;
> > + clocks = <0x03 0x18>;
> > + interrupts = <0x00 0x7b 0x04>;
> > + status = "disabled";
> > + phandle = <0x9e>;
> > + };
> > +
> > + pixelvalve@7e807000 {
> > + compatible = "brcm,bcm2835-pixelvalve2";
> > + reg = <0x7e807000 0x100>;
> > + interrupts = <0x00 0x6a 0x04>;
> > + status = "disabled";
> > + phandle = <0x9f>;
> > + };
> > +
> > + hdmi@7e902000 {
> > + compatible = "brcm,bcm2835-hdmi";
> > + reg = <0x7e902000 0x600 0x7e808000 0x100>;
> > + interrupts = <0x00 0x68 0x04 0x00 0x69 0x04>;
> > + ddc = <0x15>;
> > + clocks = <0x03 0x10 0x03 0x19>;
> > + clock-names = "pixel\0hdmi";
> > + dmas = <0x0a 0x11>;
> > + dma-names = "audio-rx";
> > + status = "disabled";
> > + power-domains = <0x13 0x05>;
> > + phandle = <0xa0>;
> > + };
> > +
> > + usb@7e980000 {
> > + compatible = "brcm,bcm2708-usb";
> > + reg = <0x7e980000 0x10000 0x7e00b200 0x200>;
> > + interrupts = <0x00 0x49 0x04 0x00 0x28 0x04>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + clocks = <0x16>;
> > + clock-names = "otg";
> > + phys = <0x17>;
> > + phy-names = "usb2-phy";
> > + interrupt-names = "usb\0soft";
> > + power-domains = <0x13 0x06>;
> > + phandle = <0xa1>;
> > + };
> > +
> > + gpu {
> > + compatible = "brcm,bcm2835-vc4";
> > + status = "disabled";
> > + phandle = <0xa2>;
> > + };
> > +
> > + local_intc@40000000 {
> > + compatible = "brcm,bcm2836-l1-intc";
> > + reg = <0x40000000 0x100>;
> > + phandle = <0xa3>;
> > + };
> > +
> > + gic400@40041000 {
> > + interrupt-controller;
> > + #interrupt-cells = <0x03>;
> > + compatible = "arm,gic-400";
> > + reg = <0x40041000 0x1000 0x40042000 0x2000
> 0x40046000 0x2000 0x40048000 0x2000>;
> > + phandle = <0x01>;
> > + };
> > +
> > + thermal@7d5d2200 {
> > + compatible = "brcm,avs-tmon-bcm2838";
> > + reg = <0x7d5d2200 0x2c>;
> > + interrupts = <0x00 0x89 0x04>;
> > + interrupt-names = "tmon";
> > + clocks = <0x03 0x1b>;
> > + #thermal-sensor-cells = <0x00>;
> > + status = "okay";
> > + phandle = <0x02>;
> > + };
> > +
> > + serial@7e201400 {
> > + compatible =
> "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
> > + reg = <0x7e201400 0x200>;
> > + interrupts = <0x00 0x79 0x04>;
> > + clocks = <0x03 0x13 0x03 0x14>;
> > + clock-names = "uartclk\0apb_pclk";
> > + arm,primecell-periphid = <0x241011>;
> > + status = "disabled";
> > + phandle = <0xa4>;
> > + };
> > +
> > + serial@7e201600 {
> > + compatible =
> "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
> > + reg = <0x7e201600 0x200>;
> > + interrupts = <0x00 0x79 0x04>;
> > + clocks = <0x03 0x13 0x03 0x14>;
> > + clock-names = "uartclk\0apb_pclk";
> > + arm,primecell-periphid = <0x241011>;
> > + status = "disabled";
> > + phandle = <0xa5>;
> > + };
> > +
> > + serial@7e201800 {
> > + compatible =
> "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
> > + reg = <0x7e201800 0x200>;
> > + interrupts = <0x00 0x79 0x04>;
> > + clocks = <0x03 0x13 0x03 0x14>;
> > + clock-names = "uartclk\0apb_pclk";
> > + arm,primecell-periphid = <0x241011>;
> > + status = "disabled";
> > + phandle = <0xa6>;
> > + };
> > +
> > + serial@7e201a00 {
> > + compatible =
> "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
> > + reg = <0x7e201a00 0x200>;
> > + interrupts = <0x00 0x79 0x04>;
> > + clocks = <0x03 0x13 0x03 0x14>;
> > + clock-names = "uartclk\0apb_pclk";
> > + arm,primecell-periphid = <0x241011>;
> > + status = "disabled";
> > + phandle = <0xa7>;
> > + };
> > +
> > + spi@7e204600 {
> > + compatible = "brcm,bcm2835-spi";
> > + reg = <0x7e204600 0x200>;
> > + interrupts = <0x00 0x76 0x04>;
> > + clocks = <0x03 0x14>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + status = "disabled";
> > + phandle = <0xa8>;
> > + };
> > +
> > + spi@7e204800 {
> > + compatible = "brcm,bcm2835-spi";
> > + reg = <0x7e204800 0x200>;
> > + interrupts = <0x00 0x76 0x04>;
> > + clocks = <0x03 0x14>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + status = "disabled";
> > + phandle = <0xa9>;
> > + };
> > +
> > + spi@7e204a00 {
> > + compatible = "brcm,bcm2835-spi";
> > + reg = <0x7e204a00 0x200>;
> > + interrupts = <0x00 0x76 0x04>;
> > + clocks = <0x03 0x14>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + status = "disabled";
> > + phandle = <0xaa>;
> > + };
> > +
> > + spi@7e204c00 {
> > + compatible = "brcm,bcm2835-spi";
> > + reg = <0x7e204c00 0x200>;
> > + interrupts = <0x00 0x76 0x04>;
> > + clocks = <0x03 0x14>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + status = "disabled";
> > + phandle = <0xab>;
> > + };
> > +
> > + i2c@7e205600 {
> > + compatible = "brcm,bcm2835-i2c";
> > + reg = <0x7e205600 0x200>;
> > + interrupts = <0x00 0x75 0x04>;
> > + clocks = <0x03 0x14>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + status = "disabled";
> > + phandle = <0xac>;
> > + };
> > +
> > + i2c@7e205800 {
> > + compatible = "brcm,bcm2835-i2c";
> > + reg = <0x7e205800 0x200>;
> > + interrupts = <0x00 0x75 0x04>;
> > + clocks = <0x03 0x14>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + status = "disabled";
> > + phandle = <0xad>;
> > + };
> > +
> > + i2c@7e205a00 {
> > + compatible = "brcm,bcm2835-i2c";
> > + reg = <0x7e205a00 0x200>;
> > + interrupts = <0x00 0x75 0x04>;
> > + clocks = <0x03 0x14>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + status = "disabled";
> > + phandle = <0xae>;
> > + };
> > +
> > + i2c@7e205c00 {
> > + compatible = "brcm,bcm2835-i2c";
> > + reg = <0x7e205c00 0x200>;
> > + interrupts = <0x00 0x75 0x04>;
> > + clocks = <0x03 0x14>;
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + status = "disabled";
> > + phandle = <0xaf>;
> > + };
> > +
> > + emmc2@7e340000 {
> > + compatible = "brcm,bcm2711-emmc2";
> > + status = "okay";
> > + interrupts = <0x00 0x7e 0x04>;
> > + clocks = <0x03 0x33>;
> > + reg = <0x7e340000 0x100>;
> > + broken-cd;
> > + vqmmc-supply = <0x18>;
> > + phandle = <0xb0>;
> > + };
> > +
> > + mmc@7e300000 {
> > + compatible =
> "brcm,bcm2835-mmc\0brcm,bcm2835-sdhci";
> > + reg = <0x7e300000 0x100>;
> > + interrupts = <0x00 0x7e 0x04>;
> > + clocks = <0x03 0x1c>;
> > + dmas = <0x0a 0x0b>;
> > + dma-names = "rx-tx";
> > + brcm,overclock-50 = <0x00>;
> > + status = "disabled";
> > + phandle = <0x28>;
> > + };
> > +
> > + mmcnr@7e300000 {
> > + compatible =
> "brcm,bcm2835-mmc\0brcm,bcm2835-sdhci";
> > + reg = <0x7e300000 0x100>;
> > + interrupts = <0x00 0x7e 0x04>;
> > + clocks = <0x03 0x1c>;
> > + dmas = <0x0a 0x0b>;
> > + dma-names = "rx-tx";
> > + brcm,overclock-50 = <0x00>;
> > + non-removable;
> > + status = "okay";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <0x19>;
> > + bus-width = <0x04>;
> > + phandle = <0x29>;
> > + };
> > +
> > + firmwarekms@7e600000 {
> > + compatible = "raspberrypi,rpi-firmware-kms";
> > + reg = <0x7e600000 0x100>;
> > + interrupts = <0x00 0x70 0x04>;
> > + brcm,firmware = <0x07>;
> > + status = "disabled";
> > + phandle = <0xb1>;
> > + };
> > +
> > + smi@7e600000 {
> > + compatible = "brcm,bcm2835-smi";
> > + reg = <0x7e600000 0x100>;
> > + interrupts = <0x00 0x70 0x04>;
> > + clocks = <0x03 0x2a>;
> > + assigned-clocks = <0x03 0x2a>;
> > + assigned-clock-rates = <0x7735940>;
> > + dmas = <0x0a 0x04>;
> > + dma-names = "rx-tx";
> > + status = "disabled";
> > + phandle = <0xb2>;
> > + };
> > +
> > + axiperf {
> > + compatible = "brcm,bcm2835-axiperf";
> > + reg = <0x7e009800 0x100 0x7ee08000 0x100>;
> > + firmware = <0x07>;
> > + status = "disabled";
> > + phandle = <0x2a>;
> > + };
> > +
> > + gpiomem {
> > + compatible = "brcm,bcm2835-gpiomem";
> > + reg = <0x7e200000 0x1000>;
> > + };
> > +
> > + firmware {
> > + compatible =
> "raspberrypi,bcm2835-firmware\0simple-bus";
> > + #address-cells = <0x00>;
> > + #size-cells = <0x00>;
> > + mboxes = <0x1a>;
> > + phandle = <0x07>;
> > +
> > + expgpio {
> > + compatible = "raspberrypi,firmware-gpio";
> > + gpio-controller;
> > + #gpio-cells = <0x02>;
> > + status = "okay";
> > + phandle = <0x2d>;
> > + };
> > + };
> > +
> > + power {
> > + compatible = "raspberrypi,bcm2835-power";
> > + firmware = <0x07>;
> > + #power-domain-cells = <0x01>;
> > + phandle = <0x13>;
> > + };
> > +
> > + fb {
> > + compatible = "brcm,bcm2708-fb";
> > + firmware = <0x07>;
> > + status = "okay";
> > + phandle = <0xb3>;
> > + };
> > +
> > + vcsm {
> > + compatible = "raspberrypi,bcm2835-vcsm";
> > + firmware = <0x07>;
> > + status = "okay";
> > + phandle = <0xb4>;
> > + };
> > +
> > + audio {
> > + compatible = "brcm,bcm2835-audio";
> > + brcm,pwm-channels = <0x08>;
> > + status = "disabled";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <0x1b>;
> > + phandle = <0x25>;
> > + };
> > +
> > + sound {
> > + status = "disabled";
> > + phandle = <0xb5>;
> > + };
> > +
> > + virtgpio {
> > + compatible = "brcm,bcm2835-virtgpio";
> > + gpio-controller;
> > + #gpio-cells = <0x02>;
> > + firmware = <0x07>;
> > + status = "okay";
> > + phandle = <0xb6>;
> > + };
> > + };
> > +
> > + clocks {
> > + compatible = "simple-bus";
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > +
> > + clock@3 {
> > + compatible = "fixed-clock";
> > + reg = <0x03>;
> > + #clock-cells = <0x00>;
> > + clock-output-names = "osc";
> > + clock-frequency = <0x337f980>;
> > + phandle = <0x04>;
> > + };
> > +
> > + clock@4 {
> > + compatible = "fixed-clock";
> > + reg = <0x04>;
> > + #clock-cells = <0x00>;
> > + clock-output-names = "otg";
> > + clock-frequency = <0x1c9c3800>;
> > + phandle = <0x16>;
> > + };
> > + };
> > +
> > + phy {
> > + compatible = "usb-nop-xceiv";
> > + #phy-cells = <0x00>;
> > + phandle = <0x17>;
> > + };
> > +
> > + arm-pmu {
> > + compatible = "arm,cortex-a72-pmu\0arm,cortex-a53-pmu";
> > + interrupts = <0x00 0x10 0x04 0x00 0x11 0x04 0x00 0x12 0x04
> 0x00 0x13 0x04>;
> > + };
> > +
> > + timer {
> > + compatible = "arm,armv7-timer";
> > + interrupts = <0x01 0x0d 0xf08 0x01 0x0e 0xf08 0x01 0x0b
> 0xf08 0x01 0x0a 0xf08>;
> > + arm,cpu-registers-not-fw-configured;
> > + always-on;
> > + };
> > +
> > + cpus {
> > + #address-cells = <0x01>;
> > + #size-cells = <0x00>;
> > + enable-method = "brcm,bcm2836-smp";
> > + phandle = <0xb7>;
> > +
> > + cpu@0 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x00>;
> > + enable-method = "spin-table";
> > + cpu-release-addr = <0x00 0xd8>;
> > + phandle = <0xb8>;
> > + };
> > +
> > + cpu@1 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x01>;
> > + enable-method = "spin-table";
> > + cpu-release-addr = <0x00 0xe0>;
> > + phandle = <0xb9>;
> > + };
> > +
> > + cpu@2 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x02>;
> > + enable-method = "spin-table";
> > + cpu-release-addr = <0x00 0xe8>;
> > + phandle = <0xba>;
> > + };
> > +
> > + cpu@3 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x03>;
> > + enable-method = "spin-table";
> > + cpu-release-addr = <0x00 0xf0>;
> > + phandle = <0xbb>;
> > + };
> > + };
> > +
> > + v3dbus {
> > + compatible = "simple-bus";
> > + #address-cells = <0x01>;
> > + #size-cells = <0x01>;
> > + ranges = <0x7c500000 0x00 0xfc500000 0x3300000 0x40000000
> 0x00 0xff800000 0x800000>;
> > + dma-ranges = <0x00 0x00 0x00 0x3c000000>;
> > +
> > + v3d@7ec04000 {
> > + compatible = "brcm,2711-v3d";
> > + reg = <0x7ec00000 0x4000 0x7ec04000 0x4000>;
> > + reg-names = "hub\0core0";
> > + power-domains = <0x1c 0x01>;
> > + resets = <0x1c 0x00>;
> > + clocks = <0x03 0x15>;
> > + interrupts = <0x00 0x4a 0x04>;
> > + status = "okay";
> > + phandle = <0xbc>;
> > + };
> > + };
> > +
> > + scb {
> > + compatible = "simple-bus";
> > + #address-cells = <0x02>;
> > + #size-cells = <0x01>;
> > + ranges = <0x00 0x7c000000 0x00 0xfc000000
> > + 0x3800000 0x00 0x40000000 0x00
> > + 0xff800000 0x800000 0x06 0x00
> > + 0x06 0x00 0x40000000 0x00
> > + 0x00 0x00 0x00 0xfc000000>;
> > + dma-ranges = <0x00 0x00 0x00 0x00 0xfc000000>;
> > + phandle = <0xbd>;
> > +
> > + pcie@7d500000 {
> > + reg = <0x00 0x7d500000 0x9310 0x00 0x7e00f300
> 0x20>;
> > + msi-controller;
> > + msi-parent = <0x1d>;
> > + #address-cells = <0x03>;
> > + #interrupt-cells = <0x01>;
> > + #size-cells = <0x02>;
> > + bus-range = <0x00 0x01>;
> > + compatible =
> "brcm,bcm7211-pcie\0brcm,bcm7445-pcie\0brcm,pci-plat-dev";
> > + max-link-speed = <0x02>;
> > + tot-num-pcie = <0x01>;
> > + linux,pci-domain = <0x00>;
> > + interrupts = <0x00 0x94 0x04 0x00 0x94 0x04>;
> > + interrupt-names = "pcie\0msi";
> > + interrupt-map-mask = <0x00 0x00 0x00 0x07>;
> > + interrupt-map = <0x00 0x00 0x00 0x01
> > + 0x01 0x00 0x8f 0x04 0x00 0x00 0x00 0x02
> > + 0x01 0x00 0x90 0x04 0x00 0x00 0x00 0x03
> > + 0x01 0x00 0x91 0x04 0x00 0x00 0x00 0x04
> > + 0x01 0x00 0x92 0x04>;
> > + ranges = <0x2000000 0x00 0xf8000000 0x06 0x00 0x00
> 0x4000000>;
> > + dma-ranges = <0x2000000 0x00 0x00 0x00 0x00 0x01
> 0x00>;
> > + status = "okay";
> > + phandle = <0x1d>;
> > + };
> > +
> > + genet@7d580000 {
> > + compatible = "brcm,genet-v5";
> > + reg = <0x00 0x7d580000 0x10000>;
> > + status = "okay";
> > + #address-cells = <0x01>;
> > + #size-cells = <0x01>;
> > + interrupts = <0x00 0x9d 0x04 0x00 0x9e 0x04>;
> > + phy-handle = <0x1e>;
> > + phy-mode = "rgmii";
> > + phandle = <0xbe>;
> > +
> > + mdio@e14 {
> > + #address-cells = <0x00>;
> > + #size-cells = <0x01>;
> > + compatible = "brcm,genet-mdio-v5";
> > + reg = <0xe14 0x08>;
> > + reg-names = "mdio";
> > +
> > + genet-phy@0 {
> > + compatible =
> "ethernet-phy-ieee802.3-c22";
> > + max-speed = <0x3e8>;
> > + reg = <0x01>;
> > + phandle = <0x1e>;
> > + };
> > + };
> > + };
> > +
> > + dma@7e007b00 {
> > + compatible = "brcm,bcm2838-dma";
> > + reg = <0x00 0x7e007b00 0x400>;
> > + interrupts = <0x00 0x59 0x04 0x00 0x5a 0x04 0x00
> 0x5b
> > + 0x04 0x00 0x5c 0x04>;
> > + interrupt-names = "dma11\0dma12\0dma13\0dma14";
> > + #dma-cells = <0x01>;
> > + brcm,dma-channel-mask = <0x7000>;
> > + phandle = <0xbf>;
> > + };
> > +
> > + xhci@7e9c0000 {
> > + compatible = "generic-xhci";
> > + status = "disabled";
> > + reg = <0x00 0x7e9c0000 0x100000>;
> > + interrupts = <0x00 0xb0 0x04>;
> > + phandle = <0xc0>;
> > + };
> > +
> > + mailbox@7e00b840 {
> > + compatible = "brcm,bcm2838-vchiq";
> > + reg = <0x00 0x7e00b840 0x3c>;
> > + interrupts = <0x00 0x22 0x04>;
> > + phandle = <0xc1>;
> > + };
> > +
> > + hevc-decoder@7eb00000 {
> > + compatible = "raspberrypi,argon-hevc-decoder";
> > + reg = <0x00 0x7eb00000 0x10000>;
> > + status = "okay";
> > + };
> > +
> > + argon-local-intc@7eb10000 {
> > + compatible = "raspberrypi,argon-local-intc";
> > + reg = <0x00 0x7eb10000 0x1000>;
> > + status = "okay";
> > + interrupts = <0x00 0x62 0x04>;
> > + };
> > +
> > + h264-decoder@7eb20000 {
> > + compatible = "raspberrypi,argon-h264-decoder";
> > + reg = <0x00 0x7eb20000 0x10000>;
> > + status = "okay";
> > + };
> > +
> > + vp9-decoder@7eb30000 {
> > + compatible = "raspberrypi,argon-vp9-decoder";
> > + reg = <0x00 0x7eb30000 0x10000>;
> > + status = "okay";
> > + };
> > + };
> > +
> > + fixedregulator_5v0 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "5v0";
> > + regulator-min-microvolt = <0x4c4b40>;
> > + regulator-max-microvolt = <0x4c4b40>;
> > + regulator-always-on;
> > + phandle = <0x2e>;
> > + };
> > +
> > + fixedregulator_3v3 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "3v3";
> > + regulator-min-microvolt = <0x325aa0>;
> > + regulator-max-microvolt = <0x325aa0>;
> > + regulator-always-on;
> > + phandle = <0xc2>;
> > + };
> > +
> > + __overrides__ {
> > + cam0-pwdn-ctrl;
> > + cam0-pwdn;
> > + cam0-led-ctrl;
> > + cam0-led;
> > + cache_line_size;
> > + uart0 = [00 00 00 1f 73 74 61 74 75 73 00];
> > + uart1 = "\0\0\0 status";
> > + i2s = "\0\0\0!status";
> > + spi = "\0\0\0\"status";
> > + i2c0 = "\0\0\0#status";
> > + i2c1 = "\0\0\0$status";
> > + i2c2_iknowwhatimdoing = [00 00 00 15 73 74 61 74 75 73 00];
> > + i2c0_baudrate = "\0\0\0#clock-frequency:0";
> > + i2c1_baudrate = "\0\0\0$clock-frequency:0";
> > + i2c2_baudrate = [00 00 00 15 63 6c 6f 63
> > + 6b 2d 66 72 65 71 75 65
> > + 6e 63 79 3a 30 00];
> > + audio = "\0\0\0%status";
> > + watchdog = [00 00 00 1c 73 74 61 74 75 73 00];
> > + random = "\0\0\0&status";
> > + sd_overclock = "\0\0\0'brcm,overclock-50:0";
> > + sd_force_pio = "\0\0\0'brcm,force-pio?";
> > + sd_pio_limit = "\0\0\0'brcm,pio-limit:0";
> > + sd_debug = "\0\0\0'brcm,debug";
> > + sdio_overclock =
> "\0\0\0(brcm,overclock-50:0\0\0\0\0)brcm,overclock-50:0";
> > + axiperf = "\0\0\0*status";
> > + arm_freq;
> > + act_led_gpio = "\0\0\0+gpios:4";
> > + act_led_activelow = "\0\0\0+gpios:8";
> > + act_led_trigger = "\0\0\0+linux,default-trigger";
> > + pwr_led_gpio = "\0\0\0,gpios:4";
> > + pwr_led_activelow = "\0\0\0,gpios:8";
> > + pwr_led_trigger = "\0\0\0,linux,default-trigger";
> > + };
> > +
> > + memory {
> > + device_type = "memory";
> > + reg = <0x00 0x00 0x00>;
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > + phandle = <0xc3>;
> > +
> > + act {
> > + label = "led0";
> > + linux,default-trigger = "mmc0";
> > + gpios = <0x0f 0x2a 0x00>;
> > + phandle = <0x2b>;
> > + };
> > +
> > + pwr {
> > + label = "led1";
> > + linux,default-trigger = "input";
> > + gpios = <0x2d 0x02 0x00>;
> > + phandle = <0x2c>;
> > + };
> > + };
> > +
> > + sd_io_1v8_reg {
> > + status = "okay";
> > + compatible = "regulator-gpio";
> > + vin-supply = <0x2e>;
> > + regulator-name = "vdd-sd-io";
> > + regulator-min-microvolt = <0x1b7740>;
> > + regulator-max-microvolt = <0x325aa0>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + regulator-settling-time-us = <0x1388>;
> > + gpios = <0x2d 0x04 0x00>;
> > + states = <0x1b7740 0x01 0x325aa0 0x00>;
> > + phandle = <0x18>;
> > + };
> > +
> > + __symbols__ {
> > + cpu_thermal = "/thermal-zones/cpu-thermal";
> > + soc = "/soc";
> > + txp = "/soc/txp@7e004000";
> > + dma = "/soc/dma@7e007000";
> > + watchdog = "/soc/watchdog@7e100000";
> > + pm = "/soc/watchdog@7e100000";
> > + clocks = "/soc/cprman@7e101000";
> > + random = "/soc/rng@7e104000";
> > + rng = "/soc/rng@7e104000";
> > + mailbox = "/soc/mailbox@7e00b880";
> > + gpio = "/soc/gpio@7e200000";
> > + dpi_gpio0 = "/soc/gpio@7e200000/dpi_gpio0";
> > + emmc_gpio22 = "/soc/gpio@7e200000/emmc_gpio22";
> > + emmc_gpio34 = "/soc/gpio@7e200000/emmc_gpio34";
> > + emmc_gpio48 = "/soc/gpio@7e200000/emmc_gpio48";
> > + gpclk0_gpio4 = "/soc/gpio@7e200000/gpclk0_gpio4";
> > + gpclk1_gpio5 = "/soc/gpio@7e200000/gpclk1_gpio5";
> > + gpclk1_gpio42 = "/soc/gpio@7e200000/gpclk1_gpio42";
> > + gpclk1_gpio44 = "/soc/gpio@7e200000/gpclk1_gpio44";
> > + gpclk2_gpio6 = "/soc/gpio@7e200000/gpclk2_gpio6";
> > + gpclk2_gpio43 = "/soc/gpio@7e200000/gpclk2_gpio43";
> > + i2c0_gpio0 = "/soc/gpio@7e200000/i2c0_gpio0";
> > + i2c0_gpio28 = "/soc/gpio@7e200000/i2c0_gpio28";
> > + i2c0_gpio44 = "/soc/gpio@7e200000/i2c0_gpio44";
> > + i2c1_gpio2 = "/soc/gpio@7e200000/i2c1_gpio2";
> > + i2c1_gpio44 = "/soc/gpio@7e200000/i2c1_gpio44";
> > + jtag_gpio22 = "/soc/gpio@7e200000/jtag_gpio22";
> > + pcm_gpio18 = "/soc/gpio@7e200000/pcm_gpio18";
> > + pcm_gpio28 = "/soc/gpio@7e200000/pcm_gpio28";
> > + pwm0_gpio12 = "/soc/gpio@7e200000/pwm0_gpio12";
> > + pwm0_gpio18 = "/soc/gpio@7e200000/pwm0_gpio18";
> > + pwm0_gpio40 = "/soc/gpio@7e200000/pwm0_gpio40";
> > + pwm1_gpio13 = "/soc/gpio@7e200000/pwm1_gpio13";
> > + pwm1_gpio19 = "/soc/gpio@7e200000/pwm1_gpio19";
> > + pwm1_gpio41 = "/soc/gpio@7e200000/pwm1_gpio41";
> > + pwm1_gpio45 = "/soc/gpio@7e200000/pwm1_gpio45";
> > + sdhost_pins = "/soc/gpio@7e200000/sdhost_gpio48";
> > + sdhost_gpio48 = "/soc/gpio@7e200000/sdhost_gpio48";
> > + spi0_gpio7 = "/soc/gpio@7e200000/spi0_gpio7";
> > + spi0_gpio35 = "/soc/gpio@7e200000/spi0_gpio35";
> > + spi1_gpio16 = "/soc/gpio@7e200000/spi1_gpio16";
> > + spi2_gpio40 = "/soc/gpio@7e200000/spi2_gpio40";
> > + uart0_gpio14 = "/soc/gpio@7e200000/uart0_gpio14";
> > + uart0_ctsrts_gpio16 = "/soc/gpio@7e200000
> /uart0_ctsrts_gpio16";
> > + uart0_ctsrts_gpio30 = "/soc/gpio@7e200000
> /uart0_ctsrts_gpio30";
> > + uart0_gpio32 = "/soc/gpio@7e200000/uart0_gpio32";
> > + uart0_gpio36 = "/soc/gpio@7e200000/uart0_gpio36";
> > + uart0_ctsrts_gpio38 = "/soc/gpio@7e200000
> /uart0_ctsrts_gpio38";
> > + uart1_gpio14 = "/soc/gpio@7e200000/uart1_gpio14";
> > + uart1_ctsrts_gpio16 = "/soc/gpio@7e200000
> /uart1_ctsrts_gpio16";
> > + uart1_gpio32 = "/soc/gpio@7e200000/uart1_gpio32";
> > + uart1_ctsrts_gpio30 = "/soc/gpio@7e200000
> /uart1_ctsrts_gpio30";
> > + uart1_gpio40 = "/soc/gpio@7e200000/uart1_gpio40";
> > + uart1_ctsrts_gpio42 = "/soc/gpio@7e200000
> /uart1_ctsrts_gpio42";
> > + gpclk0_gpio49 = "/soc/gpio@7e200000/gpclk0_gpio49";
> > + gpclk1_gpio50 = "/soc/gpio@7e200000/gpclk1_gpio50";
> > + gpclk2_gpio51 = "/soc/gpio@7e200000/gpclk2_gpio51";
> > + i2c0_gpio46 = "/soc/gpio@7e200000/i2c0_gpio46";
> > + i2c1_gpio46 = "/soc/gpio@7e200000/i2c1_gpio46";
> > + i2c3_gpio2 = "/soc/gpio@7e200000/i2c3_gpio2";
> > + i2c3_gpio4 = "/soc/gpio@7e200000/i2c3_gpio4";
> > + i2c4_gpio6 = "/soc/gpio@7e200000/i2c4_gpio6";
> > + i2c4_gpio8 = "/soc/gpio@7e200000/i2c4_gpio8";
> > + i2c5_gpio10 = "/soc/gpio@7e200000/i2c5_gpio10";
> > + i2c5_gpio12 = "/soc/gpio@7e200000/i2c5_gpio12";
> > + i2c6_gpio0 = "/soc/gpio@7e200000/i2c6_gpio0";
> > + i2c6_gpio22 = "/soc/gpio@7e200000/i2c6_gpio22";
> > + i2c_slave_gpio8 = "/soc/gpio@7e200000/i2c_slave_gpio8";
> > + jtag_gpio48 = "/soc/gpio@7e200000/jtag_gpio48";
> > + mii_gpio28 = "/soc/gpio@7e200000/mii_gpio28";
> > + mii_gpio36 = "/soc/gpio@7e200000/mii_gpio36";
> > + pcm_gpio50 = "/soc/gpio@7e200000/pcm_gpio50";
> > + pwm0_gpio52 = "/soc/gpio@7e200000/pwm0_gpio52";
> > + pwm1_gpio53 = "/soc/gpio@7e200000/pwm1_gpio53";
> > + rgmii_gpio35 = "/soc/gpio@7e200000/rgmii_gpio35";
> > + rgmii_irq_gpio34 = "/soc/gpio@7e200000/rgmii_irq_gpio34";
> > + rgmii_irq_gpio39 = "/soc/gpio@7e200000/rgmii_irq_gpio39";
> > + rgmii_mdio_gpio28 = "/soc/gpio@7e200000
> /rgmii_mdio_gpio28";
> > + rgmii_mdio_gpio37 = "/soc/gpio@7e200000
> /rgmii_mdio_gpio37";
> > + spi0_gpio46 = "/soc/gpio@7e200000/spi0_gpio46";
> > + spi2_gpio46 = "/soc/gpio@7e200000/spi2_gpio46";
> > + spi3_gpio0 = "/soc/gpio@7e200000/spi3_gpio0";
> > + spi4_gpio4 = "/soc/gpio@7e200000/spi4_gpio4";
> > + spi5_gpio12 = "/soc/gpio@7e200000/spi5_gpio12";
> > + spi6_gpio18 = "/soc/gpio@7e200000/spi6_gpio18";
> > + uart2_gpio0 = "/soc/gpio@7e200000/uart2_gpio0";
> > + uart2_ctsrts_gpio2 = "/soc/gpio@7e200000
> /uart2_ctsrts_gpio2";
> > + uart3_gpio4 = "/soc/gpio@7e200000/uart3_gpio4";
> > + uart3_ctsrts_gpio6 = "/soc/gpio@7e200000
> /uart3_ctsrts_gpio6";
> > + uart4_gpio8 = "/soc/gpio@7e200000/uart4_gpio8";
> > + uart4_ctsrts_gpio10 = "/soc/gpio@7e200000
> /uart4_ctsrts_gpio10";
> > + uart5_gpio12 = "/soc/gpio@7e200000/uart5_gpio12";
> > + uart5_ctsrts_gpio14 = "/soc/gpio@7e200000
> /uart5_ctsrts_gpio14";
> > + dpi_18bit_gpio0 = "/soc/gpio@7e200000/dpi_18bit_gpio0";
> > + spi0_pins = "/soc/gpio@7e200000/spi0_pins";
> > + spi0_cs_pins = "/soc/gpio@7e200000/spi0_cs_pins";
> > + spi3_pins = "/soc/gpio@7e200000/spi3_pins";
> > + spi3_cs_pins = "/soc/gpio@7e200000/spi3_cs_pins";
> > + spi4_pins = "/soc/gpio@7e200000/spi4_pins";
> > + spi4_cs_pins = "/soc/gpio@7e200000/spi4_cs_pins";
> > + spi5_pins = "/soc/gpio@7e200000/spi5_pins";
> > + spi5_cs_pins = "/soc/gpio@7e200000/spi5_cs_pins";
> > + spi6_pins = "/soc/gpio@7e200000/spi6_pins";
> > + spi6_cs_pins = "/soc/gpio@7e200000/spi6_cs_pins";
> > + i2c0_pins = "/soc/gpio@7e200000/i2c0";
> > + i2c1_pins = "/soc/gpio@7e200000/i2c1";
> > + i2c3_pins = "/soc/gpio@7e200000/i2c3";
> > + i2c4_pins = "/soc/gpio@7e200000/i2c4";
> > + i2c5_pins = "/soc/gpio@7e200000/i2c5";
> > + i2c6_pins = "/soc/gpio@7e200000/i2c6";
> > + i2s_pins = "/soc/gpio@7e200000/i2s";
> > + sdio_pins = "/soc/gpio@7e200000/sdio_pins";
> > + bt_pins = "/soc/gpio@7e200000/bt_pins";
> > + uart0_pins = "/soc/gpio@7e200000/uart0_pins";
> > + uart1_pins = "/soc/gpio@7e200000/uart1_pins";
> > + uart2_pins = "/soc/gpio@7e200000/uart2_pins";
> > + uart3_pins = "/soc/gpio@7e200000/uart3_pins";
> > + uart4_pins = "/soc/gpio@7e200000/uart4_pins";
> > + uart5_pins = "/soc/gpio@7e200000/uart5_pins";
> > + audio_pins = "/soc/gpio@7e200000/audio_pins";
> > + uart0 = "/soc/serial@7e201000";
> > + sdhost = "/soc/mmc@7e202000";
> > + i2s = "/soc/i2s@7e203000";
> > + spi0 = "/soc/spi@7e204000";
> > + spi = "/soc/spi@7e204000";
> > + spidev0 = "/soc/spi@7e204000/spidev@0";
> > + spidev1 = "/soc/spi@7e204000/spidev@1";
> > + i2c0 = "/soc/i2c@7e205000";
> > + pixelvalve0 = "/soc/pixelvalve@7e206000";
> > + pixelvalve1 = "/soc/pixelvalve@7e207000";
> > + dpi = "/soc/dpi@7e208000";
> > + dsi0 = "/soc/dsi@7e209000";
> > + aux = "/soc/aux@7e215000";
> > + uart1 = "/soc/serial@7e215040";
> > + spi1 = "/soc/spi@7e215080";
> > + spi2 = "/soc/spi@7e2150c0";
> > + pwm = "/soc/pwm@7e20c000";
> > + hvs = "/soc/hvs@7e400000";
> > + dsi1 = "/soc/dsi@7e700000";
> > + csi0 = "/soc/csi@7e800000";
> > + csi1 = "/soc/csi@7e801000";
> > + i2c1 = "/soc/i2c@7e804000";
> > + i2c2 = "/soc/i2c@7e805000";
> > + vec = "/soc/vec@7e806000";
> > + pixelvalve2 = "/soc/pixelvalve@7e807000";
> > + hdmi = "/soc/hdmi@7e902000";
> > + usb = "/soc/usb@7e980000";
> > + vc4 = "/soc/gpu";
> > + local_intc = "/soc/local_intc@40000000";
> > + gicv2 = "/soc/gic400@40041000";
> > + thermal = "/soc/thermal@7d5d2200";
> > + uart2 = "/soc/serial@7e201400";
> > + uart3 = "/soc/serial@7e201600";
> > + uart4 = "/soc/serial@7e201800";
> > + uart5 = "/soc/serial@7e201a00";
> > + spi3 = "/soc/spi@7e204600";
> > + spi4 = "/soc/spi@7e204800";
> > + spi5 = "/soc/spi@7e204a00";
> > + spi6 = "/soc/spi@7e204c00";
> > + i2c3 = "/soc/i2c@7e205600";
> > + i2c4 = "/soc/i2c@7e205800";
> > + i2c5 = "/soc/i2c@7e205a00";
> > + i2c6 = "/soc/i2c@7e205c00";
> > + emmc2 = "/soc/emmc2@7e340000";
> > + mmc = "/soc/mmc@7e300000";
> > + mmcnr = "/soc/mmcnr@7e300000";
> > + firmwarekms = "/soc/firmwarekms@7e600000";
> > + smi = "/soc/smi@7e600000";
> > + axiperf = "/soc/axiperf";
> > + firmware = "/soc/firmware";
> > + expgpio = "/soc/firmware/expgpio";
> > + power = "/soc/power";
> > + fb = "/soc/fb";
> > + vcsm = "/soc/vcsm";
> > + audio = "/soc/audio";
> > + sound = "/soc/sound";
> > + virtgpio = "/soc/virtgpio";
> > + clk_osc = "/clocks/clock@3";
> > + clk_usb = "/clocks/clock@4";
> > + usbphy = "/phy";
> > + cpus = "/cpus";
> > + cpu0 = "/cpus/cpu@0";
> > + cpu1 = "/cpus/cpu@1";
> > + cpu2 = "/cpus/cpu@2";
> > + cpu3 = "/cpus/cpu@3";
> > + v3d = "/v3dbus/v3d@7ec04000";
> > + scb = "/scb";
> > + pcie_0 = "/scb/pcie@7d500000";
> > + genet = "/scb/genet@7d580000";
> > + phy1 = "/scb/genet@7d580000/mdio@e14/genet-phy@0";
> > + dma40 = "/scb/dma@7e007b00";
> > + xhci = "/scb/xhci@7e9c0000";
> > + vchiq = "/scb/mailbox@7e00b840";
> > + vdd_5v0_reg = "/fixedregulator_5v0";
> > + vdd_3v3_reg = "/fixedregulator_3v3";
> > + leds = "/leds";
> > + act_led = "/leds/act";
> > + pwr_led = "/leds/pwr";
> > + sd_io_1v8_reg = "/sd_io_1v8_reg";
> > + };
> > +};
> > diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
> > index 88f7504a60f..0d534b8a28d 100644
> > --- a/configs/rpi_4_32b_defconfig
> > +++ b/configs/rpi_4_32b_defconfig
> > @@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x00008000
> > CONFIG_SYS_MALLOC_F_LEN=0x2000
> > CONFIG_TARGET_RPI_4_32B=y
> > CONFIG_ENV_SIZE=0x4000
> > +CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b"
> > CONFIG_DISTRO_DEFAULTS=y
> > CONFIG_SYS_LOAD_ADDR=0x1000000
> > CONFIG_OF_BOARD_SETUP=y
> > diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
> > index 59a71031540..0b3cadaced2 100644
> > --- a/configs/rpi_4_defconfig
> > +++ b/configs/rpi_4_defconfig
> > @@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x00080000
> > CONFIG_SYS_MALLOC_F_LEN=0x2000
> > CONFIG_TARGET_RPI_4=y
> > CONFIG_ENV_SIZE=0x4000
> > +CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b"
> > CONFIG_DISTRO_DEFAULTS=y
> > CONFIG_SYS_LOAD_ADDR=0x1000000
> > CONFIG_OF_BOARD_SETUP=y
> > diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
> > index 67dbf094ef7..07f67394ac2 100644
> > --- a/configs/rpi_arm64_defconfig
> > +++ b/configs/rpi_arm64_defconfig
> > @@ -6,6 +6,7 @@ CONFIG_TARGET_RPI_ARM64=y
> > CONFIG_ENV_SIZE=0x4000
> > CONFIG_DISTRO_DEFAULTS=y
> > CONFIG_SYS_LOAD_ADDR=0x1000000
> > +CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b"
> > CONFIG_OF_BOARD_SETUP=y
> > CONFIG_USE_PREBOOT=y
> > CONFIG_PREBOOT="pci enum; usb start;"
> > --
> > 2.34.0.rc2.393.gf8c9666880-goog
> >
> >
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4
2021-12-02 17:34 ` Mark Kettenis
2021-12-02 18:20 ` François Ozog
@ 2021-12-02 18:25 ` Simon Glass
2021-12-03 12:16 ` Peter Robinson
1 sibling, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 18:25 UTC (permalink / raw)
To: Mark Kettenis
Cc: u-boot, seanga2, ilias.apalodimas, trini, francois.ozog,
xypron.glpk, albert.u.boot, mbrugger, swarren, swarren
Hi Mark,
On Thu, 2 Dec 2021 at 10:34, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Simon Glass <sjg@chromium.org>
> > Date: Thu, 2 Dec 2021 08:59:01 -0700
> >
> > Add this file, obtained from the Raspbian boot disk, so there is a
> > reference devicetree in the U-Boot tree. The same one is used for
> > 32- and 64-bit variants.
> >
> > Note that U-Boot does not normally need this at runtime, since
> > CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
> > devicetree at runtime.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > (no changes since v1)
> >
> > arch/arm/dts/Makefile | 3 +-
> > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++++++++
> > configs/rpi_4_32b_defconfig | 1 +
> > configs/rpi_4_defconfig | 1 +
> > configs/rpi_arm64_defconfig | 1 +
> > 5 files changed, 1963 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 2d92b2f940d..9cddab37207 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -1077,7 +1077,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> > bcm2837-rpi-3-a-plus.dtb \
> > bcm2837-rpi-3-b.dtb \
> > bcm2837-rpi-3-b-plus.dtb \
> > - bcm2837-rpi-cm3-io3.dtb
> > + bcm2837-rpi-cm3-io3.dtb \
> > + bcm2711-rpi-4-b.dtb
> >
> > dtb-$(CONFIG_ARCH_BCM63158) += \
> > bcm963158.dtb
> > diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts b/arch/arm/dts/bcm2711-rpi-4-b.dts
> > new file mode 100644
> > index 00000000000..425e9fb91c4
> > --- /dev/null
> > +++ b/arch/arm/dts/bcm2711-rpi-4-b.dts
> > @@ -0,0 +1,1958 @@
> > +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> > +/*
> > + * Sample device tree for rpi_4
> > +
> > + * Copyright 2021 Google LLC
> > + */
>
> This is of course an utter lie. This wasn't written from scratch by a
> Google employee.
>
> The original copyright and license for the dtb files you
> "disassembled" applies. You don't specify exactly where you obtained
> the file from, but it probably came from here:
>
> https://github.com/raspberrypi/firmware
>
> And the README.md for that repo states that:
>
> "The dtbs, overlays and associated README are built from Linux
> kernel sources, released under the GPL (see boot/COPYING.linux)"
>
> They're probably talking about their own fork of the Linux kernel
> sources here as there are still differences between their device trees
> and the the device trees in the official Linux tree. But if you
> insist on having a device tree in the U-Boot tree, that's where you
> should look.
IANAL and didn't consider this point.
I got this from the boot disk (using fdtdump) and it does not include
a copyright message. I'll change this in the next version.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4
2021-12-02 18:25 ` Simon Glass
@ 2021-12-03 12:16 ` Peter Robinson
2021-12-03 20:13 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Peter Robinson @ 2021-12-03 12:16 UTC (permalink / raw)
To: Simon Glass
Cc: Mark Kettenis, u-boot, seanga2, ilias.apalodimas, trini,
francois.ozog, xypron.glpk, albert.u.boot, mbrugger, swarren,
swarren
On Thu, Dec 2, 2021 at 6:26 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Mark,
>
> On Thu, 2 Dec 2021 at 10:34, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >
> > > From: Simon Glass <sjg@chromium.org>
> > > Date: Thu, 2 Dec 2021 08:59:01 -0700
> > >
> > > Add this file, obtained from the Raspbian boot disk, so there is a
> > > reference devicetree in the U-Boot tree. The same one is used for
> > > 32- and 64-bit variants.
> > >
> > > Note that U-Boot does not normally need this at runtime, since
> > > CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
> > > devicetree at runtime.
> > >
> > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > ---
> > >
> > > (no changes since v1)
> > >
> > > arch/arm/dts/Makefile | 3 +-
> > > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++++++++
> > > configs/rpi_4_32b_defconfig | 1 +
> > > configs/rpi_4_defconfig | 1 +
> > > configs/rpi_arm64_defconfig | 1 +
> > > 5 files changed, 1963 insertions(+), 1 deletion(-)
> > > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> > >
> > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > > index 2d92b2f940d..9cddab37207 100644
> > > --- a/arch/arm/dts/Makefile
> > > +++ b/arch/arm/dts/Makefile
> > > @@ -1077,7 +1077,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> > > bcm2837-rpi-3-a-plus.dtb \
> > > bcm2837-rpi-3-b.dtb \
> > > bcm2837-rpi-3-b-plus.dtb \
> > > - bcm2837-rpi-cm3-io3.dtb
> > > + bcm2837-rpi-cm3-io3.dtb \
> > > + bcm2711-rpi-4-b.dtb
> > >
> > > dtb-$(CONFIG_ARCH_BCM63158) += \
> > > bcm963158.dtb
> > > diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts b/arch/arm/dts/bcm2711-rpi-4-b.dts
> > > new file mode 100644
> > > index 00000000000..425e9fb91c4
> > > --- /dev/null
> > > +++ b/arch/arm/dts/bcm2711-rpi-4-b.dts
> > > @@ -0,0 +1,1958 @@
> > > +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> > > +/*
> > > + * Sample device tree for rpi_4
> > > +
> > > + * Copyright 2021 Google LLC
> > > + */
> >
> > This is of course an utter lie. This wasn't written from scratch by a
> > Google employee.
> >
> > The original copyright and license for the dtb files you
> > "disassembled" applies. You don't specify exactly where you obtained
> > the file from, but it probably came from here:
> >
> > https://github.com/raspberrypi/firmware
> >
> > And the README.md for that repo states that:
> >
> > "The dtbs, overlays and associated README are built from Linux
> > kernel sources, released under the GPL (see boot/COPYING.linux)"
> >
> > They're probably talking about their own fork of the Linux kernel
> > sources here as there are still differences between their device trees
> > and the the device trees in the official Linux tree. But if you
> > insist on having a device tree in the U-Boot tree, that's where you
> > should look.
>
> IANAL and didn't consider this point.
>
> I got this from the boot disk (using fdtdump) and it does not include
> a copyright message. I'll change this in the next version.
Should probably just get the original one from their upstream source
repo then rather than decompiling it.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4
2021-12-03 12:16 ` Peter Robinson
@ 2021-12-03 20:13 ` Simon Glass
0 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-03 20:13 UTC (permalink / raw)
To: Peter Robinson
Cc: Mark Kettenis, u-boot, seanga2, ilias.apalodimas, trini,
francois.ozog, xypron.glpk, albert.u.boot, mbrugger, swarren,
swarren
Hi Peter,
Taking another look at https://github.com/raspberrypi/firmware.git I
see that the README says that the .dtb files are build from Linux. So
it seems I can simply grab them from there.
Regards,
Simon
On Fri, 3 Dec 2021 at 05:16, Peter Robinson <pbrobinson@gmail.com> wrote:
>
> On Thu, Dec 2, 2021 at 6:26 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Mark,
> >
> > On Thu, 2 Dec 2021 at 10:34, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > >
> > > > From: Simon Glass <sjg@chromium.org>
> > > > Date: Thu, 2 Dec 2021 08:59:01 -0700
> > > >
> > > > Add this file, obtained from the Raspbian boot disk, so there is a
> > > > reference devicetree in the U-Boot tree. The same one is used for
> > > > 32- and 64-bit variants.
> > > >
> > > > Note that U-Boot does not normally need this at runtime, since
> > > > CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
> > > > devicetree at runtime.
> > > >
> > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > ---
> > > >
> > > > (no changes since v1)
> > > >
> > > > arch/arm/dts/Makefile | 3 +-
> > > > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++++++++
> > > > configs/rpi_4_32b_defconfig | 1 +
> > > > configs/rpi_4_defconfig | 1 +
> > > > configs/rpi_arm64_defconfig | 1 +
> > > > 5 files changed, 1963 insertions(+), 1 deletion(-)
> > > > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> > > >
> > > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > > > index 2d92b2f940d..9cddab37207 100644
> > > > --- a/arch/arm/dts/Makefile
> > > > +++ b/arch/arm/dts/Makefile
> > > > @@ -1077,7 +1077,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> > > > bcm2837-rpi-3-a-plus.dtb \
> > > > bcm2837-rpi-3-b.dtb \
> > > > bcm2837-rpi-3-b-plus.dtb \
> > > > - bcm2837-rpi-cm3-io3.dtb
> > > > + bcm2837-rpi-cm3-io3.dtb \
> > > > + bcm2711-rpi-4-b.dtb
> > > >
> > > > dtb-$(CONFIG_ARCH_BCM63158) += \
> > > > bcm963158.dtb
> > > > diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts b/arch/arm/dts/bcm2711-rpi-4-b.dts
> > > > new file mode 100644
> > > > index 00000000000..425e9fb91c4
> > > > --- /dev/null
> > > > +++ b/arch/arm/dts/bcm2711-rpi-4-b.dts
> > > > @@ -0,0 +1,1958 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> > > > +/*
> > > > + * Sample device tree for rpi_4
> > > > +
> > > > + * Copyright 2021 Google LLC
> > > > + */
> > >
> > > This is of course an utter lie. This wasn't written from scratch by a
> > > Google employee.
> > >
> > > The original copyright and license for the dtb files you
> > > "disassembled" applies. You don't specify exactly where you obtained
> > > the file from, but it probably came from here:
> > >
> > > https://github.com/raspberrypi/firmware
> > >
> > > And the README.md for that repo states that:
> > >
> > > "The dtbs, overlays and associated README are built from Linux
> > > kernel sources, released under the GPL (see boot/COPYING.linux)"
> > >
> > > They're probably talking about their own fork of the Linux kernel
> > > sources here as there are still differences between their device trees
> > > and the the device trees in the official Linux tree. But if you
> > > insist on having a device tree in the U-Boot tree, that's where you
> > > should look.
> >
> > IANAL and didn't consider this point.
> >
> > I got this from the boot disk (using fdtdump) and it does not include
> > a copyright message. I'll change this in the next version.
>
> Should probably just get the original one from their upstream source
> repo then rather than decompiling it.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v6 08/25] arm: vexpress: Add a devicetree file for juno
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (6 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4 Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file Simon Glass
` (18 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Albert Aribaud, Linus Walleij
Add this file, obtained from the Linaro website[1], so there is a
reference file in the U-Boot tree.
Note that U-Boot does not normally need this at runtime, since
CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
devicetree at runtime.
[1] https://releases.linaro.org/android/reference-lcr/juno/7.1-17.05/
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/dts/Makefile | 3 +
arch/arm/dts/juno-r2.dts | 1038 ++++++++++++++++++++++++
configs/vexpress_aemv8a_juno_defconfig | 1 +
3 files changed, 1042 insertions(+)
create mode 100644 arch/arm/dts/juno-r2.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9cddab37207..d53bae2c350 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1149,7 +1149,10 @@ dtb-$(CONFIG_TARGET_GE_BX50V3) += \
dtb-$(CONFIG_TARGET_GE_B1X5V2) += imx6dl-b1x5v2.dtb
dtb-$(CONFIG_TARGET_MX53PPD) += imx53-ppd.dtb
+# TODO(Linus Walleij <linus.walleij@linaro.org>): Should us a single vexpress
+# Kconfig option to build all of these. See examples above.
dtb-$(CONFIG_TARGET_VEXPRESS_CA9X4) += vexpress-v2p-ca9.dtb
+dtb-$(CONFIG_TARGET_VEXPRESS64_JUNO) += juno-r2.dtb
dtb-$(CONFIG_TARGET_TOTAL_COMPUTE) += total_compute.dtb
diff --git a/arch/arm/dts/juno-r2.dts b/arch/arm/dts/juno-r2.dts
new file mode 100644
index 00000000000..5a536d8100e
--- /dev/null
+++ b/arch/arm/dts/juno-r2.dts
@@ -0,0 +1,1038 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for juno
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ model = "ARM Juno development board (r2)";
+ compatible = "arm,juno-r2\0arm,juno";
+ interrupt-parent = <0x01>;
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+
+ aliases {
+ serial0 = "/uart@7ff80000";
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <0x02>;
+ #size-cells = <0x00>;
+
+ cpu-map {
+
+ cluster0 {
+
+ core0 {
+ cpu = <0x02>;
+ };
+
+ core1 {
+ cpu = <0x03>;
+ };
+ };
+
+ cluster1 {
+
+ core0 {
+ cpu = <0x04>;
+ };
+
+ core1 {
+ cpu = <0x05>;
+ };
+
+ core2 {
+ cpu = <0x06>;
+ };
+
+ core3 {
+ cpu = <0x07>;
+ };
+ };
+ };
+
+ idle-states {
+ entry-method = "arm,psci";
+
+ cpu-sleep-0 {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x10000>;
+ local-timer-stop;
+ entry-latency-us = <0x12c>;
+ exit-latency-us = <0x4b0>;
+ min-residency-us = <0x7d0>;
+ linux,phandle = <0x0a>;
+ phandle = <0x0a>;
+ };
+
+ cluster-sleep-0 {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x1010000>;
+ local-timer-stop;
+ entry-latency-us = <0x190>;
+ exit-latency-us = <0x4b0>;
+ min-residency-us = <0x9c4>;
+ linux,phandle = <0x0b>;
+ phandle = <0x0b>;
+ };
+ };
+
+ cpu@0 {
+ compatible = "arm,cortex-a72\0arm,armv8";
+ reg = <0x00 0x00>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <0x08>;
+ clocks = <0x09 0x00>;
+ cpu-idle-states = <0x0a 0x0b>;
+ sched-energy-costs = <0x0c 0x0d>;
+ #cooling-cells = <0x02>;
+ dynamic-power-coefficient = <0x1c2>;
+ linux,phandle = <0x02>;
+ phandle = <0x02>;
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a72\0arm,armv8";
+ reg = <0x00 0x01>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <0x08>;
+ clocks = <0x09 0x00>;
+ cpu-idle-states = <0x0a 0x0b>;
+ sched-energy-costs = <0x0c 0x0d>;
+ #cooling-cells = <0x02>;
+ dynamic-power-coefficient = <0x1c2>;
+ linux,phandle = <0x03>;
+ phandle = <0x03>;
+ };
+
+ cpu@100 {
+ compatible = "arm,cortex-a53\0arm,armv8";
+ reg = <0x00 0x100>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <0x0e>;
+ clocks = <0x09 0x01>;
+ cpu-idle-states = <0x0a 0x0b>;
+ sched-energy-costs = <0x0f 0x10>;
+ #cooling-cells = <0x02>;
+ dynamic-power-coefficient = <0x8c>;
+ linux,phandle = <0x04>;
+ phandle = <0x04>;
+ };
+
+ cpu@101 {
+ compatible = "arm,cortex-a53\0arm,armv8";
+ reg = <0x00 0x101>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <0x0e>;
+ clocks = <0x09 0x01>;
+ cpu-idle-states = <0x0a 0x0b>;
+ sched-energy-costs = <0x0f 0x10>;
+ #cooling-cells = <0x02>;
+ dynamic-power-coefficient = <0x8c>;
+ linux,phandle = <0x05>;
+ phandle = <0x05>;
+ };
+
+ cpu@102 {
+ compatible = "arm,cortex-a53\0arm,armv8";
+ reg = <0x00 0x102>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <0x0e>;
+ clocks = <0x09 0x01>;
+ cpu-idle-states = <0x0a 0x0b>;
+ sched-energy-costs = <0x0f 0x10>;
+ #cooling-cells = <0x02>;
+ dynamic-power-coefficient = <0x8c>;
+ linux,phandle = <0x06>;
+ phandle = <0x06>;
+ };
+
+ cpu@103 {
+ compatible = "arm,cortex-a53\0arm,armv8";
+ reg = <0x00 0x103>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <0x0e>;
+ clocks = <0x09 0x01>;
+ cpu-idle-states = <0x0a 0x0b>;
+ sched-energy-costs = <0x0f 0x10>;
+ #cooling-cells = <0x02>;
+ dynamic-power-coefficient = <0x8c>;
+ linux,phandle = <0x07>;
+ phandle = <0x07>;
+ };
+
+ l2-cache0 {
+ compatible = "cache";
+ linux,phandle = <0x08>;
+ phandle = <0x08>;
+ };
+
+ l2-cache1 {
+ compatible = "cache";
+ linux,phandle = <0x0e>;
+ phandle = <0x0e>;
+ };
+
+ energy-costs {
+
+ core-cost0 {
+ busy-cost-data = <0x1f5 0xae 0x351 0x158 0x3ff 0x20e>;
+ idle-cost-data = <0x30 0x30 0x00 0x00>;
+ linux,phandle = <0x0c>;
+ phandle = <0x0c>;
+ };
+
+ core-cost1 {
+ busy-cost-data = <0x114 0x25 0x1f5 0x3b 0x251 0x75>;
+ idle-cost-data = <0x21 0x21 0x00 0x00>;
+ linux,phandle = <0x0f>;
+ phandle = <0x0f>;
+ };
+
+ cluster-cost0 {
+ busy-cost-data = <0x1f5 0x30 0x351 0x49 0x400 0x6b>;
+ idle-cost-data = <0x30 0x30 0x30 0x12>;
+ linux,phandle = <0x0d>;
+ phandle = <0x0d>;
+ };
+
+ cluster-cost1 {
+ busy-cost-data = <0x114 0x29 0x1f5 0x56 0x251 0x6b>;
+ idle-cost-data = <0x29 0x29 0x29 0x0e>;
+ linux,phandle = <0x10>;
+ phandle = <0x10>;
+ };
+ };
+ };
+
+ pmu_a72 {
+ compatible = "arm,cortex-a72-pmu";
+ interrupts = <0x00 0x02 0x04 0x00 0x06 0x04>;
+ interrupt-affinity = <0x02 0x03>;
+ };
+
+ pmu_a53 {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = <0x00 0x12 0x04 0x00 0x16 0x04 0x00 0x1a 0x04 0x00 0x1e 0x04>;
+ interrupt-affinity = <0x04 0x05 0x06 0x07>;
+ };
+
+ timer@2a810000 {
+ compatible = "arm,armv7-timer-mem";
+ reg = <0x00 0x2a810000 0x00 0x10000>;
+ clock-frequency = <0x2faf080>;
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ ranges;
+ status = "okay";
+
+ frame@2a830000 {
+ frame-number = <0x01>;
+ interrupts = <0x00 0x3c 0x04>;
+ reg = <0x00 0x2a830000 0x00 0x10000>;
+ };
+ };
+
+ mhu@2b1f0000 {
+ compatible = "arm,mhu\0arm,primecell";
+ reg = <0x00 0x2b1f0000 0x00 0x1000>;
+ interrupts = <0x00 0x24 0x04 0x00 0x23 0x04>;
+ interrupt-names = "mhu_lpri_rx\0mhu_hpri_rx";
+ #mbox-cells = <0x01>;
+ clocks = <0x11>;
+ clock-names = "apb_pclk";
+ linux,phandle = <0x13>;
+ phandle = <0x13>;
+ };
+
+ interrupt-controller@2c010000 {
+ compatible = "arm,gic-400\0arm,cortex-a15-gic";
+ reg = <0x00 0x2c010000 0x00 0x1000
+ 0x00 0x2c02f000 0x00 0x2000
+ 0x00 0x2c04f000 0x00 0x2000
+ 0x00 0x2c06f000 0x00 0x2000>;
+ #address-cells = <0x02>;
+ #interrupt-cells = <0x03>;
+ #size-cells = <0x02>;
+ interrupt-controller;
+ interrupts = <0x01 0x09 0x3f04>;
+ ranges = <0x00 0x00 0x00 0x2c1c0000 0x00 0x40000>;
+ linux,phandle = <0x01>;
+ phandle = <0x01>;
+
+ v2m@0 {
+ compatible = "arm,gic-v2m-frame";
+ msi-controller;
+ reg = <0x00 0x00 0x00 0x1000>;
+ linux,phandle = <0x12>;
+ phandle = <0x12>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <0x01 0x0d 0x3f08 0x01 0x0e 0x3f08 0x01 0x0b 0x3f08 0x01 0x0a 0x3f08>;
+ };
+
+ sram@2e000000 {
+ compatible = "arm,juno-sram-ns\0mmio-sram";
+ reg = <0x00 0x2e000000 0x00 0x8000>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ ranges = <0x00 0x00 0x2e000000 0x8000>;
+
+ scp-shmem@0 {
+ compatible = "arm,juno-scp-shmem";
+ reg = <0x00 0x200>;
+ };
+
+ scp-shmem@200 {
+ compatible = "arm,juno-scp-shmem";
+ reg = <0x200 0x200>;
+ linux,phandle = <0x14>;
+ phandle = <0x14>;
+ };
+ };
+
+ pcie-controller@40000000 {
+ compatible = "arm,juno-r1-pcie\0plda,xpressrich3-axi\0pci-host-ecam-generic";
+ device_type = "pci";
+ reg = <0x00 0x40000000 0x00 0x10000000>;
+ bus-range = <0x00 0xff>;
+ linux,pci-domain = <0x00>;
+ #address-cells = <0x03>;
+ #size-cells = <0x02>;
+ dma-coherent;
+ ranges = <0x1000000 0x00 0x00 0x00
+ 0x5f800000 0x00 0x800000 0x2000000
+ 0x00 0x50000000 0x00 0x50000000
+ 0x00 0x8000000 0x42000000 0x40
+ 0x00 0x40 0x00 0x01 0x00>;
+ #interrupt-cells = <0x01>;
+ interrupt-map-mask = <0x00 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x01 0x00 0x00 0x00
+ 0x88 0x04 0x00 0x00 0x00 0x02 0x01 0x00
+ 0x00 0x00 0x89 0x04 0x00 0x00 0x00 0x03
+ 0x01 0x00 0x00 0x00 0x8a 0x04 0x00 0x00
+ 0x00 0x04 0x01 0x00 0x00 0x00 0x8b 0x04>;
+ msi-parent = <0x12>;
+ status = "okay";
+ };
+
+ scpi {
+ compatible = "arm,scpi";
+ mboxes = <0x13 0x01>;
+ shmem = <0x14>;
+
+ clocks {
+ compatible = "arm,scpi-clocks";
+
+ scpi-dvfs {
+ compatible = "arm,scpi-dvfs-clocks";
+ #clock-cells = <0x01>;
+ clock-indices = <0x00 0x01 0x02>;
+ clock-output-names = "atlclk\0aplclk\0clk_mali";
+ linux,phandle = <0x09>;
+ phandle = <0x09>;
+ };
+
+ scpi-clk {
+ compatible = "arm,scpi-variable-clocks";
+ #clock-cells = <0x01>;
+ clock-indices = <0x03 0x04 0x05>;
+ clock-output-names = "pxlclk\0pxlclk1\0i2sclk";
+ linux,phandle = <0x19>;
+ phandle = <0x19>;
+ };
+ };
+
+ scpi-power-domains {
+ compatible = "arm,scpi-power-domains";
+ num-domains = <0x02>;
+ #power-domain-cells = <0x01>;
+ linux,phandle = <0x22>;
+ phandle = <0x22>;
+ };
+
+ sensors {
+ compatible = "arm,scpi-sensors";
+ #thermal-sensor-cells = <0x01>;
+ linux,phandle = <0x15>;
+ phandle = <0x15>;
+ };
+ };
+
+ thermal-zones {
+
+ pmic {
+ polling-delay = <0x3e8>;
+ polling-delay-passive = <0x64>;
+ thermal-sensors = <0x15 0x00>;
+ };
+
+ soc {
+ polling-delay = <0x3e8>;
+ polling-delay-passive = <0x64>;
+ sustainable-power = <0x9c4>;
+ thermal-sensors = <0x15 0x03>;
+
+ trips {
+
+ threshold {
+ temperature = <0xd6d8>;
+ hysteresis = <0x3e8>;
+ type = "passive";
+ };
+
+ target {
+ temperature = <0xfde8>;
+ hysteresis = <0x3e8>;
+ type = "passive";
+ linux,phandle = <0x16>;
+ phandle = <0x16>;
+ };
+ };
+
+ cooling-maps {
+
+ map0 {
+ trip = <0x16>;
+ cooling-device = <0x04 0xffffffff 0xffffffff>;
+ contribution = <0x800>;
+ };
+
+ map1 {
+ trip = <0x16>;
+ contribution = <0x400>;
+ cooling-device = <0x02 0xffffffff 0xffffffff>;
+ };
+
+ map2 {
+ trip = <0x16>;
+ cooling-device = <0x17 0xffffffff 0xffffffff>;
+ contribution = <0x400>;
+ };
+ };
+ };
+
+ big_cluster {
+ polling-delay = <0x3e8>;
+ polling-delay-passive = <0x64>;
+ thermal-sensors = <0x15 0x15>;
+ status = "okay";
+ };
+
+ little_cluster {
+ polling-delay = <0x3e8>;
+ polling-delay-passive = <0x64>;
+ thermal-sensors = <0x15 0x16>;
+ status = "okay";
+ };
+
+ gpu0 {
+ polling-delay = <0x3e8>;
+ polling-delay-passive = <0x64>;
+ thermal-sensors = <0x15 0x17>;
+ status = "okay";
+ };
+
+ gpu1 {
+ polling-delay = <0x3e8>;
+ polling-delay-passive = <0x64>;
+ thermal-sensors = <0x15 0x18>;
+ status = "okay";
+ };
+ };
+
+ refclk7273800hz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x6efd48>;
+ clock-output-names = "juno:uartclk";
+ linux,phandle = <0x1b>;
+ phandle = <0x1b>;
+ };
+
+ clk48mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x2dc6c00>;
+ clock-output-names = "clk48mhz";
+ linux,phandle = <0x1e>;
+ phandle = <0x1e>;
+ };
+
+ clk50mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x2faf080>;
+ clock-output-names = "smc_clk";
+ linux,phandle = <0x1c>;
+ phandle = <0x1c>;
+ };
+
+ refclk100mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x5f5e100>;
+ clock-output-names = "apb_pclk";
+ linux,phandle = <0x11>;
+ phandle = <0x11>;
+ };
+
+ refclk400mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x17d78400>;
+ clock-output-names = "faxi_clk";
+ linux,phandle = <0x18>;
+ phandle = <0x18>;
+ };
+
+ dma@7ff00000 {
+ compatible = "arm,pl330\0arm,primecell";
+ reg = <0x00 0x7ff00000 0x00 0x1000>;
+ #dma-cells = <0x01>;
+ #dma-channels = <0x08>;
+ #dma-requests = <0x20>;
+ interrupts = <0x00 0x58 0x04 0x00 0x59 0x04 0x00 0x5a
+ 0x04 0x00 0x5b 0x04 0x00 0x5c 0x04 0x00
+ 0x6c 0x04 0x00 0x6d 0x04 0x00 0x6e 0x04
+ 0x00 0x6f 0x04>;
+ clocks = <0x18>;
+ clock-names = "apb_pclk";
+ linux,phandle = <0x1f>;
+ phandle = <0x1f>;
+ };
+
+ hdlcd@7ff60000 {
+ compatible = "arm,hdlcd";
+ reg = <0x00 0x7ff60000 0x00 0x1000>;
+ interrupts = <0x00 0x55 0x04>;
+ clocks = <0x19 0x03>;
+ clock-names = "pxlclk";
+
+ port {
+
+ hdlcd0-endpoint {
+ remote-endpoint = <0x1a>;
+ linux,phandle = <0x1d>;
+ phandle = <0x1d>;
+ };
+ };
+ };
+
+ uart@7ff80000 {
+ compatible = "arm,pl011\0arm,primecell";
+ reg = <0x00 0x7ff80000 0x00 0x1000>;
+ interrupts = <0x00 0x53 0x04>;
+ clocks = <0x1b 0x11>;
+ clock-names = "uartclk\0apb_pclk";
+ };
+
+ i2c@7ffa0000 {
+ compatible = "snps,designware-i2c";
+ reg = <0x00 0x7ffa0000 0x00 0x1000>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ interrupts = <0x00 0x68 0x04>;
+ clock-frequency = <0x186a0>;
+ i2c-sda-hold-time-ns = <0x1f4>;
+ clocks = <0x1c>;
+
+ hdmi-transmitter@70 {
+ compatible = "nxp,tda998x";
+ reg = <0x70>;
+ audio-ports = <0x03 0x04>;
+ audio-port-names = "i2s\0spdif";
+ #sound-dai-cells = <0x01>;
+ linux,phandle = <0x21>;
+ phandle = <0x21>;
+
+ port {
+
+ tda998x-0-endpoint {
+ remote-endpoint = <0x1d>;
+ linux,phandle = <0x1a>;
+ phandle = <0x1a>;
+ };
+ };
+ };
+
+ hdmi-transmitter@71 {
+ compatible = "nxp,tda998x";
+ reg = <0x71>;
+
+ port {
+ };
+ };
+ };
+
+ ohci@7ffb0000 {
+ compatible = "generic-ohci";
+ reg = <0x00 0x7ffb0000 0x00 0x10000>;
+ interrupts = <0x00 0x74 0x04>;
+ clocks = <0x1e>;
+ };
+
+ ehci@7ffc0000 {
+ compatible = "generic-ehci";
+ reg = <0x00 0x7ffc0000 0x00 0x10000>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x1e>;
+ };
+
+ memory-controller@7ffd0000 {
+ compatible = "arm,pl354\0arm,primecell";
+ reg = <0x00 0x7ffd0000 0x00 0x1000>;
+ interrupts = <0x00 0x56 0x04 0x00 0x57 0x04>;
+ clocks = <0x1c>;
+ clock-names = "apb_pclk";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x00 0x80000000 0x00 0x7f000000 0x08 0x80000000 0x01 0x80000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ ranges;
+
+ optee@0xfee00000 {
+ reg = <0x00 0xfee00000 0x00 0x200000>;
+ no-map;
+ };
+ };
+
+ i2s@7ff90000 {
+ compatible = "snps,designware-i2s";
+ reg = <0x00 0x7ff90000 0x00 0x1000>;
+ clocks = <0x19 0x05 0x11>;
+ clock-names = "i2sclk\0apb_pclk";
+ #sound-dai-cells = <0x00>;
+ dmas = <0x1f 0x05>;
+ dma-names = "tx";
+ linux,phandle = <0x20>;
+ phandle = <0x20>;
+ };
+
+ hdmi_audio@0 {
+ compatible = "linux,hdmi-audio";
+ #sound-dai-cells = <0x00>;
+ status = "okay";
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+
+ simple-audio-card,cpu {
+ sound-dai = <0x20>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <0x21 0x00>;
+ };
+ };
+
+ gpu@0x2d000000 {
+ compatible = "arm,malit6xx\0arm,mali-midgard";
+ #cooling-cells = <0x02>;
+ reg = <0x00 0x2d000000 0x00 0x4000>;
+ interrupts = <0x00 0x21 0x04 0x00 0x22 0x04 0x00 0x20 0x04>;
+ interrupt-names = "JOB\0MMU\0GPU";
+ clocks = <0x09 0x02>;
+ clock-names = "clk_mali";
+ power-domains = <0x22 0x01>;
+ linux,phandle = <0x17>;
+ phandle = <0x17>;
+
+ power_model {
+ compatible = "arm,mali-simple-power-model";
+ voltage = <0x320>;
+ frequency = <0x1f4>;
+ static-power = <0x1f4>;
+ dynamic-power = <0x5dc>;
+ ts = <0x4e20 0x7d0 0xffffffec 0x02>;
+ thermal-zone = "soc";
+ };
+ };
+
+ smb@08000000 {
+ compatible = "simple-bus";
+ #address-cells = <0x02>;
+ #size-cells = <0x01>;
+ ranges = <0x00 0x00 0x00 0x8000000
+ 0x4000000 0x01 0x00 0x00
+ 0x14000000 0x4000000 0x02 0x00
+ 0x00 0x18000000 0x4000000 0x03
+ 0x00 0x00 0x1c000000 0x4000000
+ 0x04 0x00 0x00 0xc000000
+ 0x4000000 0x05 0x00 0x00
+ 0x10000000 0x4000000>;
+ #interrupt-cells = <0x01>;
+ interrupt-map-mask = <0x00 0x00 0x0f>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x44
+ 0x04 0x00 0x00 0x01 0x01 0x00 0x00 0x00
+ 0x45 0x04 0x00 0x00 0x02 0x01 0x00 0x00
+ 0x00 0x46 0x04 0x00 0x00 0x03 0x01 0x00
+ 0x00 0x00 0xa0 0x04 0x00 0x00 0x04 0x01
+ 0x00 0x00 0x00 0xa1 0x04 0x00 0x00 0x05
+ 0x01 0x00 0x00 0x00 0xa2 0x04 0x00 0x00
+ 0x06 0x01 0x00 0x00 0x00 0xa3 0x04 0x00
+ 0x00 0x07 0x01 0x00 0x00 0x00 0xa4 0x04
+ 0x00 0x00 0x08 0x01 0x00 0x00 0x00 0xa5
+ 0x04 0x00 0x00 0x09 0x01 0x00 0x00 0x00
+ 0xa6 0x04 0x00 0x00 0x0a 0x01 0x00 0x00
+ 0x00 0xa7 0x04 0x00 0x00 0x0b 0x01 0x00
+ 0x00 0x00 0xa8 0x04 0x00 0x00 0x0c 0x01
+ 0x00 0x00 0x00 0xa9 0x04>;
+
+ clk24mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x16e3600>;
+ clock-output-names = "juno_mb:clk24mhz";
+ linux,phandle = <0x28>;
+ phandle = <0x28>;
+ };
+
+ clk25mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x17d7840>;
+ clock-output-names = "juno_mb:clk25mhz";
+ linux,phandle = <0x24>;
+ phandle = <0x24>;
+ };
+
+ refclk1mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0xf4240>;
+ clock-output-names = "juno_mb:refclk1mhz";
+ linux,phandle = <0x27>;
+ phandle = <0x27>;
+ };
+
+ refclk32khz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x8000>;
+ clock-output-names = "juno_mb:refclk32khz";
+ linux,phandle = <0x26>;
+ phandle = <0x26>;
+ };
+
+ motherboard {
+ compatible = "arm,vexpress,v2p-p1\0simple-bus";
+ #address-cells = <0x02>;
+ #size-cells = <0x01>;
+ #interrupt-cells = <0x01>;
+ ranges;
+ model = "V2M-Juno";
+ arm,hbi = <0x252>;
+ arm,vexpress,site = <0x00>;
+ arm,v2m-memory-map = "rs1";
+
+ mcc-sb-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "MCC_SB_3V3";
+ regulator-min-microvolt = <0x325aa0>;
+ regulator-max-microvolt = <0x325aa0>;
+ regulator-always-on;
+ linux,phandle = <0x25>;
+ phandle = <0x25>;
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+
+ power-button {
+ debounce_interval = <0x32>;
+ wakeup-source;
+ linux,code = <0x74>;
+ label = "POWER";
+ gpios = <0x23 0x00 0x04>;
+ };
+
+ home-button {
+ debounce_interval = <0x32>;
+ wakeup-source;
+ linux,code = <0x66>;
+ label = "HOME";
+ gpios = <0x23 0x01 0x04>;
+ };
+
+ rlock-button {
+ debounce_interval = <0x32>;
+ wakeup-source;
+ linux,code = <0x98>;
+ label = "RLOCK";
+ gpios = <0x23 0x02 0x04>;
+ };
+
+ vol-up-button {
+ debounce_interval = <0x32>;
+ wakeup-source;
+ linux,code = <0x73>;
+ label = "VOL+";
+ gpios = <0x23 0x03 0x04>;
+ };
+
+ vol-down-button {
+ debounce_interval = <0x32>;
+ wakeup-source;
+ linux,code = <0x72>;
+ label = "VOL-";
+ gpios = <0x23 0x04 0x04>;
+ };
+
+ nmi-button {
+ debounce_interval = <0x32>;
+ wakeup-source;
+ linux,code = <0x63>;
+ label = "NMI";
+ gpios = <0x23 0x05 0x04>;
+ };
+ };
+
+ flash@0,00000000 {
+ compatible = "arm,vexpress-flash\0cfi-flash";
+ linux,part-probe = "afs";
+ reg = <0x00 0x00 0x4000000>;
+ bank-width = <0x04>;
+ status = "disabled";
+ };
+
+ ethernet@2,00000000 {
+ compatible = "smsc,lan9118\0smsc,lan9115";
+ reg = <0x02 0x00 0x10000>;
+ interrupts = <0x03>;
+ phy-mode = "mii";
+ reg-io-width = <0x04>;
+ smsc,irq-active-high;
+ smsc,irq-push-pull;
+ clocks = <0x24>;
+ vdd33a-supply = <0x25>;
+ vddvario-supply = <0x25>;
+ status = "disabled";
+ };
+
+ usb@5,00000000 {
+ compatible = "nxp,usb-isp1763";
+ reg = <0x05 0x00 0x20000>;
+ bus-width = <0x10>;
+ interrupts = <0x04>;
+ };
+
+ iofpga@3,00000000 {
+ compatible = "arm,amba-bus\0simple-bus";
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ ranges = <0x00 0x03 0x00 0x200000>;
+
+ sysctl@020000 {
+ compatible = "arm,sp810\0arm,primecell";
+ reg = <0x20000 0x1000>;
+ clocks = <0x26 0x27 0x28>;
+ clock-names = "refclk\0timclk\0apb_pclk";
+ #clock-cells = <0x01>;
+ clock-output-names = "timerclken0\0timerclken1\0timerclken2\0timerclken3";
+ assigned-clocks = <0x29 0x00 0x29 0x01 0x29 0x03 0x29 0x03>;
+ assigned-clock-parents = <0x27 0x27 0x27 0x27>;
+ linux,phandle = <0x29>;
+ phandle = <0x29>;
+ };
+
+ apbregs@010000 {
+ compatible = "syscon\0simple-mfd";
+ reg = <0x10000 0x1000>;
+
+ led0 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x01>;
+ label = "vexpress:0";
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ led1 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x02>;
+ label = "vexpress:1";
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+
+ led2 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x04>;
+ label = "vexpress:2";
+ linux,default-trigger = "cpu0";
+ default-state = "off";
+ };
+
+ led3 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x08>;
+ label = "vexpress:3";
+ linux,default-trigger = "cpu1";
+ default-state = "off";
+ };
+
+ led4 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x10>;
+ label = "vexpress:4";
+ linux,default-trigger = "cpu2";
+ default-state = "off";
+ };
+
+ led5 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x20>;
+ label = "vexpress:5";
+ linux,default-trigger = "cpu3";
+ default-state = "off";
+ };
+
+ led6 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x40>;
+ label = "vexpress:6";
+ default-state = "off";
+ };
+
+ led7 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x80>;
+ label = "vexpress:7";
+ default-state = "off";
+ };
+ };
+
+ mmci@050000 {
+ compatible = "arm,pl180\0arm,primecell";
+ reg = <0x50000 0x1000>;
+ interrupts = <0x05>;
+ max-frequency = <0xb71b00>;
+ vmmc-supply = <0x25>;
+ clocks = <0x28 0x1c>;
+ clock-names = "mclk\0apb_pclk";
+ };
+
+ kmi@060000 {
+ compatible = "arm,pl050\0arm,primecell";
+ reg = <0x60000 0x1000>;
+ interrupts = <0x08>;
+ clocks = <0x28 0x1c>;
+ clock-names = "KMIREFCLK\0apb_pclk";
+ };
+
+ kmi@070000 {
+ compatible = "arm,pl050\0arm,primecell";
+ reg = <0x70000 0x1000>;
+ interrupts = <0x08>;
+ clocks = <0x28 0x1c>;
+ clock-names = "KMIREFCLK\0apb_pclk";
+ };
+
+ wdt@0f0000 {
+ compatible = "arm,sp805\0arm,primecell";
+ reg = <0xf0000 0x10000>;
+ interrupts = <0x07>;
+ clocks = <0x28 0x1c>;
+ clock-names = "wdogclk\0apb_pclk";
+ };
+
+ timer@110000 {
+ compatible = "arm,sp804\0arm,primecell";
+ reg = <0x110000 0x10000>;
+ interrupts = <0x09>;
+ clocks = <0x29 0x00 0x29 0x01 0x28>;
+ clock-names = "timclken1\0timclken2\0apb_pclk";
+ };
+
+ timer@120000 {
+ compatible = "arm,sp804\0arm,primecell";
+ reg = <0x120000 0x10000>;
+ interrupts = <0x09>;
+ clocks = <0x29 0x02 0x29 0x03 0x28>;
+ clock-names = "timclken1\0timclken2\0apb_pclk";
+ };
+
+ rtc@170000 {
+ compatible = "arm,pl031\0arm,primecell";
+ reg = <0x170000 0x10000>;
+ interrupts = <0x00>;
+ clocks = <0x1c>;
+ clock-names = "apb_pclk";
+ };
+
+ gpio@1d0000 {
+ compatible = "arm,pl061\0arm,primecell";
+ reg = <0x1d0000 0x1000>;
+ interrupts = <0x06>;
+ clocks = <0x1c>;
+ clock-names = "apb_pclk";
+ gpio-controller;
+ #gpio-cells = <0x02>;
+ interrupt-controller;
+ #interrupt-cells = <0x02>;
+ linux,phandle = <0x23>;
+ phandle = <0x23>;
+ };
+ };
+ };
+ };
+
+ tlx@60000000 {
+ compatible = "simple-bus";
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ ranges = <0x00 0x00 0x60000000 0x10000000>;
+ #interrupt-cells = <0x01>;
+ interrupt-map-mask = <0x00 0x00>;
+ interrupt-map = <0x00 0x00 0x01 0x00 0x00 0x00 0xa8 0x04>;
+ };
+
+ firmware {
+
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
+};
diff --git a/configs/vexpress_aemv8a_juno_defconfig b/configs/vexpress_aemv8a_juno_defconfig
index f6ff0e0a569..0d9914c32bf 100644
--- a/configs/vexpress_aemv8a_juno_defconfig
+++ b/configs/vexpress_aemv8a_juno_defconfig
@@ -51,3 +51,4 @@ CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_GENERIC=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_GENERIC=y
+CONFIG_DEFAULT_DEVICE_TREE="juno-r2"
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (7 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 08/25] arm: vexpress: Add a devicetree file for juno Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 17:40 ` Oleksandr Andrushchenko
2021-12-02 15:59 ` [PATCH v6 10/25] arm: octeontx: " Simon Glass
` (17 subsequent siblings)
26 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Albert Aribaud, Anastasiia Lukianenko, Oleksandr Andrushchenko
Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.
The build instructions in U-Boot do not provide enough detail to build a
useful devicetree, unfortunately.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/dts/Makefile | 2 ++
arch/arm/dts/xenguest-arm64.dts | 15 +++++++++++++++
configs/xenguest_arm64_defconfig | 2 +-
3 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/xenguest-arm64.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d53bae2c350..f6345988c8c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1140,6 +1140,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt8516-pumpkin.dtb \
mt8518-ap1-emmc.dtb
+dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
+
dtb-$(CONFIG_TARGET_GE_BX50V3) += \
imx6q-bx50v3.dtb \
imx6q-b850v3.dtb \
diff --git a/arch/arm/dts/xenguest-arm64.dts b/arch/arm/dts/xenguest-arm64.dts
new file mode 100644
index 00000000000..52d3b062248
--- /dev/null
+++ b/arch/arm/dts/xenguest-arm64.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Dummy devicetre file for xenguest_arm64
+ *
+ * This is required to make the board build with CONFIG OF_SEPARATE
+ * Build instructions at xenguest_arm64.rst are inadequate for obtaining a real
+ * devicetree.
+ *
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+};
diff --git a/configs/xenguest_arm64_defconfig b/configs/xenguest_arm64_defconfig
index 8d9d9133a2e..edce34346d3 100644
--- a/configs/xenguest_arm64_defconfig
+++ b/configs/xenguest_arm64_defconfig
@@ -3,7 +3,7 @@ CONFIG_POSITION_INDEPENDENT=y
CONFIG_TARGET_XENGUEST_ARM64=y
CONFIG_SYS_TEXT_BASE=0x40080000
CONFIG_SYS_MALLOC_LEN=0x2000000
-CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="xenguest-arm64"
CONFIG_IDENT_STRING=" xenguest"
CONFIG_SYS_LOAD_ADDR=0x40000000
CONFIG_BOOTDELAY=10
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-02 15:59 ` [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file Simon Glass
@ 2021-12-02 17:40 ` Oleksandr Andrushchenko
2021-12-02 17:56 ` Tom Rini
2021-12-02 17:57 ` Simon Glass
0 siblings, 2 replies; 136+ messages in thread
From: Oleksandr Andrushchenko @ 2021-12-02 17:40 UTC (permalink / raw)
To: Simon Glass, U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Albert Aribaud,
Anastasiia Lukianenko
Hi, Simon!
Sorry for being late to the party
On 02.12.21 17:59, Simon Glass wrote:
> Add an empty file to prevent build errors when building with
> CONFIG_OF_SEPARATE enabled.
>
> The build instructions in U-Boot do not provide enough detail to build a
> useful devicetree, unfortunately.
Xen guest doesn't use any built-in device trees as the guest's device tree is provided
by the Xen hypervisor itself and is generated at the virtual machine creation time: it is
populated with memory size, number of CPUs etc. based on [1].
So, even if we provide some device tree here it must not be used by U-boot at
the end of the day. Thus, it might be a reasonable solution to provide an empty device
tree as you do, but put a comment that it is not used.
Thank you,
Oleksandr
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> (no changes since v1)
>
> arch/arm/dts/Makefile | 2 ++
> arch/arm/dts/xenguest-arm64.dts | 15 +++++++++++++++
> configs/xenguest_arm64_defconfig | 2 +-
> 3 files changed, 18 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/xenguest-arm64.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index d53bae2c350..f6345988c8c 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1140,6 +1140,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
> mt8516-pumpkin.dtb \
> mt8518-ap1-emmc.dtb
>
> +dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
> +
> dtb-$(CONFIG_TARGET_GE_BX50V3) += \
> imx6q-bx50v3.dtb \
> imx6q-b850v3.dtb \
> diff --git a/arch/arm/dts/xenguest-arm64.dts b/arch/arm/dts/xenguest-arm64.dts
> new file mode 100644
> index 00000000000..52d3b062248
> --- /dev/null
> +++ b/arch/arm/dts/xenguest-arm64.dts
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Dummy devicetre file for xenguest_arm64
> + *
> + * This is required to make the board build with CONFIG OF_SEPARATE
> + * Build instructions at xenguest_arm64.rst are inadequate for obtaining a real
> + * devicetree.
> + *
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +
> +/ {
> +};
> diff --git a/configs/xenguest_arm64_defconfig b/configs/xenguest_arm64_defconfig
> index 8d9d9133a2e..edce34346d3 100644
> --- a/configs/xenguest_arm64_defconfig
> +++ b/configs/xenguest_arm64_defconfig
> @@ -3,7 +3,7 @@ CONFIG_POSITION_INDEPENDENT=y
> CONFIG_TARGET_XENGUEST_ARM64=y
> CONFIG_SYS_TEXT_BASE=0x40080000
> CONFIG_SYS_MALLOC_LEN=0x2000000
> -CONFIG_SYS_MALLOC_F_LEN=0x2000
> +CONFIG_DEFAULT_DEVICE_TREE="xenguest-arm64"
> CONFIG_IDENT_STRING=" xenguest"
> CONFIG_SYS_LOAD_ADDR=0x40000000
> CONFIG_BOOTDELAY=10
[1] https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-02 17:40 ` Oleksandr Andrushchenko
@ 2021-12-02 17:56 ` Tom Rini
2021-12-02 18:05 ` Simon Glass
2021-12-02 17:57 ` Simon Glass
1 sibling, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-02 17:56 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: Simon Glass, U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Albert Aribaud, Anastasiia Lukianenko
[-- Attachment #1: Type: text/plain, Size: 967 bytes --]
On Thu, Dec 02, 2021 at 05:40:46PM +0000, Oleksandr Andrushchenko wrote:
> Hi, Simon!
>
> Sorry for being late to the party
>
> On 02.12.21 17:59, Simon Glass wrote:
> > Add an empty file to prevent build errors when building with
> > CONFIG_OF_SEPARATE enabled.
> >
> > The build instructions in U-Boot do not provide enough detail to build a
> > useful devicetree, unfortunately.
> Xen guest doesn't use any built-in device trees as the guest's device tree is provided
> by the Xen hypervisor itself and is generated at the virtual machine creation time: it is
> populated with memory size, number of CPUs etc. based on [1].
> So, even if we provide some device tree here it must not be used by U-boot at
> the end of the day. Thus, it might be a reasonable solution to provide an empty device
> tree as you do, but put a comment that it is not used.
So another example of why this series is taking things in the wrong
direction.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-02 17:56 ` Tom Rini
@ 2021-12-02 18:05 ` Simon Glass
2021-12-02 18:07 ` Tom Rini
2021-12-02 18:16 ` François Ozog
0 siblings, 2 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 18:05 UTC (permalink / raw)
To: Tom Rini
Cc: Oleksandr Andrushchenko, U-Boot Mailing List, Mark Kettenis,
Sean Anderson, Ilias Apalodimas, François Ozog,
Heinrich Schuchardt, Albert Aribaud, Anastasiia Lukianenko
Hi Tom,
On Thu, 2 Dec 2021 at 10:56, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 02, 2021 at 05:40:46PM +0000, Oleksandr Andrushchenko wrote:
> > Hi, Simon!
> >
> > Sorry for being late to the party
> >
> > On 02.12.21 17:59, Simon Glass wrote:
> > > Add an empty file to prevent build errors when building with
> > > CONFIG_OF_SEPARATE enabled.
> > >
> > > The build instructions in U-Boot do not provide enough detail to build a
> > > useful devicetree, unfortunately.
> > Xen guest doesn't use any built-in device trees as the guest's device tree is provided
> > by the Xen hypervisor itself and is generated at the virtual machine creation time: it is
> > populated with memory size, number of CPUs etc. based on [1].
> > So, even if we provide some device tree here it must not be used by U-boot at
> > the end of the day. Thus, it might be a reasonable solution to provide an empty device
> > tree as you do, but put a comment that it is not used.
>
> So another example of why this series is taking things in the wrong
> direction.
Why? At least we might figure out where to get the DT and how to run
Xen with U-Boot. I don't see any down-side to having a basic DT in the
tree along with instructions on how to run Xen.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-02 18:05 ` Simon Glass
@ 2021-12-02 18:07 ` Tom Rini
2021-12-02 18:16 ` François Ozog
1 sibling, 0 replies; 136+ messages in thread
From: Tom Rini @ 2021-12-02 18:07 UTC (permalink / raw)
To: Simon Glass
Cc: Oleksandr Andrushchenko, U-Boot Mailing List, Mark Kettenis,
Sean Anderson, Ilias Apalodimas, François Ozog,
Heinrich Schuchardt, Albert Aribaud, Anastasiia Lukianenko
[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]
On Thu, Dec 02, 2021 at 11:05:16AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 2 Dec 2021 at 10:56, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 02, 2021 at 05:40:46PM +0000, Oleksandr Andrushchenko wrote:
> > > Hi, Simon!
> > >
> > > Sorry for being late to the party
> > >
> > > On 02.12.21 17:59, Simon Glass wrote:
> > > > Add an empty file to prevent build errors when building with
> > > > CONFIG_OF_SEPARATE enabled.
> > > >
> > > > The build instructions in U-Boot do not provide enough detail to build a
> > > > useful devicetree, unfortunately.
> > > Xen guest doesn't use any built-in device trees as the guest's device tree is provided
> > > by the Xen hypervisor itself and is generated at the virtual machine creation time: it is
> > > populated with memory size, number of CPUs etc. based on [1].
> > > So, even if we provide some device tree here it must not be used by U-boot at
> > > the end of the day. Thus, it might be a reasonable solution to provide an empty device
> > > tree as you do, but put a comment that it is not used.
> >
> > So another example of why this series is taking things in the wrong
> > direction.
>
> Why? At least we might figure out where to get the DT and how to run
> Xen with U-Boot. I don't see any down-side to having a basic DT in the
> tree along with instructions on how to run Xen.
I agree with everything except "a basic DT in the tree". It's not used.
If you're going to do something with it, the instructions on where the
DT comes from will get you there. If the instructions are something
like "Well, it's actually horribly complex and depends on what you're
doing Xen on and ...", then that's even more of an argument for not
having "a basic DT" that will be misleading as well.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-02 18:05 ` Simon Glass
2021-12-02 18:07 ` Tom Rini
@ 2021-12-02 18:16 ` François Ozog
2021-12-02 18:29 ` Simon Glass
1 sibling, 1 reply; 136+ messages in thread
From: François Ozog @ 2021-12-02 18:16 UTC (permalink / raw)
To: Simon Glass
Cc: Tom Rini, Oleksandr Andrushchenko, U-Boot Mailing List,
Mark Kettenis, Sean Anderson, Ilias Apalodimas,
Heinrich Schuchardt, Albert Aribaud, Anastasiia Lukianenko
Hi Simon
On Thu, 2 Dec 2021 at 19:05, Simon Glass <sjg@chromium.org> wrote:
> Hi Tom,
>
> On Thu, 2 Dec 2021 at 10:56, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 02, 2021 at 05:40:46PM +0000, Oleksandr Andrushchenko wrote:
> > > Hi, Simon!
> > >
> > > Sorry for being late to the party
> > >
> > > On 02.12.21 17:59, Simon Glass wrote:
> > > > Add an empty file to prevent build errors when building with
> > > > CONFIG_OF_SEPARATE enabled.
> > > >
> > > > The build instructions in U-Boot do not provide enough detail to
> build a
> > > > useful devicetree, unfortunately.
> > > Xen guest doesn't use any built-in device trees as the guest's device
> tree is provided
> > > by the Xen hypervisor itself and is generated at the virtual machine
> creation time: it is
> > > populated with memory size, number of CPUs etc. based on [1].
> > > So, even if we provide some device tree here it must not be used by
> U-boot at
> > > the end of the day. Thus, it might be a reasonable solution to provide
> an empty device
> > > tree as you do, but put a comment that it is not used.
> >
> > So another example of why this series is taking things in the wrong
> > direction.
>
> Why?
I only had that comment in mind: "there is none so deaf as he who will not
hear."
> At least we might figure out where to get the DT and how to run
> Xen with U-Boot. I don't see any down-side to having a basic DT in the
> tree along with instructions on how to run Xen.
>
If an EMPTY device is what is required to pass current build constraints,
so be it, and let's correct that in a later patch. And EMPTY is not basic.
> Regards,
> Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-02 18:16 ` François Ozog
@ 2021-12-02 18:29 ` Simon Glass
2021-12-02 18:44 ` François Ozog
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 18:29 UTC (permalink / raw)
To: François Ozog
Cc: Tom Rini, Oleksandr Andrushchenko, U-Boot Mailing List,
Mark Kettenis, Sean Anderson, Ilias Apalodimas,
Heinrich Schuchardt, Albert Aribaud, Anastasiia Lukianenko
Hi François,
On Thu, 2 Dec 2021 at 11:17, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon
>
> On Thu, 2 Dec 2021 at 19:05, Simon Glass <sjg@chromium.org> wrote:
>>
>> Hi Tom,
>>
>> On Thu, 2 Dec 2021 at 10:56, Tom Rini <trini@konsulko.com> wrote:
>> >
>> > On Thu, Dec 02, 2021 at 05:40:46PM +0000, Oleksandr Andrushchenko wrote:
>> > > Hi, Simon!
>> > >
>> > > Sorry for being late to the party
>> > >
>> > > On 02.12.21 17:59, Simon Glass wrote:
>> > > > Add an empty file to prevent build errors when building with
>> > > > CONFIG_OF_SEPARATE enabled.
>> > > >
>> > > > The build instructions in U-Boot do not provide enough detail to build a
>> > > > useful devicetree, unfortunately.
>> > > Xen guest doesn't use any built-in device trees as the guest's device tree is provided
>> > > by the Xen hypervisor itself and is generated at the virtual machine creation time: it is
>> > > populated with memory size, number of CPUs etc. based on [1].
>> > > So, even if we provide some device tree here it must not be used by U-boot at
>> > > the end of the day. Thus, it might be a reasonable solution to provide an empty device
>> > > tree as you do, but put a comment that it is not used.
>> >
>> > So another example of why this series is taking things in the wrong
>> > direction.
>>
>> Why?
>
> I only had that comment in mind: "there is none so deaf as he who will not hear."
Hey, stop the pile-on. It's not useful.
I've guided U-Boot's use of devicetree for 10 years successfully. The
current state is a mess and I just to straighten it out.
>>
>> At least we might figure out where to get the DT and how to run
>> Xen with U-Boot. I don't see any down-side to having a basic DT in the
>> tree along with instructions on how to run Xen.
>
> If an EMPTY device is what is required to pass current build constraints, so be it, and let's correct that in a later patch. And EMPTY is not basic.
The problem here is a difference in philosophy around device tree.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-02 18:29 ` Simon Glass
@ 2021-12-02 18:44 ` François Ozog
2021-12-02 19:23 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: François Ozog @ 2021-12-02 18:44 UTC (permalink / raw)
To: Simon Glass
Cc: Tom Rini, Oleksandr Andrushchenko, U-Boot Mailing List,
Mark Kettenis, Sean Anderson, Ilias Apalodimas,
Heinrich Schuchardt, Albert Aribaud, Anastasiia Lukianenko
Hi Simon
On Thu, 2 Dec 2021 at 19:29, Simon Glass <sjg@chromium.org> wrote:
> Hi François,
>
> On Thu, 2 Dec 2021 at 11:17, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> > Hi Simon
> >
> > On Thu, 2 Dec 2021 at 19:05, Simon Glass <sjg@chromium.org> wrote:
> >>
> >> Hi Tom,
> >>
> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini <trini@konsulko.com> wrote:
> >> >
> >> > On Thu, Dec 02, 2021 at 05:40:46PM +0000, Oleksandr Andrushchenko
> wrote:
> >> > > Hi, Simon!
> >> > >
> >> > > Sorry for being late to the party
> >> > >
> >> > > On 02.12.21 17:59, Simon Glass wrote:
> >> > > > Add an empty file to prevent build errors when building with
> >> > > > CONFIG_OF_SEPARATE enabled.
> >> > > >
> >> > > > The build instructions in U-Boot do not provide enough detail to
> build a
> >> > > > useful devicetree, unfortunately.
> >> > > Xen guest doesn't use any built-in device trees as the guest's
> device tree is provided
> >> > > by the Xen hypervisor itself and is generated at the virtual
> machine creation time: it is
> >> > > populated with memory size, number of CPUs etc. based on [1].
> >> > > So, even if we provide some device tree here it must not be used by
> U-boot at
> >> > > the end of the day. Thus, it might be a reasonable solution to
> provide an empty device
> >> > > tree as you do, but put a comment that it is not used.
> >> >
> >> > So another example of why this series is taking things in the wrong
> >> > direction.
> >>
> >> Why?
> >
> > I only had that comment in mind: "there is none so deaf as he who will
> not hear."
>
> Hey, stop the pile-on. It's not useful.
>
> I've guided U-Boot's use of devicetree for 10 years successfully. The
> current state is a mess and I just to straighten it out.
>
> I admire your talent and knowledge.
I know you are 99,99% of the time correct and spot on for your comments in
many meetings we were attending.
When you questioned a number of points I made, I first tried to understand
what I got wrong because you said it.
And you were right ;-)
For this topic, I made every effort to come to your position, but
definitively can't.
>>
> >> At least we might figure out where to get the DT and how to run
> >> Xen with U-Boot. I don't see any down-side to having a basic DT in the
> >> tree along with instructions on how to run Xen.
> >
> > If an EMPTY device is what is required to pass current build
> constraints, so be it, and let's correct that in a later patch. And EMPTY
> is not basic.
>
> The problem here is a difference in philosophy around device tree.
>
> Indeed!
> Regards,
> Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-02 18:44 ` François Ozog
@ 2021-12-02 19:23 ` Simon Glass
2021-12-03 12:14 ` Tom Rini
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 19:23 UTC (permalink / raw)
To: François Ozog
Cc: Tom Rini, Oleksandr Andrushchenko, U-Boot Mailing List,
Mark Kettenis, Sean Anderson, Ilias Apalodimas,
Heinrich Schuchardt, Albert Aribaud, Anastasiia Lukianenko
Hi François,
On Thu, 2 Dec 2021 at 11:44, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon
>
> On Thu, 2 Dec 2021 at 19:29, Simon Glass <sjg@chromium.org> wrote:
>>
>> Hi François,
>>
>> On Thu, 2 Dec 2021 at 11:17, François Ozog <francois.ozog@linaro.org> wrote:
>> >
>> > Hi Simon
>> >
>> > On Thu, 2 Dec 2021 at 19:05, Simon Glass <sjg@chromium.org> wrote:
>> >>
>> >> Hi Tom,
>> >>
>> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini <trini@konsulko.com> wrote:
>> >> >
>> >> > On Thu, Dec 02, 2021 at 05:40:46PM +0000, Oleksandr Andrushchenko wrote:
>> >> > > Hi, Simon!
>> >> > >
>> >> > > Sorry for being late to the party
>> >> > >
>> >> > > On 02.12.21 17:59, Simon Glass wrote:
>> >> > > > Add an empty file to prevent build errors when building with
>> >> > > > CONFIG_OF_SEPARATE enabled.
>> >> > > >
>> >> > > > The build instructions in U-Boot do not provide enough detail to build a
>> >> > > > useful devicetree, unfortunately.
>> >> > > Xen guest doesn't use any built-in device trees as the guest's device tree is provided
>> >> > > by the Xen hypervisor itself and is generated at the virtual machine creation time: it is
>> >> > > populated with memory size, number of CPUs etc. based on [1].
>> >> > > So, even if we provide some device tree here it must not be used by U-boot at
>> >> > > the end of the day. Thus, it might be a reasonable solution to provide an empty device
>> >> > > tree as you do, but put a comment that it is not used.
>> >> >
>> >> > So another example of why this series is taking things in the wrong
>> >> > direction.
>> >>
>> >> Why?
>> >
>> > I only had that comment in mind: "there is none so deaf as he who will not hear."
>>
>> Hey, stop the pile-on. It's not useful.
>>
>> I've guided U-Boot's use of devicetree for 10 years successfully. The
>> current state is a mess and I just to straighten it out.
>>
> I admire your talent and knowledge.
> I know you are 99,99% of the time correct and spot on for your comments in many meetings we were attending.
> When you questioned a number of points I made, I first tried to understand what I got wrong because you said it.
> And you were right ;-)
> For this topic, I made every effort to come to your position, but definitively can't.
Thank you. I think this will come together in a few years when
devicetree is sorted out in U-Boot and Binman is more widely used.
For this series, if and when it is applied, I predict:
- it will not cause any confusion
- it will aid development
- it will help with discoverability, pressuring people to explain how
to build for their systems
- it will be a good basis for future work (we have a long list)
- everyone will wonder what the fuss was about
Here is the commit that introduced OF_PRIOR_STAGE. It attracted no
such push-back.
commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481
Author: Thomas Fitzsimmons <fitzsim@fitzsim.org>
Date: Fri Jun 8 17:59:45 2018 -0400
board: arm: Add support for Broadcom BCM7445
Add support for loading U-Boot on the Broadcom 7445 SoC. This port
assumes Broadcom's BOLT bootloader is acting as the second stage
bootloader, and U-Boot is acting as the third stage bootloader, loaded
as an ELF program by BOLT.
Signed-off-by: Thomas Fitzsimmons <fitzsim@fitzsim.org>
Cc: Stefan Roese <sr@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-02 19:23 ` Simon Glass
@ 2021-12-03 12:14 ` Tom Rini
2021-12-03 16:04 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-03 12:14 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Oleksandr Andrushchenko, U-Boot Mailing List,
Mark Kettenis, Sean Anderson, Ilias Apalodimas,
Heinrich Schuchardt, Albert Aribaud, Anastasiia Lukianenko
[-- Attachment #1: Type: text/plain, Size: 3924 bytes --]
On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote:
> Hi François,
>
> On Thu, 2 Dec 2021 at 11:44, François Ozog <francois.ozog@linaro.org> wrote:
> >
> > Hi Simon
> >
> > On Thu, 2 Dec 2021 at 19:29, Simon Glass <sjg@chromium.org> wrote:
> >>
> >> Hi François,
> >>
> >> On Thu, 2 Dec 2021 at 11:17, François Ozog <francois.ozog@linaro.org> wrote:
> >> >
> >> > Hi Simon
> >> >
> >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass <sjg@chromium.org> wrote:
> >> >>
> >> >> Hi Tom,
> >> >>
> >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini <trini@konsulko.com> wrote:
> >> >> >
> >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +0000, Oleksandr Andrushchenko wrote:
> >> >> > > Hi, Simon!
> >> >> > >
> >> >> > > Sorry for being late to the party
> >> >> > >
> >> >> > > On 02.12.21 17:59, Simon Glass wrote:
> >> >> > > > Add an empty file to prevent build errors when building with
> >> >> > > > CONFIG_OF_SEPARATE enabled.
> >> >> > > >
> >> >> > > > The build instructions in U-Boot do not provide enough detail to build a
> >> >> > > > useful devicetree, unfortunately.
> >> >> > > Xen guest doesn't use any built-in device trees as the guest's device tree is provided
> >> >> > > by the Xen hypervisor itself and is generated at the virtual machine creation time: it is
> >> >> > > populated with memory size, number of CPUs etc. based on [1].
> >> >> > > So, even if we provide some device tree here it must not be used by U-boot at
> >> >> > > the end of the day. Thus, it might be a reasonable solution to provide an empty device
> >> >> > > tree as you do, but put a comment that it is not used.
> >> >> >
> >> >> > So another example of why this series is taking things in the wrong
> >> >> > direction.
> >> >>
> >> >> Why?
> >> >
> >> > I only had that comment in mind: "there is none so deaf as he who will not hear."
> >>
> >> Hey, stop the pile-on. It's not useful.
> >>
> >> I've guided U-Boot's use of devicetree for 10 years successfully. The
> >> current state is a mess and I just to straighten it out.
> >>
> > I admire your talent and knowledge.
> > I know you are 99,99% of the time correct and spot on for your comments in many meetings we were attending.
> > When you questioned a number of points I made, I first tried to understand what I got wrong because you said it.
> > And you were right ;-)
> > For this topic, I made every effort to come to your position, but definitively can't.
>
> Thank you. I think this will come together in a few years when
> devicetree is sorted out in U-Boot and Binman is more widely used.
>
> For this series, if and when it is applied, I predict:
> - it will not cause any confusion
> - it will aid development
> - it will help with discoverability, pressuring people to explain how
> to build for their systems
> - it will be a good basis for future work (we have a long list)
> - everyone will wonder what the fuss was about
>
> Here is the commit that introduced OF_PRIOR_STAGE. It attracted no
> such push-back.
>
> commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481
> Author: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> Date: Fri Jun 8 17:59:45 2018 -0400
>
> board: arm: Add support for Broadcom BCM7445
>
> Add support for loading U-Boot on the Broadcom 7445 SoC. This port
> assumes Broadcom's BOLT bootloader is acting as the second stage
> bootloader, and U-Boot is acting as the third stage bootloader, loaded
> as an ELF program by BOLT.
>
> Signed-off-by: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> Cc: Stefan Roese <sr@denx.de>
> Cc: Tom Rini <trini@konsulko.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
I want to cycle back over here. Yes, historically a number of things
came in that perhaps shouldn't have. I went with "well, this is what we
need to handle this case I suppose" and applied it.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-03 12:14 ` Tom Rini
@ 2021-12-03 16:04 ` Simon Glass
2021-12-03 17:02 ` François Ozog
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-03 16:04 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Oleksandr Andrushchenko, U-Boot Mailing List,
Mark Kettenis, Sean Anderson, Ilias Apalodimas,
Heinrich Schuchardt, Albert Aribaud, Anastasiia Lukianenko
Hi Tom,
On Fri, 3 Dec 2021 at 05:14, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote:
> > Hi François,
> >
> > On Thu, 2 Dec 2021 at 11:44, François Ozog <francois.ozog@linaro.org> wrote:
> > >
> > > Hi Simon
> > >
> > > On Thu, 2 Dec 2021 at 19:29, Simon Glass <sjg@chromium.org> wrote:
> > >>
> > >> Hi François,
> > >>
> > >> On Thu, 2 Dec 2021 at 11:17, François Ozog <francois.ozog@linaro.org> wrote:
> > >> >
> > >> > Hi Simon
> > >> >
> > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass <sjg@chromium.org> wrote:
> > >> >>
> > >> >> Hi Tom,
> > >> >>
> > >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini <trini@konsulko.com> wrote:
> > >> >> >
> > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +0000, Oleksandr Andrushchenko wrote:
> > >> >> > > Hi, Simon!
> > >> >> > >
> > >> >> > > Sorry for being late to the party
> > >> >> > >
> > >> >> > > On 02.12.21 17:59, Simon Glass wrote:
> > >> >> > > > Add an empty file to prevent build errors when building with
> > >> >> > > > CONFIG_OF_SEPARATE enabled.
> > >> >> > > >
> > >> >> > > > The build instructions in U-Boot do not provide enough detail to build a
> > >> >> > > > useful devicetree, unfortunately.
> > >> >> > > Xen guest doesn't use any built-in device trees as the guest's device tree is provided
> > >> >> > > by the Xen hypervisor itself and is generated at the virtual machine creation time: it is
> > >> >> > > populated with memory size, number of CPUs etc. based on [1].
> > >> >> > > So, even if we provide some device tree here it must not be used by U-boot at
> > >> >> > > the end of the day. Thus, it might be a reasonable solution to provide an empty device
> > >> >> > > tree as you do, but put a comment that it is not used.
> > >> >> >
> > >> >> > So another example of why this series is taking things in the wrong
> > >> >> > direction.
> > >> >>
> > >> >> Why?
> > >> >
> > >> > I only had that comment in mind: "there is none so deaf as he who will not hear."
> > >>
> > >> Hey, stop the pile-on. It's not useful.
> > >>
> > >> I've guided U-Boot's use of devicetree for 10 years successfully. The
> > >> current state is a mess and I just to straighten it out.
> > >>
> > > I admire your talent and knowledge.
> > > I know you are 99,99% of the time correct and spot on for your comments in many meetings we were attending.
> > > When you questioned a number of points I made, I first tried to understand what I got wrong because you said it.
> > > And you were right ;-)
> > > For this topic, I made every effort to come to your position, but definitively can't.
> >
> > Thank you. I think this will come together in a few years when
> > devicetree is sorted out in U-Boot and Binman is more widely used.
> >
> > For this series, if and when it is applied, I predict:
> > - it will not cause any confusion
> > - it will aid development
> > - it will help with discoverability, pressuring people to explain how
> > to build for their systems
> > - it will be a good basis for future work (we have a long list)
> > - everyone will wonder what the fuss was about
> >
> > Here is the commit that introduced OF_PRIOR_STAGE. It attracted no
> > such push-back.
> >
> > commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481
> > Author: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> > Date: Fri Jun 8 17:59:45 2018 -0400
> >
> > board: arm: Add support for Broadcom BCM7445
> >
> > Add support for loading U-Boot on the Broadcom 7445 SoC. This port
> > assumes Broadcom's BOLT bootloader is acting as the second stage
> > bootloader, and U-Boot is acting as the third stage bootloader, loaded
> > as an ELF program by BOLT.
> >
> > Signed-off-by: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> > Cc: Stefan Roese <sr@denx.de>
> > Cc: Tom Rini <trini@konsulko.com>
> > Cc: Florian Fainelli <f.fainelli@gmail.com>
>
> I want to cycle back over here. Yes, historically a number of things
> came in that perhaps shouldn't have. I went with "well, this is what we
> need to handle this case I suppose" and applied it.
Yes and we need to move things forward. We can't just object to things
without an alternative. As I have mentioned before, I think, I did
actually review this (there was a question about sequence numbers or
something) and didn't even notice the devicetree thing! It should have
been a separate patch, I suppose. But even with the other patch
(OF_BOARD), I did not at the time understand the implications. I feel
very bad about the situation we are in and I wish I had thought it
through properly at the time. Mea culpa.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-03 16:04 ` Simon Glass
@ 2021-12-03 17:02 ` François Ozog
2021-12-03 20:14 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: François Ozog @ 2021-12-03 17:02 UTC (permalink / raw)
To: Simon Glass
Cc: Tom Rini, Oleksandr Andrushchenko, U-Boot Mailing List,
Mark Kettenis, Sean Anderson, Ilias Apalodimas,
Heinrich Schuchardt, Albert Aribaud, Anastasiia Lukianenko
On Fri, 3 Dec 2021 at 17:04, Simon Glass <sjg@chromium.org> wrote:
> Hi Tom,
>
> On Fri, 3 Dec 2021 at 05:14, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote:
> > > Hi François,
> > >
> > > On Thu, 2 Dec 2021 at 11:44, François Ozog <francois.ozog@linaro.org>
> wrote:
> > > >
> > > > Hi Simon
> > > >
> > > > On Thu, 2 Dec 2021 at 19:29, Simon Glass <sjg@chromium.org> wrote:
> > > >>
> > > >> Hi François,
> > > >>
> > > >> On Thu, 2 Dec 2021 at 11:17, François Ozog <
> francois.ozog@linaro.org> wrote:
> > > >> >
> > > >> > Hi Simon
> > > >> >
> > > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass <sjg@chromium.org>
> wrote:
> > > >> >>
> > > >> >> Hi Tom,
> > > >> >>
> > > >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini <trini@konsulko.com>
> wrote:
> > > >> >> >
> > > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +0000, Oleksandr
> Andrushchenko wrote:
> > > >> >> > > Hi, Simon!
> > > >> >> > >
> > > >> >> > > Sorry for being late to the party
> > > >> >> > >
> > > >> >> > > On 02.12.21 17:59, Simon Glass wrote:
> > > >> >> > > > Add an empty file to prevent build errors when building
> with
> > > >> >> > > > CONFIG_OF_SEPARATE enabled.
> > > >> >> > > >
> > > >> >> > > > The build instructions in U-Boot do not provide enough
> detail to build a
> > > >> >> > > > useful devicetree, unfortunately.
> > > >> >> > > Xen guest doesn't use any built-in device trees as the
> guest's device tree is provided
> > > >> >> > > by the Xen hypervisor itself and is generated at the virtual
> machine creation time: it is
> > > >> >> > > populated with memory size, number of CPUs etc. based on [1].
> > > >> >> > > So, even if we provide some device tree here it must not be
> used by U-boot at
> > > >> >> > > the end of the day. Thus, it might be a reasonable solution
> to provide an empty device
> > > >> >> > > tree as you do, but put a comment that it is not used.
> > > >> >> >
> > > >> >> > So another example of why this series is taking things in the
> wrong
> > > >> >> > direction.
> > > >> >>
> > > >> >> Why?
> > > >> >
> > > >> > I only had that comment in mind: "there is none so deaf as he who
> will not hear."
> > > >>
> > > >> Hey, stop the pile-on. It's not useful.
> > > >>
> > > >> I've guided U-Boot's use of devicetree for 10 years successfully.
> The
> > > >> current state is a mess and I just to straighten it out.
> > > >>
> > > > I admire your talent and knowledge.
> > > > I know you are 99,99% of the time correct and spot on for your
> comments in many meetings we were attending.
> > > > When you questioned a number of points I made, I first tried to
> understand what I got wrong because you said it.
> > > > And you were right ;-)
> > > > For this topic, I made every effort to come to your position, but
> definitively can't.
> > >
> > > Thank you. I think this will come together in a few years when
> > > devicetree is sorted out in U-Boot and Binman is more widely used.
> > >
> > > For this series, if and when it is applied, I predict:
> > > - it will not cause any confusion
> > > - it will aid development
> > > - it will help with discoverability, pressuring people to explain how
> > > to build for their systems
> > > - it will be a good basis for future work (we have a long list)
> > > - everyone will wonder what the fuss was about
> > >
> > > Here is the commit that introduced OF_PRIOR_STAGE. It attracted no
> > > such push-back.
> > >
> > > commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481
> > > Author: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> > > Date: Fri Jun 8 17:59:45 2018 -0400
> > >
> > > board: arm: Add support for Broadcom BCM7445
> > >
> > > Add support for loading U-Boot on the Broadcom 7445 SoC. This port
> > > assumes Broadcom's BOLT bootloader is acting as the second stage
> > > bootloader, and U-Boot is acting as the third stage bootloader,
> loaded
> > > as an ELF program by BOLT.
> > >
> > > Signed-off-by: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> > > Cc: Stefan Roese <sr@denx.de>
> > > Cc: Tom Rini <trini@konsulko.com>
> > > Cc: Florian Fainelli <f.fainelli@gmail.com>
> >
> > I want to cycle back over here. Yes, historically a number of things
> > came in that perhaps shouldn't have. I went with "well, this is what we
> > need to handle this case I suppose" and applied it.
>
> Yes and we need to move things forward. We can't just object to things
> without an alternative.
As far as I can follow the threads, I proposed the dts to be empty to pass
compilation and move forward, but I think you haven't replied. The empty
dts can contain a comment pointing to documentation, which could describe
the DT lifecycle of the platform, and a template dts that could be used for
adventurous developers.
> As I have mentioned before, I think, I did
> actually review this (there was a question about sequence numbers or
> something) and didn't even notice the devicetree thing! It should have
> been a separate patch, I suppose. But even with the other patch
> (OF_BOARD), I did not at the time understand the implications. I feel
> very bad about the situation we are in and I wish I had thought it
> through properly at the time. Mea culpa.
>
> Regards,
> Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-03 17:02 ` François Ozog
@ 2021-12-03 20:14 ` Simon Glass
2021-12-03 20:21 ` Tom Rini
2021-12-03 20:27 ` François Ozog
0 siblings, 2 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-03 20:14 UTC (permalink / raw)
To: François Ozog
Cc: Tom Rini, Oleksandr Andrushchenko, U-Boot Mailing List,
Mark Kettenis, Sean Anderson, Ilias Apalodimas,
Heinrich Schuchardt, Albert Aribaud, Anastasiia Lukianenko
Hi François,
On Fri, 3 Dec 2021 at 10:03, François Ozog <francois.ozog@linaro.org> wrote:
>
>
>
> On Fri, 3 Dec 2021 at 17:04, Simon Glass <sjg@chromium.org> wrote:
>>
>> Hi Tom,
>>
>> On Fri, 3 Dec 2021 at 05:14, Tom Rini <trini@konsulko.com> wrote:
>> >
>> > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote:
>> > > Hi François,
>> > >
>> > > On Thu, 2 Dec 2021 at 11:44, François Ozog <francois.ozog@linaro.org> wrote:
>> > > >
>> > > > Hi Simon
>> > > >
>> > > > On Thu, 2 Dec 2021 at 19:29, Simon Glass <sjg@chromium.org> wrote:
>> > > >>
>> > > >> Hi François,
>> > > >>
>> > > >> On Thu, 2 Dec 2021 at 11:17, François Ozog <francois.ozog@linaro.org> wrote:
>> > > >> >
>> > > >> > Hi Simon
>> > > >> >
>> > > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass <sjg@chromium.org> wrote:
>> > > >> >>
>> > > >> >> Hi Tom,
>> > > >> >>
>> > > >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini <trini@konsulko.com> wrote:
>> > > >> >> >
>> > > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +0000, Oleksandr Andrushchenko wrote:
>> > > >> >> > > Hi, Simon!
>> > > >> >> > >
>> > > >> >> > > Sorry for being late to the party
>> > > >> >> > >
>> > > >> >> > > On 02.12.21 17:59, Simon Glass wrote:
>> > > >> >> > > > Add an empty file to prevent build errors when building with
>> > > >> >> > > > CONFIG_OF_SEPARATE enabled.
>> > > >> >> > > >
>> > > >> >> > > > The build instructions in U-Boot do not provide enough detail to build a
>> > > >> >> > > > useful devicetree, unfortunately.
>> > > >> >> > > Xen guest doesn't use any built-in device trees as the guest's device tree is provided
>> > > >> >> > > by the Xen hypervisor itself and is generated at the virtual machine creation time: it is
>> > > >> >> > > populated with memory size, number of CPUs etc. based on [1].
>> > > >> >> > > So, even if we provide some device tree here it must not be used by U-boot at
>> > > >> >> > > the end of the day. Thus, it might be a reasonable solution to provide an empty device
>> > > >> >> > > tree as you do, but put a comment that it is not used.
>> > > >> >> >
>> > > >> >> > So another example of why this series is taking things in the wrong
>> > > >> >> > direction.
>> > > >> >>
>> > > >> >> Why?
>> > > >> >
>> > > >> > I only had that comment in mind: "there is none so deaf as he who will not hear."
>> > > >>
>> > > >> Hey, stop the pile-on. It's not useful.
>> > > >>
>> > > >> I've guided U-Boot's use of devicetree for 10 years successfully. The
>> > > >> current state is a mess and I just to straighten it out.
>> > > >>
>> > > > I admire your talent and knowledge.
>> > > > I know you are 99,99% of the time correct and spot on for your comments in many meetings we were attending.
>> > > > When you questioned a number of points I made, I first tried to understand what I got wrong because you said it.
>> > > > And you were right ;-)
>> > > > For this topic, I made every effort to come to your position, but definitively can't.
>> > >
>> > > Thank you. I think this will come together in a few years when
>> > > devicetree is sorted out in U-Boot and Binman is more widely used.
>> > >
>> > > For this series, if and when it is applied, I predict:
>> > > - it will not cause any confusion
>> > > - it will aid development
>> > > - it will help with discoverability, pressuring people to explain how
>> > > to build for their systems
>> > > - it will be a good basis for future work (we have a long list)
>> > > - everyone will wonder what the fuss was about
>> > >
>> > > Here is the commit that introduced OF_PRIOR_STAGE. It attracted no
>> > > such push-back.
>> > >
>> > > commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481
>> > > Author: Thomas Fitzsimmons <fitzsim@fitzsim.org>
>> > > Date: Fri Jun 8 17:59:45 2018 -0400
>> > >
>> > > board: arm: Add support for Broadcom BCM7445
>> > >
>> > > Add support for loading U-Boot on the Broadcom 7445 SoC. This port
>> > > assumes Broadcom's BOLT bootloader is acting as the second stage
>> > > bootloader, and U-Boot is acting as the third stage bootloader, loaded
>> > > as an ELF program by BOLT.
>> > >
>> > > Signed-off-by: Thomas Fitzsimmons <fitzsim@fitzsim.org>
>> > > Cc: Stefan Roese <sr@denx.de>
>> > > Cc: Tom Rini <trini@konsulko.com>
>> > > Cc: Florian Fainelli <f.fainelli@gmail.com>
>> >
>> > I want to cycle back over here. Yes, historically a number of things
>> > came in that perhaps shouldn't have. I went with "well, this is what we
>> > need to handle this case I suppose" and applied it.
>>
>> Yes and we need to move things forward. We can't just object to things
>> without an alternative.
>
> As far as I can follow the threads, I proposed the dts to be empty to pass compilation and move forward, but I think you haven't replied. The empty dts can contain a comment pointing to documentation, which could describe the DT lifecycle of the platform, and a template dts that could be used for adventurous developers.
That does not go far enough for me. We actually do want to be able to
build U-Boot and run it on the board, e.g. in a lab. We cannot do that
if there are manual instructions involved. The onus needs to be on
contributors to make their boards actually buildable/bootable with
U-Boot.
[..]
REgards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-03 20:14 ` Simon Glass
@ 2021-12-03 20:21 ` Tom Rini
2021-12-03 20:27 ` François Ozog
1 sibling, 0 replies; 136+ messages in thread
From: Tom Rini @ 2021-12-03 20:21 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Oleksandr Andrushchenko, U-Boot Mailing List,
Mark Kettenis, Sean Anderson, Ilias Apalodimas,
Heinrich Schuchardt, Albert Aribaud, Anastasiia Lukianenko
[-- Attachment #1: Type: text/plain, Size: 5835 bytes --]
On Fri, Dec 03, 2021 at 01:14:04PM -0700, Simon Glass wrote:
> Hi François,
>
> On Fri, 3 Dec 2021 at 10:03, François Ozog <francois.ozog@linaro.org> wrote:
> >
> >
> >
> > On Fri, 3 Dec 2021 at 17:04, Simon Glass <sjg@chromium.org> wrote:
> >>
> >> Hi Tom,
> >>
> >> On Fri, 3 Dec 2021 at 05:14, Tom Rini <trini@konsulko.com> wrote:
> >> >
> >> > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote:
> >> > > Hi François,
> >> > >
> >> > > On Thu, 2 Dec 2021 at 11:44, François Ozog <francois.ozog@linaro.org> wrote:
> >> > > >
> >> > > > Hi Simon
> >> > > >
> >> > > > On Thu, 2 Dec 2021 at 19:29, Simon Glass <sjg@chromium.org> wrote:
> >> > > >>
> >> > > >> Hi François,
> >> > > >>
> >> > > >> On Thu, 2 Dec 2021 at 11:17, François Ozog <francois.ozog@linaro.org> wrote:
> >> > > >> >
> >> > > >> > Hi Simon
> >> > > >> >
> >> > > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass <sjg@chromium.org> wrote:
> >> > > >> >>
> >> > > >> >> Hi Tom,
> >> > > >> >>
> >> > > >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini <trini@konsulko.com> wrote:
> >> > > >> >> >
> >> > > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +0000, Oleksandr Andrushchenko wrote:
> >> > > >> >> > > Hi, Simon!
> >> > > >> >> > >
> >> > > >> >> > > Sorry for being late to the party
> >> > > >> >> > >
> >> > > >> >> > > On 02.12.21 17:59, Simon Glass wrote:
> >> > > >> >> > > > Add an empty file to prevent build errors when building with
> >> > > >> >> > > > CONFIG_OF_SEPARATE enabled.
> >> > > >> >> > > >
> >> > > >> >> > > > The build instructions in U-Boot do not provide enough detail to build a
> >> > > >> >> > > > useful devicetree, unfortunately.
> >> > > >> >> > > Xen guest doesn't use any built-in device trees as the guest's device tree is provided
> >> > > >> >> > > by the Xen hypervisor itself and is generated at the virtual machine creation time: it is
> >> > > >> >> > > populated with memory size, number of CPUs etc. based on [1].
> >> > > >> >> > > So, even if we provide some device tree here it must not be used by U-boot at
> >> > > >> >> > > the end of the day. Thus, it might be a reasonable solution to provide an empty device
> >> > > >> >> > > tree as you do, but put a comment that it is not used.
> >> > > >> >> >
> >> > > >> >> > So another example of why this series is taking things in the wrong
> >> > > >> >> > direction.
> >> > > >> >>
> >> > > >> >> Why?
> >> > > >> >
> >> > > >> > I only had that comment in mind: "there is none so deaf as he who will not hear."
> >> > > >>
> >> > > >> Hey, stop the pile-on. It's not useful.
> >> > > >>
> >> > > >> I've guided U-Boot's use of devicetree for 10 years successfully. The
> >> > > >> current state is a mess and I just to straighten it out.
> >> > > >>
> >> > > > I admire your talent and knowledge.
> >> > > > I know you are 99,99% of the time correct and spot on for your comments in many meetings we were attending.
> >> > > > When you questioned a number of points I made, I first tried to understand what I got wrong because you said it.
> >> > > > And you were right ;-)
> >> > > > For this topic, I made every effort to come to your position, but definitively can't.
> >> > >
> >> > > Thank you. I think this will come together in a few years when
> >> > > devicetree is sorted out in U-Boot and Binman is more widely used.
> >> > >
> >> > > For this series, if and when it is applied, I predict:
> >> > > - it will not cause any confusion
> >> > > - it will aid development
> >> > > - it will help with discoverability, pressuring people to explain how
> >> > > to build for their systems
> >> > > - it will be a good basis for future work (we have a long list)
> >> > > - everyone will wonder what the fuss was about
> >> > >
> >> > > Here is the commit that introduced OF_PRIOR_STAGE. It attracted no
> >> > > such push-back.
> >> > >
> >> > > commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481
> >> > > Author: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> >> > > Date: Fri Jun 8 17:59:45 2018 -0400
> >> > >
> >> > > board: arm: Add support for Broadcom BCM7445
> >> > >
> >> > > Add support for loading U-Boot on the Broadcom 7445 SoC. This port
> >> > > assumes Broadcom's BOLT bootloader is acting as the second stage
> >> > > bootloader, and U-Boot is acting as the third stage bootloader, loaded
> >> > > as an ELF program by BOLT.
> >> > >
> >> > > Signed-off-by: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> >> > > Cc: Stefan Roese <sr@denx.de>
> >> > > Cc: Tom Rini <trini@konsulko.com>
> >> > > Cc: Florian Fainelli <f.fainelli@gmail.com>
> >> >
> >> > I want to cycle back over here. Yes, historically a number of things
> >> > came in that perhaps shouldn't have. I went with "well, this is what we
> >> > need to handle this case I suppose" and applied it.
> >>
> >> Yes and we need to move things forward. We can't just object to things
> >> without an alternative.
> >
> > As far as I can follow the threads, I proposed the dts to be empty to pass compilation and move forward, but I think you haven't replied. The empty dts can contain a comment pointing to documentation, which could describe the DT lifecycle of the platform, and a template dts that could be used for adventurous developers.
>
> That does not go far enough for me. We actually do want to be able to
> build U-Boot and run it on the board, e.g. in a lab. We cannot do that
> if there are manual instructions involved. The onus needs to be on
> contributors to make their boards actually buildable/bootable with
> U-Boot.
We can build and boot the platform fine with an empty useless device
tree when we get the actual tree at run time. You're conflating the
developer use case with the normal use case.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-03 20:14 ` Simon Glass
2021-12-03 20:21 ` Tom Rini
@ 2021-12-03 20:27 ` François Ozog
1 sibling, 0 replies; 136+ messages in thread
From: François Ozog @ 2021-12-03 20:27 UTC (permalink / raw)
To: Simon Glass
Cc: Albert Aribaud, Anastasiia Lukianenko, Heinrich Schuchardt,
Ilias Apalodimas, Mark Kettenis, Oleksandr Andrushchenko,
Sean Anderson, Tom Rini, U-Boot Mailing List
Le ven. 3 déc. 2021 à 21:14, Simon Glass <sjg@chromium.org> a écrit :
> Hi François,
>
> On Fri, 3 Dec 2021 at 10:03, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> >
> >
> > On Fri, 3 Dec 2021 at 17:04, Simon Glass <sjg@chromium.org> wrote:
> >>
> >> Hi Tom,
> >>
> >> On Fri, 3 Dec 2021 at 05:14, Tom Rini <trini@konsulko.com> wrote:
> >> >
> >> > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote:
> >> > > Hi François,
> >> > >
> >> > > On Thu, 2 Dec 2021 at 11:44, François Ozog <
> francois.ozog@linaro.org> wrote:
> >> > > >
> >> > > > Hi Simon
> >> > > >
> >> > > > On Thu, 2 Dec 2021 at 19:29, Simon Glass <sjg@chromium.org>
> wrote:
> >> > > >>
> >> > > >> Hi François,
> >> > > >>
> >> > > >> On Thu, 2 Dec 2021 at 11:17, François Ozog <
> francois.ozog@linaro.org> wrote:
> >> > > >> >
> >> > > >> > Hi Simon
> >> > > >> >
> >> > > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass <sjg@chromium.org>
> wrote:
> >> > > >> >>
> >> > > >> >> Hi Tom,
> >> > > >> >>
> >> > > >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini <trini@konsulko.com>
> wrote:
> >> > > >> >> >
> >> > > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +0000, Oleksandr
> Andrushchenko wrote:
> >> > > >> >> > > Hi, Simon!
> >> > > >> >> > >
> >> > > >> >> > > Sorry for being late to the party
> >> > > >> >> > >
> >> > > >> >> > > On 02.12.21 17:59, Simon Glass wrote:
> >> > > >> >> > > > Add an empty file to prevent build errors when building
> with
> >> > > >> >> > > > CONFIG_OF_SEPARATE enabled.
> >> > > >> >> > > >
> >> > > >> >> > > > The build instructions in U-Boot do not provide enough
> detail to build a
> >> > > >> >> > > > useful devicetree, unfortunately.
> >> > > >> >> > > Xen guest doesn't use any built-in device trees as the
> guest's device tree is provided
> >> > > >> >> > > by the Xen hypervisor itself and is generated at the
> virtual machine creation time: it is
> >> > > >> >> > > populated with memory size, number of CPUs etc. based on
> [1].
> >> > > >> >> > > So, even if we provide some device tree here it must not
> be used by U-boot at
> >> > > >> >> > > the end of the day. Thus, it might be a reasonable
> solution to provide an empty device
> >> > > >> >> > > tree as you do, but put a comment that it is not used.
> >> > > >> >> >
> >> > > >> >> > So another example of why this series is taking things in
> the wrong
> >> > > >> >> > direction.
> >> > > >> >>
> >> > > >> >> Why?
> >> > > >> >
> >> > > >> > I only had that comment in mind: "there is none so deaf as he
> who will not hear."
> >> > > >>
> >> > > >> Hey, stop the pile-on. It's not useful.
> >> > > >>
> >> > > >> I've guided U-Boot's use of devicetree for 10 years
> successfully. The
> >> > > >> current state is a mess and I just to straighten it out.
> >> > > >>
> >> > > > I admire your talent and knowledge.
> >> > > > I know you are 99,99% of the time correct and spot on for your
> comments in many meetings we were attending.
> >> > > > When you questioned a number of points I made, I first tried to
> understand what I got wrong because you said it.
> >> > > > And you were right ;-)
> >> > > > For this topic, I made every effort to come to your position, but
> definitively can't.
> >> > >
> >> > > Thank you. I think this will come together in a few years when
> >> > > devicetree is sorted out in U-Boot and Binman is more widely used.
> >> > >
> >> > > For this series, if and when it is applied, I predict:
> >> > > - it will not cause any confusion
> >> > > - it will aid development
> >> > > - it will help with discoverability, pressuring people to explain
> how
> >> > > to build for their systems
> >> > > - it will be a good basis for future work (we have a long list)
> >> > > - everyone will wonder what the fuss was about
> >> > >
> >> > > Here is the commit that introduced OF_PRIOR_STAGE. It attracted no
> >> > > such push-back.
> >> > >
> >> > > commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481
> >> > > Author: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> >> > > Date: Fri Jun 8 17:59:45 2018 -0400
> >> > >
> >> > > board: arm: Add support for Broadcom BCM7445
> >> > >
> >> > > Add support for loading U-Boot on the Broadcom 7445 SoC. This
> port
> >> > > assumes Broadcom's BOLT bootloader is acting as the second stage
> >> > > bootloader, and U-Boot is acting as the third stage bootloader,
> loaded
> >> > > as an ELF program by BOLT.
> >> > >
> >> > > Signed-off-by: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> >> > > Cc: Stefan Roese <sr@denx.de>
> >> > > Cc: Tom Rini <trini@konsulko.com>
> >> > > Cc: Florian Fainelli <f.fainelli@gmail.com>
> >> >
> >> > I want to cycle back over here. Yes, historically a number of things
> >> > came in that perhaps shouldn't have. I went with "well, this is what
> we
> >> > need to handle this case I suppose" and applied it.
> >>
> >> Yes and we need to move things forward. We can't just object to things
> >> without an alternative.
> >
> > As far as I can follow the threads, I proposed the dts to be empty to
> pass compilation and move forward, but I think you haven't replied. The
> empty dts can contain a comment pointing to documentation, which could
> describe the DT lifecycle of the platform, and a template dts that could be
> used for adventurous developers.
>
> That does not go far enough for me. We actually do want to be able to
> build U-Boot and run it on the board, e.g. in a lab. We cannot do that
> if there are manual instructions involved. The onus needs to be on
> contributors to make their boards actually buildable/bootable with
> U-Boot.
Compromise seems to be missing here…
If the dts is empty and defconfig is set to of_board it works well. So if
you want more, it means you want to tweak the DT lifecycle for those boards
as the standard way. Not good.
>
>
> [..]
>
> REgards,
> Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-02 17:40 ` Oleksandr Andrushchenko
2021-12-02 17:56 ` Tom Rini
@ 2021-12-02 17:57 ` Simon Glass
2021-12-03 5:41 ` Oleksandr Andrushchenko
1 sibling, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 17:57 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, Tom Rini, François Ozog,
Heinrich Schuchardt, Albert Aribaud, Anastasiia Lukianenko
Hi Oleksandr,
On Thu, 2 Dec 2021 at 10:40, Oleksandr Andrushchenko
<Oleksandr_Andrushchenko@epam.com> wrote:
>
> Hi, Simon!
>
> Sorry for being late to the party
>
> On 02.12.21 17:59, Simon Glass wrote:
> > Add an empty file to prevent build errors when building with
> > CONFIG_OF_SEPARATE enabled.
> >
> > The build instructions in U-Boot do not provide enough detail to build a
> > useful devicetree, unfortunately.
> Xen guest doesn't use any built-in device trees as the guest's device tree is provided
> by the Xen hypervisor itself and is generated at the virtual machine creation time: it is
> populated with memory size, number of CPUs etc. based on [1].
> So, even if we provide some device tree here it must not be used by U-boot at
> the end of the day. Thus, it might be a reasonable solution to provide an empty device
> tree as you do, but put a comment that it is not used.
OK we can go with an empty one if we have to, but where are the
instructions to create the DT that is used?
I'm not even sure how to run U-Boot with Xen? The in-tree instructions
don't help...
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-02 17:57 ` Simon Glass
@ 2021-12-03 5:41 ` Oleksandr Andrushchenko
2021-12-03 16:23 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Oleksandr Andrushchenko @ 2021-12-03 5:41 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, Tom Rini, François Ozog,
Heinrich Schuchardt, Albert Aribaud, Anastasiia Lukianenko
Hi, Simon!
On 02.12.21 19:57, Simon Glass wrote:
> Hi Oleksandr,
>
> On Thu, 2 Dec 2021 at 10:40, Oleksandr Andrushchenko
> <Oleksandr_Andrushchenko@epam.com> wrote:
>> Hi, Simon!
>>
>> Sorry for being late to the party
>>
>> On 02.12.21 17:59, Simon Glass wrote:
>>> Add an empty file to prevent build errors when building with
>>> CONFIG_OF_SEPARATE enabled.
>>>
>>> The build instructions in U-Boot do not provide enough detail to build a
>>> useful devicetree, unfortunately.
>> Xen guest doesn't use any built-in device trees as the guest's device tree is provided
>> by the Xen hypervisor itself and is generated at the virtual machine creation time: it is
>> populated with memory size, number of CPUs etc. based on [1].
>> So, even if we provide some device tree here it must not be used by U-boot at
>> the end of the day. Thus, it might be a reasonable solution to provide an empty device
>> tree as you do, but put a comment that it is not used.
> OK we can go with an empty one if we have to, but where are the
> instructions to create the DT that is used?
You don't need to create the device tree yourself, but instead it is
provided by Xen and generated at run-time while creating a
virtual machine. So, it is up to Xen to provide one.
There are cases [1] when you may want providing a so called
partial device tree to better tune what a virtual machine gets.
But again, it is used by Xen toolstack outside of the virtual machine
and serves as a sort of overlay to the generated device tree.
So, we can provide some device tree to be embedded in U-boot,
but it will have no practical meaning and will make more harm than good
>
> I'm not even sure how to run U-Boot with Xen? The in-tree instructions
> don't help...
This is just a virtual machine from Xen POV, so U-boot is nothing
different here from Linux kernel or anything else.
Thus no specific instructions are needed nor provided
Thank you,
Oleksandr
>
> Regards,
> Simon
[1] https://xenbits.xen.org/docs/unstable/misc/arm/passthrough.txt
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-03 5:41 ` Oleksandr Andrushchenko
@ 2021-12-03 16:23 ` Simon Glass
2021-12-03 17:02 ` Oleksandr Andrushchenko
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-03 16:23 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, Tom Rini, François Ozog,
Heinrich Schuchardt, Albert Aribaud, Anastasiia Lukianenko
Hi Oleksandr,
On Thu, 2 Dec 2021 at 22:41, Oleksandr Andrushchenko
<Oleksandr_Andrushchenko@epam.com> wrote:
>
> Hi, Simon!
>
> On 02.12.21 19:57, Simon Glass wrote:
> > Hi Oleksandr,
> >
> > On Thu, 2 Dec 2021 at 10:40, Oleksandr Andrushchenko
> > <Oleksandr_Andrushchenko@epam.com> wrote:
> >> Hi, Simon!
> >>
> >> Sorry for being late to the party
> >>
> >> On 02.12.21 17:59, Simon Glass wrote:
> >>> Add an empty file to prevent build errors when building with
> >>> CONFIG_OF_SEPARATE enabled.
> >>>
> >>> The build instructions in U-Boot do not provide enough detail to build a
> >>> useful devicetree, unfortunately.
> >> Xen guest doesn't use any built-in device trees as the guest's device tree is provided
> >> by the Xen hypervisor itself and is generated at the virtual machine creation time: it is
> >> populated with memory size, number of CPUs etc. based on [1].
> >> So, even if we provide some device tree here it must not be used by U-boot at
> >> the end of the day. Thus, it might be a reasonable solution to provide an empty device
> >> tree as you do, but put a comment that it is not used.
> > OK we can go with an empty one if we have to, but where are the
> > instructions to create the DT that is used?
> You don't need to create the device tree yourself, but instead it is
> provided by Xen and generated at run-time while creating a
> virtual machine. So, it is up to Xen to provide one.
> There are cases [1] when you may want providing a so called
> partial device tree to better tune what a virtual machine gets.
> But again, it is used by Xen toolstack outside of the virtual machine
> and serves as a sort of overlay to the generated device tree.
> So, we can provide some device tree to be embedded in U-boot,
> but it will have no practical meaning and will make more harm than good
> >
> > I'm not even sure how to run U-Boot with Xen? The in-tree instructions
> > don't help...
> This is just a virtual machine from Xen POV, so U-boot is nothing
> different here from Linux kernel or anything else.
> Thus no specific instructions are needed nor provided
I'd like to try it out. How??
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
2021-12-03 16:23 ` Simon Glass
@ 2021-12-03 17:02 ` Oleksandr Andrushchenko
0 siblings, 0 replies; 136+ messages in thread
From: Oleksandr Andrushchenko @ 2021-12-03 17:02 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, Tom Rini, François Ozog,
Heinrich Schuchardt, Albert Aribaud, Anastasiia Lukianenko
Hi, Simon!
On 03.12.21 18:23, Simon Glass wrote:
> Hi Oleksandr,
>
> On Thu, 2 Dec 2021 at 22:41, Oleksandr Andrushchenko
> <Oleksandr_Andrushchenko@epam.com> wrote:
>> Hi, Simon!
>>
>> On 02.12.21 19:57, Simon Glass wrote:
>>> Hi Oleksandr,
>>>
>>> On Thu, 2 Dec 2021 at 10:40, Oleksandr Andrushchenko
>>> <Oleksandr_Andrushchenko@epam.com> wrote:
>>>> Hi, Simon!
>>>>
>>>> Sorry for being late to the party
>>>>
>>>> On 02.12.21 17:59, Simon Glass wrote:
>>>>> Add an empty file to prevent build errors when building with
>>>>> CONFIG_OF_SEPARATE enabled.
>>>>>
>>>>> The build instructions in U-Boot do not provide enough detail to build a
>>>>> useful devicetree, unfortunately.
>>>> Xen guest doesn't use any built-in device trees as the guest's device tree is provided
>>>> by the Xen hypervisor itself and is generated at the virtual machine creation time: it is
>>>> populated with memory size, number of CPUs etc. based on [1].
>>>> So, even if we provide some device tree here it must not be used by U-boot at
>>>> the end of the day. Thus, it might be a reasonable solution to provide an empty device
>>>> tree as you do, but put a comment that it is not used.
>>> OK we can go with an empty one if we have to, but where are the
>>> instructions to create the DT that is used?
>> You don't need to create the device tree yourself, but instead it is
>> provided by Xen and generated at run-time while creating a
>> virtual machine. So, it is up to Xen to provide one.
>> There are cases [1] when you may want providing a so called
>> partial device tree to better tune what a virtual machine gets.
>> But again, it is used by Xen toolstack outside of the virtual machine
>> and serves as a sort of overlay to the generated device tree.
>> So, we can provide some device tree to be embedded in U-boot,
>> but it will have no practical meaning and will make more harm than good
>>> I'm not even sure how to run U-Boot with Xen? The in-tree instructions
>>> don't help...
>> This is just a virtual machine from Xen POV, so U-boot is nothing
>> different here from Linux kernel or anything else.
>> Thus no specific instructions are needed nor provided
> I'd like to try it out. How??
Well, it can be tricky a bit. There are number of ARM64 platforms which have
Xen running: Arm, Renesas, Xilinx, iMX8, Rpi4...
You can probably start from QEMU, for example OP-TEE has a way to build
Xen + QEMU, please see [1]. The build has Xen in it and a virtual machine [2].
You will need to tweak [3] and put U-boot instead of the Linux kernel.
I never tried that build myself, but I know it is used for OP-TEE tests for Xen.
Hope this helps,
Oleksandr
>
> Regards,
> Simon
[1] https://github.com/OP-TEE/manifest/blob/master/qemu_v8.xml
[2] https://github.com/OP-TEE/build/tree/master/qemu_v8/xen
[3] https://github.com/OP-TEE/build/blob/master/qemu_v8/xen/guest.cfg#L1
^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v6 10/25] arm: octeontx: Add a fake devicetree file
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (8 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 11/25] arm: xilinx_versal_virt: Add a " Simon Glass
` (16 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Aaron Williams, Albert Aribaud
Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.
Unfortunately there are no build instructions in the U-Boot tree to enable
a real file to be created.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/dts/Makefile | 3 +++
arch/arm/dts/octeontx.dts | 14 ++++++++++++++
configs/octeontx2_95xx_defconfig | 1 +
configs/octeontx2_96xx_defconfig | 1 +
configs/octeontx_81xx_defconfig | 1 +
configs/octeontx_83xx_defconfig | 1 +
6 files changed, 21 insertions(+)
create mode 100644 arch/arm/dts/octeontx.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f6345988c8c..91302118598 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1142,6 +1142,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
+dtb-$(CONFIG_ARCH_OCTEONTX) += octeontx.dtb
+dtb-$(CONFIG_ARCH_OCTEONTX2) += octeontx.dtb
+
dtb-$(CONFIG_TARGET_GE_BX50V3) += \
imx6q-bx50v3.dtb \
imx6q-b850v3.dtb \
diff --git a/arch/arm/dts/octeontx.dts b/arch/arm/dts/octeontx.dts
new file mode 100644
index 00000000000..60a15f5df23
--- /dev/null
+++ b/arch/arm/dts/octeontx.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Dummy devicetre file for octeontx2 boards
+ *
+ * This is required to make the board build with CONFIG OF_SEPARATE
+ * I could not find any in-tree documentation at all so this is a dummy file.
+ *
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+};
diff --git a/configs/octeontx2_95xx_defconfig b/configs/octeontx2_95xx_defconfig
index e1b86a5a8b6..e3df390c94b 100644
--- a/configs/octeontx2_95xx_defconfig
+++ b/configs/octeontx2_95xx_defconfig
@@ -12,6 +12,7 @@ CONFIG_ENV_OFFSET=0xF00000
CONFIG_ENV_SECT_SIZE=0x10000
CONFIG_TARGET_OCTEONTX2_95XX=y
CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="octeontx"
CONFIG_DEBUG_UART_BASE=0x87e028000000
CONFIG_DEBUG_UART_CLOCK=24000000
CONFIG_DEBUG_UART=y
diff --git a/configs/octeontx2_96xx_defconfig b/configs/octeontx2_96xx_defconfig
index ec03d959771..0478b3068a6 100644
--- a/configs/octeontx2_96xx_defconfig
+++ b/configs/octeontx2_96xx_defconfig
@@ -10,6 +10,7 @@ CONFIG_ENV_OFFSET=0xF00000
CONFIG_ENV_SECT_SIZE=0x10000
CONFIG_TARGET_OCTEONTX2_96XX=y
CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="octeontx"
CONFIG_DEBUG_UART_BASE=0x87e028000000
CONFIG_DEBUG_UART_CLOCK=24000000
CONFIG_DEBUG_UART=y
diff --git a/configs/octeontx_81xx_defconfig b/configs/octeontx_81xx_defconfig
index d0728ac3c67..d871be8f812 100644
--- a/configs/octeontx_81xx_defconfig
+++ b/configs/octeontx_81xx_defconfig
@@ -12,6 +12,7 @@ CONFIG_ENV_OFFSET=0xF00000
CONFIG_ENV_SECT_SIZE=0x10000
CONFIG_TARGET_OCTEONTX_81XX=y
CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="octeontx"
CONFIG_DEBUG_UART_BASE=0x87e028000000
CONFIG_DEBUG_UART_CLOCK=24000000
CONFIG_DEBUG_UART=y
diff --git a/configs/octeontx_83xx_defconfig b/configs/octeontx_83xx_defconfig
index 6c9609b0cd3..94b072bf6fa 100644
--- a/configs/octeontx_83xx_defconfig
+++ b/configs/octeontx_83xx_defconfig
@@ -10,6 +10,7 @@ CONFIG_ENV_OFFSET=0xF00000
CONFIG_ENV_SECT_SIZE=0x10000
CONFIG_TARGET_OCTEONTX_83XX=y
CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="octeontx"
CONFIG_DEBUG_UART_BASE=0x87e028000000
CONFIG_DEBUG_UART_CLOCK=24000000
CONFIG_DEBUG_UART=y
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 11/25] arm: xilinx_versal_virt: Add a devicetree file
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (9 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 10/25] arm: octeontx: " Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 12/25] arm: bcm7xxx: " Simon Glass
` (15 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Albert Aribaud, Michal Simek
Add a devicetree file obtained from qemu for this board. This was obtained
with:
qemu-system-aarch64 -M xlnx-versal-virt -machine dumpdtb=dtb.dtb
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/xilinx-versal-virt.dts | 307 +++++++++++++++++++++++++++
configs/xilinx_versal_virt_defconfig | 1 +
3 files changed, 310 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 91302118598..b07a1b3378e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -360,7 +360,8 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += \
dtb-$(CONFIG_ARCH_VERSAL) += \
versal-mini.dtb \
versal-mini-emmc0.dtb \
- versal-mini-emmc1.dtb
+ versal-mini-emmc1.dtb \
+ xilinx-versal-virt.dtb
dtb-$(CONFIG_ARCH_ZYNQMP_R5) += \
zynqmp-r5.dtb
dtb-$(CONFIG_AM33XX) += \
diff --git a/arch/arm/dts/xilinx-versal-virt.dts b/arch/arm/dts/xilinx-versal-virt.dts
new file mode 100644
index 00000000000..3712af9e7a4
--- /dev/null
+++ b/arch/arm/dts/xilinx-versal-virt.dts
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for versal-virt board
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ compatible = "xlnx-versal-virt";
+ model = "Xilinx Versal Virtual development board";
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ interrupt-parent = <0x8000>;
+
+ memory@0 {
+ reg = <0x00 0x00 0x00 0x8000000>;
+ device_type = "memory";
+ };
+
+ clk25 {
+ u-boot,dm-pre-reloc;
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x17d7840>;
+ phandle = <0x8003>;
+ };
+
+ clk125 {
+ u-boot,dm-pre-reloc;
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x7735940>;
+ phandle = <0x8004>;
+ };
+
+ cpus {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a72";
+ device_type = "cpu";
+ reg = <0x00>;
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a72";
+ device_type = "cpu";
+ reg = <0x01>;
+ };
+ };
+
+ rtc@f12a0000 {
+ compatible = "xlnx,zynqmp-rtc";
+ reg = <0x00 0xf12a0000 0x00 0x10000>;
+ interrupt-names = "alarm\0sec";
+ interrupts = <0x00 0x8e 0x04 0x00 0x8f 0x04>;
+ };
+
+ sdhci@f1040000 {
+ compatible = "arasan,sdhci-8.9a";
+ reg = <0x00 0xf1040000 0x00 0x10000>;
+ interrupts = <0x00 0x7e 0x04>;
+ clock-names = "clk_xin\0clk_ahb";
+ clocks = <0x8003 0x8003>;
+ };
+
+ sdhci@f1050000 {
+ compatible = "arasan,sdhci-8.9a";
+ reg = <0x00 0xf1050000 0x00 0x10000>;
+ interrupts = <0x00 0x80 0x04>;
+ clock-names = "clk_xin\0clk_ahb";
+ clocks = <0x8003 0x8003>;
+ };
+
+ usb@ff9d0000 {
+ phandle = <0x8005>;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ ranges;
+ clocks = <0x8003 0x8004>;
+ clock-names = "bus_clk\0ref_clk";
+ reg = <0x00 0xff9d0000 0x00 0x10000>;
+ compatible = "xlnx,versal-dwc3";
+
+ dwc3@fe200000 {
+ maximum-speed = "high-speed";
+ phandle = <0x8006>;
+ snps,mask_phy_reset;
+ snps,refclk_fladj;
+ snps,dis_u3_susphy_quirk;
+ snps,dis_u2_susphy_quirk;
+ phy-names = "usb3-phy";
+ dr_mode = "host";
+ #stream-id-cells = <0x01>;
+ snps,quirk-frame-length-adjustment = <0x20>;
+ interrupts = <0x00 0x16 0x04>;
+ interrupt-names = "dwc_usb3";
+ reg = <0x00 0xfe200000 0x00 0x10000>;
+ compatible = "snps,dwc3";
+ };
+ };
+
+ dma@ffa80000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffa80000 0x00 0x1000>;
+ interrupts = <0x00 0x3c 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffa90000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffa90000 0x00 0x1000>;
+ interrupts = <0x00 0x3d 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffaa0000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffaa0000 0x00 0x1000>;
+ interrupts = <0x00 0x3e 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffab0000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffab0000 0x00 0x1000>;
+ interrupts = <0x00 0x3f 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffac0000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffac0000 0x00 0x1000>;
+ interrupts = <0x00 0x40 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffad0000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffad0000 0x00 0x1000>;
+ interrupts = <0x00 0x41 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffae0000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffae0000 0x00 0x1000>;
+ interrupts = <0x00 0x42 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffaf0000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffaf0000 0x00 0x1000>;
+ interrupts = <0x00 0x43 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <0x01 0x0d 0x04 0x01 0x0e 0x04 0x01 0x0b 0x04 0x01 0x0a 0x04>;
+ };
+
+ gic@f9000000 {
+ compatible = "arm,gic-v3";
+ #interrupt-cells = <0x03>;
+ reg = <0x00 0xf9000000 0x00 0x10000 0x00 0xf9080000 0x00 0x80000>;
+ interrupt-controller;
+ interrupts = <0x01 0x09 0x04>;
+ phandle = <0x8000>;
+ };
+
+ uart@ff000000 {
+ u-boot,dm-pre-reloc;
+ compatible = "arm,pl011\0arm,sbsa-uart";
+ reg = <0x00 0xff000000 0x00 0x1000>;
+ interrupts = <0x00 0x12 0x04>;
+ clock-names = "uartclk\0apb_pclk";
+ clocks = <0x8004 0x8004>;
+ current-speed = <0x1c200>;
+ };
+
+ uart@ff010000 {
+ u-boot,dm-pre-reloc;
+ compatible = "arm,pl011\0arm,sbsa-uart";
+ reg = <0x00 0xff010000 0x00 0x1000>;
+ interrupts = <0x00 0x13 0x04>;
+ clock-names = "uartclk\0apb_pclk";
+ clocks = <0x8004 0x8004>;
+ current-speed = <0x1c200>;
+ };
+
+ ethernet@ff0c0000 {
+ #size-cells = <0x00>;
+ #address-cells = <0x01>;
+ compatible = "cdns,zynqmp-gem\0cdns,gem";
+ reg = <0x00 0xff0c0000 0x00 0x1000>;
+ interrupts = <0x00 0x38 0x04 0x00 0x38 0x04>;
+ clock-names = "pclk\0hclk\0tx_clk\0rx_clk";
+ clocks = <0x8003 0x8003 0x8004 0x8004>;
+ phy-handle = <0x8002>;
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <0x3e8>;
+ full-duplex;
+ phandle = <0x8002>;
+ };
+ };
+
+ ethernet@ff0d0000 {
+ #size-cells = <0x00>;
+ #address-cells = <0x01>;
+ compatible = "cdns,zynqmp-gem\0cdns,gem";
+ reg = <0x00 0xff0d0000 0x00 0x1000>;
+ interrupts = <0x00 0x3a 0x04 0x00 0x3a 0x04>;
+ clock-names = "pclk\0hclk\0tx_clk\0rx_clk";
+ clocks = <0x8003 0x8003 0x8004 0x8004>;
+ phy-handle = <0x8001>;
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <0x3e8>;
+ full-duplex;
+ phandle = <0x8001>;
+ };
+ };
+
+ virtio_mmio@a0000e00 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000e00 0x00 0x200>;
+ interrupts = <0x00 0x76 0x01>;
+ dma-coherent;
+ };
+
+ virtio_mmio@a0000c00 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000c00 0x00 0x200>;
+ interrupts = <0x00 0x75 0x01>;
+ dma-coherent;
+ };
+
+ virtio_mmio@a0000a00 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000a00 0x00 0x200>;
+ interrupts = <0x00 0x74 0x01>;
+ dma-coherent;
+ };
+
+ virtio_mmio@a0000800 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000800 0x00 0x200>;
+ interrupts = <0x00 0x73 0x01>;
+ dma-coherent;
+ };
+
+ virtio_mmio@a0000600 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000600 0x00 0x200>;
+ interrupts = <0x00 0x72 0x01>;
+ dma-coherent;
+ };
+
+ virtio_mmio@a0000400 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000400 0x00 0x200>;
+ interrupts = <0x00 0x71 0x01>;
+ dma-coherent;
+ };
+
+ virtio_mmio@a0000200 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000200 0x00 0x200>;
+ interrupts = <0x00 0x70 0x01>;
+ dma-coherent;
+ };
+
+ virtio_mmio@a0000000 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000000 0x00 0x200>;
+ interrupts = <0x00 0x6f 0x01>;
+ dma-coherent;
+ };
+
+ chosen {
+ stdout-path = "/uart@ff000000";
+ };
+};
diff --git a/configs/xilinx_versal_virt_defconfig b/configs/xilinx_versal_virt_defconfig
index 11598623954..f0ec2639a38 100644
--- a/configs/xilinx_versal_virt_defconfig
+++ b/configs/xilinx_versal_virt_defconfig
@@ -7,6 +7,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x100000
CONFIG_SYS_MEMTEST_START=0x00000000
CONFIG_SYS_MEMTEST_END=0x00001000
CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="xilinx-versal-virt"
CONFIG_CMD_FRU=y
CONFIG_DEFINE_TCM_OCM_MMAP=y
CONFIG_COUNTER_FREQUENCY=100000000
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 12/25] arm: bcm7xxx: Add a devicetree file
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (10 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 11/25] arm: xilinx_versal_virt: Add a " Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 13/25] arm: qemu-ppce500: " Simon Glass
` (14 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Albert Aribaud, Thomas Fitzsimmons
Add a dummy devicetree file for these boards. It seems to be possible to
obtain a real one from another bootloader called 'bolt' but I will leave
this to the maintainer.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/dts/Makefile | 2 ++
arch/arm/dts/bcm7xxx.dts | 15 +++++++++++++++
configs/bcm7260_defconfig | 1 +
configs/bcm7445_defconfig | 1 +
4 files changed, 19 insertions(+)
create mode 100644 arch/arm/dts/bcm7xxx.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b07a1b3378e..8bb15b96cc7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1092,6 +1092,8 @@ dtb-$(CONFIG_ARCH_BCM6858) += \
dtb-$(CONFIG_TARGET_BCMNS3) += ns3-board.dtb
+dtb-$(CONFIG_ARCH_BCMSTB) += bcm7xxx.dtb
+
dtb-$(CONFIG_ASPEED_AST2500) += ast2500-evb.dtb
dtb-$(CONFIG_ASPEED_AST2600) += ast2600-evb.dtb
diff --git a/arch/arm/dts/bcm7xxx.dts b/arch/arm/dts/bcm7xxx.dts
new file mode 100644
index 00000000000..799cc9caad4
--- /dev/null
+++ b/arch/arm/dts/bcm7xxx.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Dummy devicetre file for bcm7260 board
+ *
+ * This is required to make the board build with CONFIG OF_SEPARATE
+ * In-tree document explains how to obtain a real devicetree using 'bolt' but
+ * I did not attempt this.
+ *
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+};
diff --git a/configs/bcm7260_defconfig b/configs/bcm7260_defconfig
index 257d81052a8..2b527b65770 100644
--- a/configs/bcm7260_defconfig
+++ b/configs/bcm7260_defconfig
@@ -7,6 +7,7 @@ CONFIG_TARGET_BCM7260=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x10000
CONFIG_ENV_OFFSET=0x814800
+CONFIG_DEFAULT_DEVICE_TREE="bcm7xxx"
CONFIG_ENV_OFFSET_REDUND=0x824800
CONFIG_SYS_LOAD_ADDR=0x02000000
CONFIG_FIT=y
diff --git a/configs/bcm7445_defconfig b/configs/bcm7445_defconfig
index 9ffa436e454..3ae678ba56e 100644
--- a/configs/bcm7445_defconfig
+++ b/configs/bcm7445_defconfig
@@ -8,6 +8,7 @@ CONFIG_NR_DRAM_BANKS=3
CONFIG_ENV_SIZE=0x10000
CONFIG_ENV_OFFSET=0x1E0000
CONFIG_ENV_SECT_SIZE=0x10000
+CONFIG_DEFAULT_DEVICE_TREE="bcm7xxx"
CONFIG_ENV_OFFSET_REDUND=0x1F0000
CONFIG_SYS_LOAD_ADDR=0x02000000
CONFIG_FIT=y
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 13/25] arm: qemu-ppce500: Add a devicetree file
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (11 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 12/25] arm: bcm7xxx: " Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 14/25] arm: highbank: Add a fake " Simon Glass
` (13 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Albert Aribaud, Alexander Graf, Bin Meng
Add a devicetree file obtained from qemu for this board. This was obtained
with:
qemu-system-ppc64 -machine ppce500 -cpu e6500 -M dumpdtb=dtb.dtb
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/powerpc/dts/Makefile | 1 +
arch/powerpc/dts/qemu-ppce500.dts | 264 ++++++++++++++++++++++++++++++
configs/qemu-ppce500_defconfig | 1 +
3 files changed, 266 insertions(+)
create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
diff --git a/arch/powerpc/dts/Makefile b/arch/powerpc/dts/Makefile
index ceaa8ce5c82..66d22ae8a45 100644
--- a/arch/powerpc/dts/Makefile
+++ b/arch/powerpc/dts/Makefile
@@ -18,6 +18,7 @@ dtb-$(CONFIG_TARGET_P2041RDB) += p2041rdb.dtb
dtb-$(CONFIG_TARGET_P3041DS) += p3041ds.dtb
dtb-$(CONFIG_TARGET_P4080DS) += p4080ds.dtb
dtb-$(CONFIG_TARGET_P5040DS) += p5040ds.dtb
+dtb-$(CONFIG_TARGET_QEMU_PPCE500) += qemu-ppce500.dtb
dtb-$(CONFIG_TARGET_SOCRATES) += socrates.dtb
dtb-$(CONFIG_TARGET_T1024RDB) += t1024rdb.dtb
dtb-$(CONFIG_TARGET_T1042D4RDB) += t1042d4rdb.dtb
diff --git a/arch/powerpc/dts/qemu-ppce500.dts b/arch/powerpc/dts/qemu-ppce500.dts
new file mode 100644
index 00000000000..92368e4d731
--- /dev/null
+++ b/arch/powerpc/dts/qemu-ppce500.dts
@@ -0,0 +1,264 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu-ppce400
+
+ * Copyright 2021 Google LLC
+ */
+/dts-v1/;
+
+/ {
+ compatible = "fsl,qemu-e500";
+ model = "QEMU ppce500";
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+
+ platform@f00000000 {
+ interrupt-parent = <0x8003>;
+ ranges = <0x00 0x0f 0x00 0x8000000>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ pci@fe0008000 {
+ #address-cells = <0x03>;
+ #size-cells = <0x02>;
+ #interrupt-cells = <0x01>;
+ clock-frequency = <0x3f940aa>;
+ reg = <0x0f 0xe0008000 0x00 0x1000>;
+ ranges = <0x2000000 0x00 0xe0000000 0x0c
+ 0x00 0x00 0x20000000 0x1000000
+ 0x00 0x00 0x0f 0xe1000000
+ 0x00 0x10000>;
+ fsl,msi = <0x8004>;
+ bus-range = <0x00 0xff>;
+ interrupts = <0x18 0x02>;
+ interrupt-parent = <0x8003>;
+ interrupt-map = <0x800 0x00 0x00 0x01 0x8003 0x02 0x01 0x800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x1000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x1000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x1000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x1000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x1800 0x00 0x00 0x01 0x8003 0x04 0x01 0x1800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x1800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x1800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0x2000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0x2000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0x2000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0x2000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0x2800 0x00 0x00 0x01 0x8003 0x02 0x01 0x2800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x2800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x2800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x3000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x3000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x3000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x3000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x3800 0x00 0x00 0x01 0x8003 0x04 0x01 0x3800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x3800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x3800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0x4000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0x4000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0x4000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0x4000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0x4800 0x00 0x00 0x01 0x8003 0x02 0x01 0x4800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x4800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x4800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x5000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x5000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x5000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x5000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x5800 0x00 0x00 0x01 0x8003 0x04 0x01 0x5800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x5800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x5800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0x6000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0x6000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0x6000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0x6000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0x6800 0x00 0x00 0x01 0x8003 0x02 0x01 0x6800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x6800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x6800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x7000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x7000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x7000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x7000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x7800 0x00 0x00 0x01 0x8003 0x04 0x01 0x7800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x7800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x7800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0x8000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0x8000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0x8000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0x8000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0x8800 0x00 0x00 0x01 0x8003 0x02 0x01 0x8800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x8800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x8800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x9000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x9000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x9000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x9000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x9800 0x00 0x00 0x01 0x8003 0x04 0x01 0x9800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x9800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x9800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0xa000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0xa000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0xa000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0xa000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0xa800 0x00 0x00 0x01 0x8003 0x02 0x01 0xa800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0xa800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0xa800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0xb000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0xb000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0xb000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0xb000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0xb800 0x00 0x00 0x01 0x8003 0x04 0x01 0xb800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0xb800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0xb800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0xc000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0xc000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0xc000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0xc000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0xc800 0x00 0x00 0x01 0x8003 0x02 0x01 0xc800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0xc800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0xc800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0xd000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0xd000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0xd000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0xd000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0xd800 0x00 0x00 0x01 0x8003 0x04 0x01 0xd800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0xd800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0xd800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0xe000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0xe000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0xe000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0xe000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0xe800 0x00 0x00 0x01 0x8003 0x02 0x01 0xe800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0xe800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0xe800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0xf000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0xf000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0xf000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0xf000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0xf800 0x00 0x00 0x01 0x8003 0x04 0x01 0xf800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0xf800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0xf800 0x00 0x00
+ 0x04 0x8003 0x03 0x01>;
+ interrupt-map-mask = <0xf800 0x00 0x00 0x07>;
+ device_type = "pci";
+ compatible = "fsl,mpc8540-pci";
+ cell-index = <0x00>;
+ };
+
+ soc@fe0000000 {
+ bus-frequency = <0x00>;
+ ranges = <0x00 0x0f 0xe0000000 0x100000>;
+ #size-cells = <0x01>;
+ #address-cells = <0x01>;
+ compatible = "fsl,mpc8544-immr\0simple-bus";
+ device_type = "soc";
+
+ power-off {
+ gpios = <0x8005 0x00 0x00>;
+ compatible = "gpio-poweroff";
+ };
+
+ gpio@ff000 {
+ linux,phandle = <0x8005>;
+ phandle = <0x8005>;
+ gpio-controller;
+ #gpio-cells = <0x02>;
+ interrupt-parent = <0x8003>;
+ interrupts = <0x2f 0x02>;
+ reg = <0xff000 0x1000>;
+ compatible = "fsl,qoriq-gpio";
+ };
+
+ msi@41600 {
+ linux,phandle = <0x8004>;
+ phandle = <0x8004>;
+ interrupts = <0xe0 0x00 0xe1 0x00 0xe2 0x00 0xe3 0x00
+ 0xe4 0x00 0xe5 0x00 0xe6 0x00 0xe7 0x00>;
+ interrupt-parent = <0x8003>;
+ msi-available-ranges = <0x00 0x100>;
+ reg = <0x41600 0x200>;
+ compatible = "fsl,mpic-msi";
+ };
+
+ global-utilities@e0000 {
+ fsl,has-rstcr;
+ reg = <0xe0000 0x1000>;
+ compatible = "fsl,mpc8544-guts";
+ };
+
+ i2c@3000 {
+ interrupt-parent = <0x8003>;
+ interrupts = <0x2b 0x02>;
+ cell-index = <0x00>;
+ reg = <0x3000 0x14>;
+ compatible = "fsl-i2c";
+ device_type = "i2c";
+
+ rtc@68 {
+ reg = <0x68>;
+ compatible = "pericom,pt7c4338";
+ };
+ };
+
+ serial@4500 {
+ interrupt-parent = <0x8003>;
+ interrupts = <0x2a 0x02>;
+ clock-frequency = <0x17d78400>;
+ cell-index = <0x00>;
+ reg = <0x4500 0x100>;
+ compatible = "ns16550";
+ device_type = "serial";
+ };
+
+ pic@40000 {
+ interrupt-controller;
+ linux,phandle = <0x8003>;
+ phandle = <0x8003>;
+ #interrupt-cells = <0x02>;
+ #address-cells = <0x00>;
+ reg = <0x40000 0x40000>;
+ compatible = "fsl,mpic";
+ device_type = "open-pic";
+ };
+ };
+
+ aliases {
+ pci0 = "/pci@fe0008000";
+ rtc = "i2c/rtc@68";
+ i2c = "/soc@fe0000000/i2c@3000";
+ serial0 = "/soc@fe0000000/serial@4500";
+ };
+
+ cpus {
+ #size-cells = <0x00>;
+ #address-cells = <0x01>;
+
+ PowerPC,8544@0 {
+ status = "okay";
+ bus-frequency = <0x00>;
+ i-cache-size = <0x8000>;
+ d-cache-size = <0x8000>;
+ i-cache-line-size = <0x20>;
+ d-cache-line-size = <0x20>;
+ reg = <0x00>;
+ device_type = "cpu";
+ timebase-frequency = <0x17d78400>;
+ clock-frequency = <0x17d78400>;
+ };
+ };
+
+ chosen {
+ stdout-path = "/soc@fe0000000/serial@4500";
+ linux,stdout-path = "/soc@fe0000000/serial@4500";
+ bootargs = [00];
+ };
+
+ memory {
+ reg = <0x00 0x00 0x00 0x8000000>;
+ device_type = "memory";
+ };
+};
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index f386f526548..ae4cd8b9618 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -1,6 +1,7 @@
CONFIG_PPC=y
CONFIG_SYS_TEXT_BASE=0xf01000
CONFIG_ENV_SIZE=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-ppce500"
CONFIG_MPC85xx=y
# CONFIG_CMD_ERRATA is not set
CONFIG_TARGET_QEMU_PPCE500=y
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 14/25] arm: highbank: Add a fake devicetree file
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (12 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 13/25] arm: qemu-ppce500: " Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 15/25] fdt: Make OF_BOARD a bool option Simon Glass
` (12 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Albert Aribaud, Andre Przywara
Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.
Unfortunately there are no build instructions in the U-Boot tree to enable
a real file to be created.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/dts/Makefile | 2 ++
arch/arm/dts/highbank.dts | 14 ++++++++++++++
configs/highbank_defconfig | 2 +-
3 files changed, 17 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/highbank.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8bb15b96cc7..453e2fd1a98 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -871,6 +871,8 @@ dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \
dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-com.dtb \
imx7ulp-evk.dtb
+dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb
+
dtb-$(CONFIG_ARCH_IMX8) += \
fsl-imx8qm-apalis.dtb \
fsl-imx8qm-mek.dtb \
diff --git a/arch/arm/dts/highbank.dts b/arch/arm/dts/highbank.dts
new file mode 100644
index 00000000000..29ac48f5788
--- /dev/null
+++ b/arch/arm/dts/highbank.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Dummy devicetre file for highbank board
+ *
+ * This is required to make the board build with CONFIG OF_SEPARATE
+ * There appears to be no in-tree documentation about this board at all.
+ *
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+};
diff --git a/configs/highbank_defconfig b/configs/highbank_defconfig
index 85b42c70f55..3e8bfcf73a6 100644
--- a/configs/highbank_defconfig
+++ b/configs/highbank_defconfig
@@ -7,6 +7,7 @@ CONFIG_SYS_TEXT_BASE=0x00008000
CONFIG_SYS_MALLOC_LEN=0x80000
CONFIG_NR_DRAM_BANKS=2
CONFIG_ENV_SIZE=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="highbank"
CONFIG_SYS_BOOTCOUNT_ADDR=0xfff3cf0c
CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
CONFIG_DISTRO_DEFAULTS=y
@@ -21,7 +22,6 @@ CONFIG_AUTOBOOT_KEYED_CTRLC=y
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_MISC_INIT_R=y
# CONFIG_CMD_SETEXPR is not set
-CONFIG_OF_BOARD=y
CONFIG_ENV_IS_IN_NVRAM=y
CONFIG_ENV_ADDR=0xFFF88000
CONFIG_SCSI_AHCI=y
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 15/25] fdt: Make OF_BOARD a bool option
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (13 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 14/25] arm: highbank: Add a fake " Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 16/25] Drop CONFIG_BINMAN_STANDALONE_FDT Simon Glass
` (11 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Jerry Van Baren
This should not be a separate option from OF_SEPARATE. It is a run-time
option to override the devicetree, even if present.
Move the option out of the choice.
Disable BINMAN_FDT for a few boards which don't actually use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
configs/qemu-ppce500_defconfig | 1 +
configs/qemu-riscv32_spl_defconfig | 2 ++
configs/qemu-riscv64_spl_defconfig | 1 +
dts/Kconfig | 11 ++++++-----
4 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index ae4cd8b9618..81d12d5f3c1 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -56,4 +56,5 @@ CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_NET=y
CONFIG_VIRTIO_BLK=y
CONFIG_ADDR_MAP=y
+# CONFIG_BINMAN_FDT is not set
CONFIG_PANIC_HANG=y
diff --git a/configs/qemu-riscv32_spl_defconfig b/configs/qemu-riscv32_spl_defconfig
index c4422969c61..8889b028c6b 100644
--- a/configs/qemu-riscv32_spl_defconfig
+++ b/configs/qemu-riscv32_spl_defconfig
@@ -6,6 +6,7 @@ CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
CONFIG_SPL=y
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_RISCV_SMODE=y
+# CONFIG_OF_BOARD_FIXUP is not set
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0x80200000
CONFIG_FIT=y
@@ -18,3 +19,4 @@ CONFIG_OF_BOARD=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM_MTD=y
CONFIG_SYSRESET_SBI=y
+# CONFIG_BINMAN_FDT is not set
diff --git a/configs/qemu-riscv64_spl_defconfig b/configs/qemu-riscv64_spl_defconfig
index e02ca3a1465..8f875949ec0 100644
--- a/configs/qemu-riscv64_spl_defconfig
+++ b/configs/qemu-riscv64_spl_defconfig
@@ -19,3 +19,4 @@ CONFIG_OF_BOARD=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM_MTD=y
CONFIG_SYSRESET_SBI=y
+# CONFIG_BINMAN_FDT is not set
diff --git a/dts/Kconfig b/dts/Kconfig
index b7c4a2fec03..9994ab13dcb 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -97,11 +97,9 @@ config OF_LIVE
choice
prompt "Provider of DTB for DT control"
depends on OF_CONTROL
- default OF_BOARD if SANDBOX
config OF_SEPARATE
bool "Separate DTB for DT control"
- depends on !SANDBOX
help
If this option is enabled, the device tree will be built and
placed as a separate u-boot.dtb file alongside the U-Boot image.
@@ -114,14 +112,17 @@ config OF_EMBED
and development only and is not recommended for production devices.
Boards in the mainline U-Boot tree should not use it.
+endchoice
+
config OF_BOARD
bool "Provided by the board (e.g a previous loader) at runtime"
+ default y if SANDBOX
help
If this option is enabled, the device tree will be provided by
- the board at runtime if the board supports it, instead of being
- bundled with the image.
+ the board at runtime if the board supports it. The device tree bundled
+ with the image (if any) will be overridden / ignored.
-endchoice
+ A device tree file must be provided in the tree.
config DEFAULT_DEVICE_TREE
string "Default Device Tree for DT control"
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 16/25] Drop CONFIG_BINMAN_STANDALONE_FDT
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (14 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 15/25] fdt: Make OF_BOARD a bool option Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 17/25] doc: Update info on devicetree update Simon Glass
` (10 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass
This was added as a hack to work around not having an in-tree devicetree.
Now that this is fixed it is not needed.
Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
Makefile | 3 +--
dts/Kconfig | 18 ------------------
tools/binman/binman.rst | 20 --------------------
3 files changed, 1 insertion(+), 40 deletions(-)
diff --git a/Makefile b/Makefile
index 57c3643d9a8..87e13ec6f53 100644
--- a/Makefile
+++ b/Makefile
@@ -945,7 +945,6 @@ endif
endif
INPUTS-$(CONFIG_TPL) += tpl/u-boot-tpl.bin
INPUTS-$(CONFIG_OF_SEPARATE) += u-boot.dtb
-INPUTS-$(CONFIG_BINMAN_STANDALONE_FDT) += u-boot.dtb
ifeq ($(CONFIG_SPL_FRAMEWORK),y)
INPUTS-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img
endif
@@ -1412,7 +1411,7 @@ u-boot-lzma.img: u-boot.bin.lzma FORCE
u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \
$(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin \
- $(if $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb) \
+ $(if $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX),dts/dt.dtb) \
,$(UBOOT_BIN)) FORCE
$(call if_changed,mkimage)
$(BOARD_SIZE_CHECK)
diff --git a/dts/Kconfig b/dts/Kconfig
index 9994ab13dcb..6ebbac2a649 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -16,24 +16,6 @@ config BINMAN
bool
select DTOC
-config BINMAN_STANDALONE_FDT
- bool
- depends on BINMAN
- default y if OF_BOARD
- help
- This option tells U-Boot build system that a standalone device tree
- source is explicitly required when using binman to package U-Boot.
-
- This is not necessary in a common scenario where a device tree source
- that contains the binman node is provided in the arch/<arch>/dts
- directory for a specific board. Such device tree sources are built for
- OF_SEPARATE or OF_EMBED. However for a scenario like the board device
- tree blob is not provided in the U-Boot build tree, but fed to U-Boot
- in the runtime, e.g.: in the OF_BOARD case that it is passed by
- a prior stage bootloader. For such scenario, a standalone device tree
- blob containing binman node to describe how to package U-Boot should
- be provided explicitly.
-
menu "Device Tree Control"
depends on SUPPORT_OF_CONTROL
diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
index 35de93bd898..9ef6dc9db6a 100644
--- a/tools/binman/binman.rst
+++ b/tools/binman/binman.rst
@@ -232,26 +232,6 @@ You can use other, more specific CONFIG options - see 'Automatic .dtsi
inclusion' below.
-Using binman with OF_BOARD
---------------------------------------------
-
-Normally binman is used with a board configured with OF_SEPARATE or OF_EMBED.
-This is a typical scenario where a device tree source that contains the binman
-node is provided in the arch/<arch>/dts directory for a specific board.
-
-However for a board configured with OF_BOARD, no device tree blob is provided
-in the U-Boot build phase hence the binman node information is not available.
-In order to support such use case, a new Kconfig option BINMAN_STANDALONE_FDT
-is introduced, to tell the build system that a standalone device tree blob
-containing binman node is explicitly required.
-
-Note there is a Kconfig option BINMAN_FDT which enables U-Boot run time to
-access information about binman entries, stored in the device tree in a binman
-node. Generally speaking, this option makes sense for OF_SEPARATE or OF_EMBED.
-For the other OF_CONTROL methods, it's quite possible binman node is not
-available as binman is invoked during the build phase, thus this option is not
-turned on by default for these OF_CONTROL methods.
-
Access to binman entry offsets at run time (symbols)
----------------------------------------------------
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 17/25] doc: Update info on devicetree update
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (15 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 16/25] Drop CONFIG_BINMAN_STANDALONE_FDT Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 18/25] fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() Simon Glass
` (9 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass
Since OF_BOARD has been corrected to be a run-time option, we can drop
the historical info from this documentation.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
doc/develop/devicetree/dt_update.rst | 74 +++-------------------------
1 file changed, 8 insertions(+), 66 deletions(-)
diff --git a/doc/develop/devicetree/dt_update.rst b/doc/develop/devicetree/dt_update.rst
index a1429d6e21a..1461af60f29 100644
--- a/doc/develop/devicetree/dt_update.rst
+++ b/doc/develop/devicetree/dt_update.rst
@@ -32,66 +32,6 @@ 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
-----------------------
@@ -200,15 +140,18 @@ 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.
+Note: Dicussions on adding a binding for this to the Linux devicetree bindings
+are ongoing as of October 2021.
+
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 some cases U-Boot receives 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:
@@ -546,7 +489,6 @@ 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
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 18/25] fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup()
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (16 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 17/25] doc: Update info on devicetree update Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 19/25] fdt: Drop #ifdefs with MULTI_DTB_FIT Simon Glass
` (8 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Jerry Van Baren
This logic is a bit convoluted for one function. Move the mulit-FIT part
into its own function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
---
(no changes since v1)
lib/fdtdec.c | 62 ++++++++++++++++++++++++++++++++--------------------
1 file changed, 38 insertions(+), 24 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 7681f272d27..e0ce2532f95 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1594,13 +1594,46 @@ __weak int fdtdec_board_setup(const void *fdt_blob)
return 0;
}
+/**
+ * setup_multi_dtb_fit() - locate the correct dtb from a FIT
+ *
+ * This supports the CONFIG_MULTI_DTB_FIT feature, looking for the dtb in a
+ * supplied FIT
+ *
+ * It accepts the current value of gd->fdt_blob, which points to the FIT, then
+ * updates that gd->fdt_blob, to point to the chosen dtb so that U-Boot uses the
+ * correct one
+ */
+static void setup_multi_dtb_fit(void)
+{
+# if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
+ void *blob;
+
+ /*
+ * Try and uncompress the blob.
+ * Unfortunately there is no way to know how big the input blob really
+ * is. So let us set the maximum input size arbitrarily high. 16MB
+ * ought to be more than enough for packed DTBs.
+ */
+ if (uncompress_blob(gd->fdt_blob, 0x1000000, &blob) == 0)
+ gd->fdt_blob = blob;
+
+ /*
+ * Check if blob is a FIT images containings DTBs.
+ * If so, pick the most relevant
+ */
+ blob = locate_dtb_in_fit(gd->fdt_blob);
+ if (blob) {
+ gd->multi_dtb_fit = gd->fdt_blob;
+ gd->fdt_blob = blob;
+ }
+#endif /* # MULTI_DTB_FIT */
+}
+
int fdtdec_setup(void)
{
int ret;
#if CONFIG_IS_ENABLED(OF_CONTROL)
-# if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
- void *fdt_blob;
-# endif
# ifdef CONFIG_OF_EMBED
/* Get a pointer to the FDT */
# ifdef CONFIG_SPL_BUILD
@@ -1621,27 +1654,8 @@ int fdtdec_setup(void)
(unsigned long)map_to_sysmem(gd->fdt_blob)), 0);
# endif
-# if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
- /*
- * Try and uncompress the blob.
- * Unfortunately there is no way to know how big the input blob really
- * is. So let us set the maximum input size arbitrarily high. 16MB
- * ought to be more than enough for packed DTBs.
- */
- if (uncompress_blob(gd->fdt_blob, 0x1000000, &fdt_blob) == 0)
- gd->fdt_blob = fdt_blob;
-
- /*
- * Check if blob is a FIT images containings DTBs.
- * If so, pick the most relevant
- */
- fdt_blob = locate_dtb_in_fit(gd->fdt_blob);
- if (fdt_blob) {
- gd->multi_dtb_fit = gd->fdt_blob;
- gd->fdt_blob = fdt_blob;
- }
-
-# endif
+ if (CONFIG_IS_ENABLED(MULTI_DTB_FIT))
+ setup_multi_dtb_fit();
#endif
ret = fdtdec_prepare_fdt();
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 19/25] fdt: Drop #ifdefs with MULTI_DTB_FIT
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (17 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 18/25] fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 20/25] fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() Simon Glass
` (7 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Jerry Van Baren
Refactor the code to drop the #ifdefs for this feature.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
dts/Kconfig | 1 -
include/asm-generic/global_data.h | 8 ++++++++
lib/fdtdec.c | 31 +++++++++++--------------------
3 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/dts/Kconfig b/dts/Kconfig
index 6ebbac2a649..5dcc79d5192 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -177,7 +177,6 @@ endchoice
config MULTI_DTB_FIT_UNCOMPRESS_SZ
hex "Size of memory reserved to uncompress the DTBs"
- depends on (MULTI_DTB_FIT_GZIP || MULTI_DTB_FIT_LZO)
default 0x8000
help
This is the size of this area where the DTBs are uncompressed.
diff --git a/include/asm-generic/global_data.h b/include/asm-generic/global_data.h
index 16fd305a65c..99daa20c765 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -512,6 +512,14 @@ static_assert(sizeof(struct global_data) == GD_SIZE);
#define gd_acpi_ctx() NULL
#endif
+#if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
+#define gd_multi_dtb_fit() gd->multi_dtb_fit
+#define gd_set_multi_dtb_fit(_dtb) gd->multi_dtb_fit = _dtb
+#else
+#define gd_multi_dtb_fit() NULL
+#define gd_set_multi_dtb_fit(_dtb)
+#endif
+
/**
* enum gd_flags - global data flags
*
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index e0ce2532f95..4967ab87075 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1146,11 +1146,10 @@ int fdtdec_setup_mem_size_base_lowest(void)
return 0;
}
-#if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
-# if CONFIG_IS_ENABLED(MULTI_DTB_FIT_GZIP) ||\
- CONFIG_IS_ENABLED(MULTI_DTB_FIT_LZO)
static int uncompress_blob(const void *src, ulong sz_src, void **dstp)
{
+#if CONFIG_IS_ENABLED(MULTI_DTB_FIT_GZIP) ||\
+ CONFIG_IS_ENABLED(MULTI_DTB_FIT_LZO)
size_t sz_out = CONFIG_VAL(MULTI_DTB_FIT_UNCOMPRESS_SZ);
bool gzip = 0, lzo = 0;
ulong sz_in = sz_src;
@@ -1175,11 +1174,11 @@ static int uncompress_blob(const void *src, ulong sz_src, void **dstp)
return -ENOMEM;
}
} else {
-# if CONFIG_IS_ENABLED(MULTI_DTB_FIT_USER_DEFINED_AREA)
+# if CONFIG_IS_ENABLED(MULTI_DTB_FIT_USER_DEFINED_AREA)
dst = (void *)CONFIG_VAL(MULTI_DTB_FIT_USER_DEF_ADDR);
-# else
+# else
return -ENOTSUPP;
-# endif
+# endif
}
if (CONFIG_IS_ENABLED(GZIP) && gzip)
@@ -1197,16 +1196,12 @@ static int uncompress_blob(const void *src, ulong sz_src, void **dstp)
return -EBADMSG;
}
*dstp = dst;
- return 0;
-}
-# else
-static int uncompress_blob(const void *src, ulong sz_src, void **dstp)
-{
+#else
+ *dstp = (void *)src;
*dstp = (void *)src;
+#endif
return 0;
}
-# endif
-#endif
#if defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE)
/*
@@ -1606,7 +1601,6 @@ __weak int fdtdec_board_setup(const void *fdt_blob)
*/
static void setup_multi_dtb_fit(void)
{
-# if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
void *blob;
/*
@@ -1624,10 +1618,9 @@ static void setup_multi_dtb_fit(void)
*/
blob = locate_dtb_in_fit(gd->fdt_blob);
if (blob) {
- gd->multi_dtb_fit = gd->fdt_blob;
+ gd_set_multi_dtb_fit(gd->fdt_blob);
gd->fdt_blob = blob;
}
-#endif /* # MULTI_DTB_FIT */
}
int fdtdec_setup(void)
@@ -1664,7 +1657,6 @@ int fdtdec_setup(void)
return ret;
}
-#if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
int fdtdec_resetup(int *rescan)
{
void *fdt_blob;
@@ -1675,8 +1667,8 @@ int fdtdec_resetup(int *rescan)
* FIT image stillpresent there. Save the time and space
* required to uncompress it again.
*/
- if (gd->multi_dtb_fit) {
- fdt_blob = locate_dtb_in_fit(gd->multi_dtb_fit);
+ if (gd_multi_dtb_fit()) {
+ fdt_blob = locate_dtb_in_fit(gd_multi_dtb_fit());
if (fdt_blob == gd->fdt_blob) {
/*
@@ -1700,7 +1692,6 @@ int fdtdec_resetup(int *rescan)
*rescan = 0;
return 0;
}
-#endif
int fdtdec_decode_ram_size(const void *blob, const char *area, int board_id,
phys_addr_t *basep, phys_size_t *sizep,
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 20/25] fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup()
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (18 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 19/25] fdt: Drop #ifdefs with MULTI_DTB_FIT Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 21/25] fdt: Drop #ifdef around board_fdt_blob_setup() Simon Glass
` (6 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Jerry Van Baren
Move this to the header file to clean up the C code.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
include/fdtdec.h | 14 ++++++++++++++
lib/fdtdec.c | 6 +-----
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 6c7ab887b20..68786111a44 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -111,6 +111,20 @@ struct fdt_pci_addr {
extern u8 __dtb_dt_begin[]; /* embedded device tree blob */
extern u8 __dtb_dt_spl_begin[]; /* embedded device tree blob for SPL/TPL */
+/* Get a pointer to the embedded devicetree, if there is one, else NULL */
+static inline u8 *dtb_dt_embedded(void)
+{
+#ifdef CONFIG_OF_EMBED
+# ifdef CONFIG_SPL_BUILD
+ return __dtb_dt_spl_begin;
+# else
+ return __dtb_dt_begin;
+# endif
+#else
+ return NULL;
+#endif
+}
+
/**
* Compute the size of a resource.
*
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 4967ab87075..fbdc92c0813 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1629,11 +1629,7 @@ int fdtdec_setup(void)
#if CONFIG_IS_ENABLED(OF_CONTROL)
# ifdef CONFIG_OF_EMBED
/* Get a pointer to the FDT */
-# ifdef CONFIG_SPL_BUILD
- gd->fdt_blob = __dtb_dt_spl_begin;
-# else
- gd->fdt_blob = __dtb_dt_begin;
-# endif
+ gd->fdt_blob = dtb_dt_embedded();
# elif defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE)
/* Allow the board to override the fdt address. */
gd->fdt_blob = board_fdt_blob_setup(&ret);
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 21/25] fdt: Drop #ifdef around board_fdt_blob_setup()
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (19 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 20/25] fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 22/25] fdt: Use if() for fdtcontroladdr check Simon Glass
` (5 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Jerry Van Baren
This serves no purpose. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
lib/fdtdec.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index fbdc92c0813..299a2c3a32f 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1203,7 +1203,6 @@ static int uncompress_blob(const void *src, ulong sz_src, void **dstp)
return 0;
}
-#if defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE)
/*
* For CONFIG_OF_SEPARATE, the board may optionally implement this to
* provide and/or fixup the fdt.
@@ -1226,7 +1225,6 @@ __weak void *board_fdt_blob_setup(int *err)
return fdt_blob;
}
-#endif
int fdtdec_set_ethernet_mac_address(void *fdt, const u8 *mac, size_t size)
{
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 22/25] fdt: Use if() for fdtcontroladdr check
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (20 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 21/25] fdt: Drop #ifdef around board_fdt_blob_setup() Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 15:59 ` [PATCH v6 25/25] fdt: Don't call board_fdt_blob_setup() without OF_BOARD Simon Glass
` (4 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Jerry Van Baren
Change this to use if() instead of #if
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
lib/fdtdec.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 299a2c3a32f..659aeffd82e 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1634,12 +1634,11 @@ int fdtdec_setup(void)
if (ret)
return ret;
# endif
-# ifndef CONFIG_SPL_BUILD
- /* Allow the early environment to override the fdt address */
- gd->fdt_blob = map_sysmem
- (env_get_ulong("fdtcontroladdr", 16,
+ if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
+ /* Allow the early environment to override the fdt address */
+ gd->fdt_blob = map_sysmem(env_get_ulong("fdtcontroladdr", 16,
(unsigned long)map_to_sysmem(gd->fdt_blob)), 0);
-# endif
+ }
if (CONFIG_IS_ENABLED(MULTI_DTB_FIT))
setup_multi_dtb_fit();
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v6 25/25] fdt: Don't call board_fdt_blob_setup() without OF_BOARD
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (21 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 22/25] fdt: Use if() for fdtcontroladdr check Simon Glass
@ 2021-12-02 15:59 ` Simon Glass
2021-12-02 16:33 ` [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option François Ozog
` (3 subsequent siblings)
26 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 15:59 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Heinrich Schuchardt, Simon Glass,
Jerry Van Baren
At present this override function is called even when OF_BOARD Is not
enabled. This makes it impossible to disable this feature and in fact
makes the OF_BOARD option useless.
Reinstate its intended purpose, so that it is possible to switch between
the appended devicetree and one provided by the board's custom function.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v5)
Changes in v5:
- Add new patches to clean up fdtdec_setup() and surrounds
include/fdtdec.h | 7 +++++--
lib/fdtdec.c | 21 ++++++++++++---------
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 68786111a44..68a36f10583 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -1170,10 +1170,13 @@ int fdtdec_resetup(int *rescan);
/**
* Board-specific FDT initialization. Returns the address to a device tree blob.
- * Called when CONFIG_OF_BOARD is defined, or if CONFIG_OF_SEPARATE is defined
- * and the board implements it.
+ *
+ * Called when CONFIG_OF_BOARD is defined.
+ *
+ * The existing devicetree is available at gd->fdt_blob
*
* @err internal error code if we fail to setup a DTB
+ * @returns new devicetree blob pointer
*/
void *board_fdt_blob_setup(int *err);
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index a7f62123a94..31a509bc221 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1203,15 +1203,15 @@ static int uncompress_blob(const void *src, ulong sz_src, void **dstp)
return 0;
}
-/*
- * For CONFIG_OF_SEPARATE, the board may optionally implement this to
- * provide and/or fixup the fdt.
+/**
+ * fdt_find_separate() - Find a devicetree at the end of the image
+ *
+ * @return pointer to FDT blob
*/
-__weak void *board_fdt_blob_setup(int *err)
+static void *fdt_find_separate(void)
{
void *fdt_blob = NULL;
- *err = 0;
#ifdef CONFIG_SPL_BUILD
/* FDT is at end of BSS unless it is in a different memory region */
if (IS_ENABLED(CONFIG_SPL_SEPARATE_BSS))
@@ -1626,13 +1626,16 @@ int fdtdec_setup(void)
int ret;
/* The devicetree is typically appended to U-Boot */
- if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD)) {
- /* Allow the board to override the fdt address. */
+ if (IS_ENABLED(CONFIG_OF_SEPARATE))
+ gd->fdt_blob = fdt_find_separate();
+ else /* embed dtb in ELF file for testing / development */
+ gd->fdt_blob = dtb_dt_embedded();
+
+ /* Allow the board to override the fdt address. */
+ if (IS_ENABLED(CONFIG_OF_BOARD)) {
gd->fdt_blob = board_fdt_blob_setup(&ret);
if (ret)
return ret;
- } else { /* embed dtb in ELF file for testing / development */
- gd->fdt_blob = dtb_dt_embedded();
}
if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
--
2.34.0.rc2.393.gf8c9666880-goog
^ permalink raw reply related [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (22 preceding siblings ...)
2021-12-02 15:59 ` [PATCH v6 25/25] fdt: Don't call board_fdt_blob_setup() without OF_BOARD Simon Glass
@ 2021-12-02 16:33 ` François Ozog
2021-12-02 16:38 ` Tom Rini
2021-12-02 16:39 ` Simon Glass
2021-12-02 16:47 ` Heinrich Schuchardt
` (2 subsequent siblings)
26 siblings, 2 replies; 136+ messages in thread
From: François Ozog @ 2021-12-02 16:33 UTC (permalink / raw)
To: Simon Glass
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons, Tom Rini,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Simon
Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> there are only three ways to obtain a devicetree:
>
> - OF_SEPARATE - the normal way, where the devicetree is built and
> appended to U-Boot
> - OF_EMBED - for development purposes, the devicetree is embedded in
> the ELF file (also used for EFI)
> - OF_BOARD - the board figures it out on its own
>
> The last one is currently set up so that no devicetree is needed at all
> in the U-Boot tree. Most boards do provide one, but some don't. Some
> don't even provide instructions on how to boot on the board.
>
> The problems with this approach are documented in another patch in this
> series: "doc: Add documentation about devicetree usage"
>
> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> can obtain its devicetree at runtime, even it is has a devicetree built
> in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> caller may have a better idea about the hardware available in the machine.
> This is the case with a few QEMU boards, for example.
>
> So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> option, available with either OF_SEPARATE or OF_EMBED.
>
> This series makes this change, adding various missing devicetree files
> (and placeholders) to make the build work.
>
> Note: If board maintainers are able to add their own patch to add the
> files, some patches in this series can be dropped.
>
> It also provides a few qemu clean-ups discovered along the way. The
> qemu-riscv64_spl problem is fixed.
>
> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>
> Changes in v6:
> - Fix description of OF_BOARD so it refers just to the current state
> - Explain that the 'two devicetrees' refers to two *control* devicetrees
> - Expand the commit message based on comments
> - Expand the commit message based on comments
You haven’t addressed any concerns expressed on the mailing list.so I am
not in favor of this new version either.
If you make a version without « fake DTs » as you name them, there are good
advances in the documentation and other areas that would be better in
mainline….
If I am the only one thinking this way and the patch can be accepted, I
would love there is a warning in capital letters at the top of the DTS fake
files that explains the intent of this fake DT, the possible outcomes of
not using the one provided by the platform and the right way of dealing
with DTs for the platform.
>
> 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
> - Merge RISC-V and ARM patches since they are similar
> - Add new patches to clean up fdtdec_setup() and surrounds
>
> 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?'
>
> Simon Glass (25):
> doc: Add documentation about devicetree usage
> arm: qemu: Mention -nographic in the docs
> arm: riscv: qemu: Explain how to extract the generated dt
> arm: qemu: Add a devicetree file for qemu_arm
> arm: qemu: Add a devicetree file for qemu_arm64
> riscv: qemu: Add devicetree files for qemu_riscv32/64
> arm: rpi: Add a devicetree file for rpi_4
> arm: vexpress: Add a devicetree file for juno
> arm: xenguest_arm64: Add a fake devicetree file
> arm: octeontx: Add a fake devicetree file
> arm: xilinx_versal_virt: Add a devicetree file
> arm: bcm7xxx: Add a devicetree file
> arm: qemu-ppce500: Add a devicetree file
> arm: highbank: Add a fake devicetree file
> fdt: Make OF_BOARD a bool option
> Drop CONFIG_BINMAN_STANDALONE_FDT
> doc: Update info on devicetree update
> fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup()
> fdt: Drop #ifdefs with MULTI_DTB_FIT
> fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup()
> fdt: Drop #ifdef around board_fdt_blob_setup()
> fdt: Use if() for fdtcontroladdr check
> fdt: Drop OF_CONTROL check in fdtdec_setup()
> fdt: Drop remaining preprocessor macros in fdtdec_setup()
> fdt: Don't call board_fdt_blob_setup() without OF_BOARD
>
> Makefile | 3 +-
> arch/arm/dts/Makefile | 20 +-
> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++
> arch/arm/dts/bcm7xxx.dts | 15 +
> arch/arm/dts/highbank.dts | 14 +
> arch/arm/dts/juno-r2.dts | 1038 +++++++++++++
> arch/arm/dts/octeontx.dts | 14 +
> arch/arm/dts/qemu-arm.dts | 402 +++++
> arch/arm/dts/qemu-arm64.dts | 381 +++++
> arch/arm/dts/xenguest-arm64.dts | 15 +
> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++
> arch/powerpc/dts/Makefile | 1 +
> arch/powerpc/dts/qemu-ppce500.dts | 264 ++++
> arch/riscv/dts/Makefile | 2 +-
> arch/riscv/dts/qemu-virt.dts | 8 -
> arch/riscv/dts/qemu-virt32.dts | 217 +++
> arch/riscv/dts/qemu-virt64.dts | 217 +++
> configs/bcm7260_defconfig | 1 +
> configs/bcm7445_defconfig | 1 +
> configs/highbank_defconfig | 2 +-
> configs/octeontx2_95xx_defconfig | 1 +
> configs/octeontx2_96xx_defconfig | 1 +
> configs/octeontx_81xx_defconfig | 1 +
> configs/octeontx_83xx_defconfig | 1 +
> configs/qemu-ppce500_defconfig | 2 +
> configs/qemu-riscv32_defconfig | 1 +
> configs/qemu-riscv32_smode_defconfig | 1 +
> configs/qemu-riscv32_spl_defconfig | 4 +-
> configs/qemu-riscv64_defconfig | 1 +
> configs/qemu-riscv64_smode_defconfig | 1 +
> configs/qemu-riscv64_spl_defconfig | 3 +-
> configs/qemu_arm64_defconfig | 1 +
> configs/qemu_arm_defconfig | 1 +
> configs/rpi_4_32b_defconfig | 1 +
> configs/rpi_4_defconfig | 1 +
> configs/rpi_arm64_defconfig | 1 +
> configs/vexpress_aemv8a_juno_defconfig | 1 +
> configs/xenguest_arm64_defconfig | 2 +-
> configs/xilinx_versal_virt_defconfig | 1 +
> doc/board/emulation/qemu-arm.rst | 10 +-
> doc/board/emulation/qemu-riscv.rst | 3 +
> doc/develop/devicetree/dt_qemu.rst | 48 +
> doc/develop/devicetree/dt_update.rst | 497 ++++++
> doc/develop/devicetree/index.rst | 2 +
> dts/Kconfig | 30 +-
> include/asm-generic/global_data.h | 8 +
> include/fdtdec.h | 21 +-
> lib/fdtdec.c | 117 +-
> tools/binman/binman.rst | 20 -
> 49 files changed, 5538 insertions(+), 124 deletions(-)
> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> create mode 100644 arch/arm/dts/bcm7xxx.dts
> create mode 100644 arch/arm/dts/highbank.dts
> create mode 100644 arch/arm/dts/juno-r2.dts
> create mode 100644 arch/arm/dts/octeontx.dts
> create mode 100644 arch/arm/dts/qemu-arm.dts
> create mode 100644 arch/arm/dts/qemu-arm64.dts
> create mode 100644 arch/arm/dts/xenguest-arm64.dts
> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
> delete mode 100644 arch/riscv/dts/qemu-virt.dts
> create mode 100644 arch/riscv/dts/qemu-virt32.dts
> create mode 100644 arch/riscv/dts/qemu-virt64.dts
> create mode 100644 doc/develop/devicetree/dt_qemu.rst
> create mode 100644 doc/develop/devicetree/dt_update.rst
>
> --
> 2.34.0.rc2.393.gf8c9666880-goog
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 16:33 ` [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option François Ozog
@ 2021-12-02 16:38 ` Tom Rini
2021-12-02 16:49 ` Simon Glass
2021-12-02 17:03 ` Ilias Apalodimas
2021-12-02 16:39 ` Simon Glass
1 sibling, 2 replies; 136+ messages in thread
From: Tom Rini @ 2021-12-02 16:38 UTC (permalink / raw)
To: François Ozog, Simon Glass
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 3166 bytes --]
On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> Hi Simon
>
> Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
>
> > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > there are only three ways to obtain a devicetree:
> >
> > - OF_SEPARATE - the normal way, where the devicetree is built and
> > appended to U-Boot
> > - OF_EMBED - for development purposes, the devicetree is embedded in
> > the ELF file (also used for EFI)
> > - OF_BOARD - the board figures it out on its own
> >
> > The last one is currently set up so that no devicetree is needed at all
> > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > don't even provide instructions on how to boot on the board.
> >
> > The problems with this approach are documented in another patch in this
> > series: "doc: Add documentation about devicetree usage"
> >
> > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > can obtain its devicetree at runtime, even it is has a devicetree built
> > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > caller may have a better idea about the hardware available in the machine.
> > This is the case with a few QEMU boards, for example.
> >
> > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > option, available with either OF_SEPARATE or OF_EMBED.
> >
> > This series makes this change, adding various missing devicetree files
> > (and placeholders) to make the build work.
> >
> > Note: If board maintainers are able to add their own patch to add the
> > files, some patches in this series can be dropped.
> >
> > It also provides a few qemu clean-ups discovered along the way. The
> > qemu-riscv64_spl problem is fixed.
> >
> > [1]
> > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >
> > Changes in v6:
> > - Fix description of OF_BOARD so it refers just to the current state
> > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > - Expand the commit message based on comments
> > - Expand the commit message based on comments
>
> You haven’t addressed any concerns expressed on the mailing list.so I am
> not in favor of this new version either.
> If you make a version without « fake DTs » as you name them, there are good
> advances in the documentation and other areas that would be better in
> mainline….
> If I am the only one thinking this way and the patch can be accepted, I
> would love there is a warning in capital letters at the top of the DTS fake
> files that explains the intent of this fake DT, the possible outcomes of
> not using the one provided by the platform and the right way of dealing
> with DTs for the platform.
This is the part that I too am still unhappy about. I do not want
reference or fake or whatever device trees in the U-Boot source tree.
We should be able to _remove_ the ones we have, that are not required,
with doc/board/...rst explaining how to get / view one. Not adding
more.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 16:38 ` Tom Rini
@ 2021-12-02 16:49 ` Simon Glass
2021-12-02 16:59 ` Tom Rini
2021-12-02 17:03 ` Ilias Apalodimas
1 sibling, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 16:49 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Tom,
On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > Hi Simon
> >
> > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> >
> > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > there are only three ways to obtain a devicetree:
> > >
> > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > appended to U-Boot
> > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > the ELF file (also used for EFI)
> > > - OF_BOARD - the board figures it out on its own
> > >
> > > The last one is currently set up so that no devicetree is needed at all
> > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > don't even provide instructions on how to boot on the board.
> > >
> > > The problems with this approach are documented in another patch in this
> > > series: "doc: Add documentation about devicetree usage"
> > >
> > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > caller may have a better idea about the hardware available in the machine.
> > > This is the case with a few QEMU boards, for example.
> > >
> > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > option, available with either OF_SEPARATE or OF_EMBED.
> > >
> > > This series makes this change, adding various missing devicetree files
> > > (and placeholders) to make the build work.
> > >
> > > Note: If board maintainers are able to add their own patch to add the
> > > files, some patches in this series can be dropped.
> > >
> > > It also provides a few qemu clean-ups discovered along the way. The
> > > qemu-riscv64_spl problem is fixed.
> > >
> > > [1]
> > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > >
> > > Changes in v6:
> > > - Fix description of OF_BOARD so it refers just to the current state
> > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > - Expand the commit message based on comments
> > > - Expand the commit message based on comments
> >
> > You haven’t addressed any concerns expressed on the mailing list.so I am
> > not in favor of this new version either.
> > If you make a version without « fake DTs » as you name them, there are good
> > advances in the documentation and other areas that would be better in
> > mainline….
> > If I am the only one thinking this way and the patch can be accepted, I
> > would love there is a warning in capital letters at the top of the DTS fake
> > files that explains the intent of this fake DT, the possible outcomes of
> > not using the one provided by the platform and the right way of dealing
> > with DTs for the platform.
>
> This is the part that I too am still unhappy about. I do not want
> reference or fake or whatever device trees in the U-Boot source tree.
> We should be able to _remove_ the ones we have, that are not required,
> with doc/board/...rst explaining how to get / view one. Not adding
> more.
I understand you don't like it and that others don't as well. I wish
it had not come to this.
However we are only talking about 10 boards, three of which don't even
have a devicetree anywhere I can find.
I think on balance this is a substantial clean-up. I am happy to add
whatever caveats and documentation people want to clarify what is
going on here. I'm happy to look at future options where the
devicetree is hosted elsewhere, so long as it is trivial to build it
within U-Boot for development purposes.
I'll also note that the bootstd series shows the devicetree source:
Core: 246 devices, 88 uclasses, devicetree: board
But for now, I still feel this is the best path forward.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 16:49 ` Simon Glass
@ 2021-12-02 16:59 ` Tom Rini
2021-12-02 17:07 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-02 16:59 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 5219 bytes --]
On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > Hi Simon
> > >
> > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > >
> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > there are only three ways to obtain a devicetree:
> > > >
> > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > appended to U-Boot
> > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > the ELF file (also used for EFI)
> > > > - OF_BOARD - the board figures it out on its own
> > > >
> > > > The last one is currently set up so that no devicetree is needed at all
> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > don't even provide instructions on how to boot on the board.
> > > >
> > > > The problems with this approach are documented in another patch in this
> > > > series: "doc: Add documentation about devicetree usage"
> > > >
> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > caller may have a better idea about the hardware available in the machine.
> > > > This is the case with a few QEMU boards, for example.
> > > >
> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > >
> > > > This series makes this change, adding various missing devicetree files
> > > > (and placeholders) to make the build work.
> > > >
> > > > Note: If board maintainers are able to add their own patch to add the
> > > > files, some patches in this series can be dropped.
> > > >
> > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > qemu-riscv64_spl problem is fixed.
> > > >
> > > > [1]
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > >
> > > > Changes in v6:
> > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > - Expand the commit message based on comments
> > > > - Expand the commit message based on comments
> > >
> > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > not in favor of this new version either.
> > > If you make a version without « fake DTs » as you name them, there are good
> > > advances in the documentation and other areas that would be better in
> > > mainline….
> > > If I am the only one thinking this way and the patch can be accepted, I
> > > would love there is a warning in capital letters at the top of the DTS fake
> > > files that explains the intent of this fake DT, the possible outcomes of
> > > not using the one provided by the platform and the right way of dealing
> > > with DTs for the platform.
> >
> > This is the part that I too am still unhappy about. I do not want
> > reference or fake or whatever device trees in the U-Boot source tree.
> > We should be able to _remove_ the ones we have, that are not required,
> > with doc/board/...rst explaining how to get / view one. Not adding
> > more.
>
> I understand you don't like it and that others don't as well. I wish
> it had not come to this.
>
> However we are only talking about 10 boards, three of which don't even
> have a devicetree anywhere I can find.
>
> I think on balance this is a substantial clean-up. I am happy to add
> whatever caveats and documentation people want to clarify what is
> going on here. I'm happy to look at future options where the
> devicetree is hosted elsewhere, so long as it is trivial to build it
> within U-Boot for development purposes.
>
> I'll also note that the bootstd series shows the devicetree source:
>
> Core: 246 devices, 88 uclasses, devicetree: board
>
> But for now, I still feel this is the best path forward.
I'm not sure how to proceed here. The reviews are rather strongly
against the "include a device tree that won't be used". The use case of
"but for development someone might need to modify the device tree" is
handled by platforms documenting where / how to get the real one. We
should even update the Kconfig help to note that if you enable this your
board docs MUST explain where the device tree can be seen (or have some
legal reason you think it's OK to not...).
And yes, we're "only" talking about 10 platforms, which include things
like the "everyone" has one Pi family, the extraordinarily flexible (and
so easy for the reference device tree to be very wrong) QEMU families
and then platforms that are including a dts in-tree now because they
were told that was required.
How about adjusting the make logic so that if a tree isn't found, we use
a dummy minimal valid dts file?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 16:59 ` Tom Rini
@ 2021-12-02 17:07 ` Simon Glass
2021-12-02 18:03 ` Tom Rini
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 17:07 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Tom,
On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > Hi Simon
> > > >
> > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > >
> > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > there are only three ways to obtain a devicetree:
> > > > >
> > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > appended to U-Boot
> > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > the ELF file (also used for EFI)
> > > > > - OF_BOARD - the board figures it out on its own
> > > > >
> > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > don't even provide instructions on how to boot on the board.
> > > > >
> > > > > The problems with this approach are documented in another patch in this
> > > > > series: "doc: Add documentation about devicetree usage"
> > > > >
> > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > caller may have a better idea about the hardware available in the machine.
> > > > > This is the case with a few QEMU boards, for example.
> > > > >
> > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > >
> > > > > This series makes this change, adding various missing devicetree files
> > > > > (and placeholders) to make the build work.
> > > > >
> > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > files, some patches in this series can be dropped.
> > > > >
> > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > qemu-riscv64_spl problem is fixed.
> > > > >
> > > > > [1]
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > >
> > > > > Changes in v6:
> > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > - Expand the commit message based on comments
> > > > > - Expand the commit message based on comments
> > > >
> > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > not in favor of this new version either.
> > > > If you make a version without « fake DTs » as you name them, there are good
> > > > advances in the documentation and other areas that would be better in
> > > > mainline….
> > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > not using the one provided by the platform and the right way of dealing
> > > > with DTs for the platform.
> > >
> > > This is the part that I too am still unhappy about. I do not want
> > > reference or fake or whatever device trees in the U-Boot source tree.
> > > We should be able to _remove_ the ones we have, that are not required,
> > > with doc/board/...rst explaining how to get / view one. Not adding
> > > more.
> >
> > I understand you don't like it and that others don't as well. I wish
> > it had not come to this.
> >
> > However we are only talking about 10 boards, three of which don't even
> > have a devicetree anywhere I can find.
> >
> > I think on balance this is a substantial clean-up. I am happy to add
> > whatever caveats and documentation people want to clarify what is
> > going on here. I'm happy to look at future options where the
> > devicetree is hosted elsewhere, so long as it is trivial to build it
> > within U-Boot for development purposes.
> >
> > I'll also note that the bootstd series shows the devicetree source:
> >
> > Core: 246 devices, 88 uclasses, devicetree: board
> >
> > But for now, I still feel this is the best path forward.
>
> I'm not sure how to proceed here. The reviews are rather strongly
> against the "include a device tree that won't be used". The use case of
> "but for development someone might need to modify the device tree" is
> handled by platforms documenting where / how to get the real one. We
> should even update the Kconfig help to note that if you enable this your
> board docs MUST explain where the device tree can be seen (or have some
> legal reason you think it's OK to not...).
Right, we can do lots of things as we have discussed. I am very
willing to work on these and make sure it is hard to do the thing. But
this series is long enough already.
It is more than just development. A devicetree is needed for binman to
work, even if it is empty. The documentation idea doesn't really work,
as I think I have proven by the difficulty in getting this series
together. An automated mechanism that runs in CI might be acceptable,
but that is in the future. For now, I believe it just HAS to be
in-tree.
>
> And yes, we're "only" talking about 10 platforms, which include things
> like the "everyone" has one Pi family, the extraordinarily flexible (and
> so easy for the reference device tree to be very wrong) QEMU families
> and then platforms that are including a dts in-tree now because they
> were told that was required.
Actually it is only rpi4 that doesn't have an in-tree DT. There is
actually no reason for it not to, e.g. Linux has it. Why not U-Boot?
The argument is the same.
Most QEMU boards have an in-tree devicetree. It is only ARM (now
copied by RISC-V) which doesn't.
>
> How about adjusting the make logic so that if a tree isn't found, we use
> a dummy minimal valid dts file?
This is what I have done for the boards where I could not figure out
how to get any sort of DT, yes. But I don't think that should be the
default.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 17:07 ` Simon Glass
@ 2021-12-02 18:03 ` Tom Rini
2021-12-02 18:17 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-02 18:03 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 8328 bytes --]
On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > Hi Simon
> > > > >
> > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > >
> > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > there are only three ways to obtain a devicetree:
> > > > > >
> > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > appended to U-Boot
> > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > the ELF file (also used for EFI)
> > > > > > - OF_BOARD - the board figures it out on its own
> > > > > >
> > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > don't even provide instructions on how to boot on the board.
> > > > > >
> > > > > > The problems with this approach are documented in another patch in this
> > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > >
> > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > This is the case with a few QEMU boards, for example.
> > > > > >
> > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > >
> > > > > > This series makes this change, adding various missing devicetree files
> > > > > > (and placeholders) to make the build work.
> > > > > >
> > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > files, some patches in this series can be dropped.
> > > > > >
> > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > qemu-riscv64_spl problem is fixed.
> > > > > >
> > > > > > [1]
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > >
> > > > > > Changes in v6:
> > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > - Expand the commit message based on comments
> > > > > > - Expand the commit message based on comments
> > > > >
> > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > not in favor of this new version either.
> > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > advances in the documentation and other areas that would be better in
> > > > > mainline….
> > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > not using the one provided by the platform and the right way of dealing
> > > > > with DTs for the platform.
> > > >
> > > > This is the part that I too am still unhappy about. I do not want
> > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > We should be able to _remove_ the ones we have, that are not required,
> > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > more.
> > >
> > > I understand you don't like it and that others don't as well. I wish
> > > it had not come to this.
> > >
> > > However we are only talking about 10 boards, three of which don't even
> > > have a devicetree anywhere I can find.
> > >
> > > I think on balance this is a substantial clean-up. I am happy to add
> > > whatever caveats and documentation people want to clarify what is
> > > going on here. I'm happy to look at future options where the
> > > devicetree is hosted elsewhere, so long as it is trivial to build it
> > > within U-Boot for development purposes.
> > >
> > > I'll also note that the bootstd series shows the devicetree source:
> > >
> > > Core: 246 devices, 88 uclasses, devicetree: board
> > >
> > > But for now, I still feel this is the best path forward.
> >
> > I'm not sure how to proceed here. The reviews are rather strongly
> > against the "include a device tree that won't be used". The use case of
> > "but for development someone might need to modify the device tree" is
> > handled by platforms documenting where / how to get the real one. We
> > should even update the Kconfig help to note that if you enable this your
> > board docs MUST explain where the device tree can be seen (or have some
> > legal reason you think it's OK to not...).
>
> Right, we can do lots of things as we have discussed. I am very
> willing to work on these and make sure it is hard to do the thing. But
> this series is long enough already.
Yes, I think the rest of us had hoped you would come around to all of
our reasoning by this point, is why this is taking so long.
> It is more than just development. A devicetree is needed for binman to
> work, even if it is empty. The documentation idea doesn't really work,
> as I think I have proven by the difficulty in getting this series
> together. An automated mechanism that runs in CI might be acceptable,
> but that is in the future. For now, I believe it just HAS to be
> in-tree.
I still don't see any reason why we need these incorrect and not
functionally used device trees in-tree when a dummy invalid tree is
enough to make things link. We're dealing with real "we must have X.bin
in the output for things to function" issues on other platforms with
binman right now. Using a dummy dts should be fine.
> > And yes, we're "only" talking about 10 platforms, which include things
> > like the "everyone" has one Pi family, the extraordinarily flexible (and
> > so easy for the reference device tree to be very wrong) QEMU families
> > and then platforms that are including a dts in-tree now because they
> > were told that was required.
>
> Actually it is only rpi4 that doesn't have an in-tree DT. There is
> actually no reason for it not to, e.g. Linux has it. Why not U-Boot?
> The argument is the same.
Because we don't need it! It serves no purpose! It exists in Linux
as that's the primary device tree source repository. We could _copy_ it
in, if it was useful. But then we need to re-sync it every so often,
and for less clear reasons than all of the platforms that we need to
sync with the kernel for, AND we use the tree.
There's even an argument to be made that it IS in Linux because when you
build that dtb, it's what the firmware then ships and uses and provides
to everyone at run time, possibly along with whatever other
modifications the binary firmware did (see the assorted threads,
including one this week about the problems we have because we don't just
always use the dtb provided to us at run time).
> Most QEMU boards have an in-tree devicetree. It is only ARM (now
> copied by RISC-V) which doesn't.
Yes, these are more examples of "someone said we need to copy it in, so
we copy it in".
> > How about adjusting the make logic so that if a tree isn't found, we use
> > a dummy minimal valid dts file?
>
> This is what I have done for the boards where I could not figure out
> how to get any sort of DT, yes. But I don't think that should be the
> default.
The more I think about this, the more I think dummy minimal valid dts
should be the fall-back default. This then solves the "I'm a developer,
I need to modify the dts files" case because you then just provide the
dts instead where it should go, and it's used.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 18:03 ` Tom Rini
@ 2021-12-02 18:17 ` Simon Glass
2021-12-02 18:34 ` Tom Rini
2021-12-03 1:29 ` Andre Przywara
0 siblings, 2 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 18:17 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Tom,
On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > Hi Simon
> > > > > >
> > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > >
> > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > there are only three ways to obtain a devicetree:
> > > > > > >
> > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > appended to U-Boot
> > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > the ELF file (also used for EFI)
> > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > >
> > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > >
> > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > >
> > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > >
> > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > >
> > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > (and placeholders) to make the build work.
> > > > > > >
> > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > files, some patches in this series can be dropped.
> > > > > > >
> > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > >
> > > > > > > [1]
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > >
> > > > > > > Changes in v6:
> > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > - Expand the commit message based on comments
> > > > > > > - Expand the commit message based on comments
> > > > > >
> > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > not in favor of this new version either.
> > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > advances in the documentation and other areas that would be better in
> > > > > > mainline….
> > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > with DTs for the platform.
> > > > >
> > > > > This is the part that I too am still unhappy about. I do not want
> > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > more.
> > > >
> > > > I understand you don't like it and that others don't as well. I wish
> > > > it had not come to this.
> > > >
> > > > However we are only talking about 10 boards, three of which don't even
> > > > have a devicetree anywhere I can find.
> > > >
> > > > I think on balance this is a substantial clean-up. I am happy to add
> > > > whatever caveats and documentation people want to clarify what is
> > > > going on here. I'm happy to look at future options where the
> > > > devicetree is hosted elsewhere, so long as it is trivial to build it
> > > > within U-Boot for development purposes.
> > > >
> > > > I'll also note that the bootstd series shows the devicetree source:
> > > >
> > > > Core: 246 devices, 88 uclasses, devicetree: board
> > > >
> > > > But for now, I still feel this is the best path forward.
> > >
> > > I'm not sure how to proceed here. The reviews are rather strongly
> > > against the "include a device tree that won't be used". The use case of
> > > "but for development someone might need to modify the device tree" is
> > > handled by platforms documenting where / how to get the real one. We
> > > should even update the Kconfig help to note that if you enable this your
> > > board docs MUST explain where the device tree can be seen (or have some
> > > legal reason you think it's OK to not...).
> >
> > Right, we can do lots of things as we have discussed. I am very
> > willing to work on these and make sure it is hard to do the thing. But
> > this series is long enough already.
>
> Yes, I think the rest of us had hoped you would come around to all of
> our reasoning by this point, is why this is taking so long.
>
Look, if I thought this was all wrong I would not be doing it. We have
a range of opinions:
- U-Boot should not have its own nodes/properties
- U-Boot should not have DTs in-tree
- U-Boot should have DTs only when essential
- U-Boot should have DTs in-tree for all boards
What's the downside here anyway?
> > It is more than just development. A devicetree is needed for binman to
> > work, even if it is empty. The documentation idea doesn't really work,
> > as I think I have proven by the difficulty in getting this series
> > together. An automated mechanism that runs in CI might be acceptable,
> > but that is in the future. For now, I believe it just HAS to be
> > in-tree.
>
> I still don't see any reason why we need these incorrect and not
> functionally used device trees in-tree when a dummy invalid tree is
> enough to make things link. We're dealing with real "we must have X.bin
> in the output for things to function" issues on other platforms with
> binman right now. Using a dummy dts should be fine.
Incorrect in what way?
How do I get a real one for development? How do I turn off OF_BOARD
and use the in-tree one?
The documentation approach is not good enough.
>
> > > And yes, we're "only" talking about 10 platforms, which include things
> > > like the "everyone" has one Pi family, the extraordinarily flexible (and
> > > so easy for the reference device tree to be very wrong) QEMU families
> > > and then platforms that are including a dts in-tree now because they
> > > were told that was required.
> >
> > Actually it is only rpi4 that doesn't have an in-tree DT. There is
> > actually no reason for it not to, e.g. Linux has it. Why not U-Boot?
> > The argument is the same.
>
> Because we don't need it! It serves no purpose! It exists in Linux
> as that's the primary device tree source repository. We could _copy_ it
> in, if it was useful. But then we need to re-sync it every so often,
> and for less clear reasons than all of the platforms that we need to
> sync with the kernel for, AND we use the tree.
So some people don't need it and it serves no purpose for them. But
why do they care? It is not hurting anyone. This is all overblown.
>
> There's even an argument to be made that it IS in Linux because when you
> build that dtb, it's what the firmware then ships and uses and provides
> to everyone at run time, possibly along with whatever other
> modifications the binary firmware did (see the assorted threads,
> including one this week about the problems we have because we don't just
> always use the dtb provided to us at run time).
>
> > Most QEMU boards have an in-tree devicetree. It is only ARM (now
> > copied by RISC-V) which doesn't.
>
> Yes, these are more examples of "someone said we need to copy it in, so
> we copy it in".
No that's not correct. With x86, ppc, integrator, ast2500 and many
others we *need* the DT and *it is not* created by QEMU.
>
> > > How about adjusting the make logic so that if a tree isn't found, we use
> > > a dummy minimal valid dts file?
> >
> > This is what I have done for the boards where I could not figure out
> > how to get any sort of DT, yes. But I don't think that should be the
> > default.
>
> The more I think about this, the more I think dummy minimal valid dts
> should be the fall-back default. This then solves the "I'm a developer,
> I need to modify the dts files" case because you then just provide the
> dts instead where it should go, and it's used.
How does it solve it? I don't even know how to get it in many cases.
If it is a dummy then I cannot actually use it for development, right?
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 18:17 ` Simon Glass
@ 2021-12-02 18:34 ` Tom Rini
2021-12-02 19:12 ` Simon Glass
` (2 more replies)
2021-12-03 1:29 ` Andre Przywara
1 sibling, 3 replies; 136+ messages in thread
From: Tom Rini @ 2021-12-02 18:34 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 12994 bytes --]
On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > Hi Simon
> > > > > > >
> > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > > >
> > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > >
> > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > > appended to U-Boot
> > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > > the ELF file (also used for EFI)
> > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > >
> > > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > > >
> > > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > >
> > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > >
> > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > >
> > > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > > (and placeholders) to make the build work.
> > > > > > > >
> > > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > > files, some patches in this series can be dropped.
> > > > > > > >
> > > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > >
> > > > > > > > [1]
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > >
> > > > > > > > Changes in v6:
> > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > - Expand the commit message based on comments
> > > > > > > > - Expand the commit message based on comments
> > > > > > >
> > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > not in favor of this new version either.
> > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > mainline….
> > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > with DTs for the platform.
> > > > > >
> > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > more.
> > > > >
> > > > > I understand you don't like it and that others don't as well. I wish
> > > > > it had not come to this.
> > > > >
> > > > > However we are only talking about 10 boards, three of which don't even
> > > > > have a devicetree anywhere I can find.
> > > > >
> > > > > I think on balance this is a substantial clean-up. I am happy to add
> > > > > whatever caveats and documentation people want to clarify what is
> > > > > going on here. I'm happy to look at future options where the
> > > > > devicetree is hosted elsewhere, so long as it is trivial to build it
> > > > > within U-Boot for development purposes.
> > > > >
> > > > > I'll also note that the bootstd series shows the devicetree source:
> > > > >
> > > > > Core: 246 devices, 88 uclasses, devicetree: board
> > > > >
> > > > > But for now, I still feel this is the best path forward.
> > > >
> > > > I'm not sure how to proceed here. The reviews are rather strongly
> > > > against the "include a device tree that won't be used". The use case of
> > > > "but for development someone might need to modify the device tree" is
> > > > handled by platforms documenting where / how to get the real one. We
> > > > should even update the Kconfig help to note that if you enable this your
> > > > board docs MUST explain where the device tree can be seen (or have some
> > > > legal reason you think it's OK to not...).
> > >
> > > Right, we can do lots of things as we have discussed. I am very
> > > willing to work on these and make sure it is hard to do the thing. But
> > > this series is long enough already.
> >
> > Yes, I think the rest of us had hoped you would come around to all of
> > our reasoning by this point, is why this is taking so long.
> >
>
> Look, if I thought this was all wrong I would not be doing it. We have
> a range of opinions:
And the rest of us wouldn't keep trying to argue otherwise if we didn't
see problems with it, still.
> - U-Boot should not have its own nodes/properties
The caveat there is that aren't documented upstream bindings. I think
at this point the lack of screaming and otherwise "wait, no no no
don't!" that your current patch has gotten means it's time for a pull
request, and for that to go in, and so this line of argument would be
simply removed.
> - U-Boot should not have DTs in-tree
... for the cases where the DTs are not used at run time, yes.
> - U-Boot should have DTs only when essential
I don't understand this point. Can you please elaborate?
> - U-Boot should have DTs in-tree for all boards
This is the line you're pushing and almost every other reviewer
disagrees with.
> What's the downside here anyway?
- A lack of clarity. We have dts files, you modify those dts files,
they aren't used. What's the point? Oh, you forgot to tweak
something else. Wait, now nothing works. Oh, it's a mismatch between
what this dts was at one point, and what it needs to be now to
actually work.
- We're adding more ongoing sync-up work. While I loudly applaud the
custodians that are keeping their dts files in sync very regularly,
and I sympathize with the custodians that want to do it more, but are
unable to find the time, I do not want to add more of this work. Even
more so when it's unclear who would be doing it. Or what the use is.
There's probably more if I think about it harder, but those are the
first to spring to mind.
> > > It is more than just development. A devicetree is needed for binman to
> > > work, even if it is empty. The documentation idea doesn't really work,
> > > as I think I have proven by the difficulty in getting this series
> > > together. An automated mechanism that runs in CI might be acceptable,
> > > but that is in the future. For now, I believe it just HAS to be
> > > in-tree.
> >
> > I still don't see any reason why we need these incorrect and not
> > functionally used device trees in-tree when a dummy invalid tree is
> > enough to make things link. We're dealing with real "we must have X.bin
> > in the output for things to function" issues on other platforms with
> > binman right now. Using a dummy dts should be fine.
>
> Incorrect in what way?
Well, in the QEMU instance, they're only as correct as the parameters
passed to qemu-system-foo when you did -dumpdtb to start with. Lets
take TPM as that now should show up in the device tree, or not,
depending on if we have the backend side of it? Or all of the examples
of how to arbitrarily configure a system as Heinrich noted.
Or the Pi examples where we need to use the device tree passed to us
because config.txt is the official way to modify things in the device
tree on that platform.
> How do I get a real one for development? How do I turn off OF_BOARD
> and use the in-tree one?
How do you turn off the run-time device tree and instead use the in-tree
one for development, with your series?
> The documentation approach is not good enough.
Why? But maybe I can better explain things in Mark's part of the thread
about power domains and serial on M1..
> > > > And yes, we're "only" talking about 10 platforms, which include things
> > > > like the "everyone" has one Pi family, the extraordinarily flexible (and
> > > > so easy for the reference device tree to be very wrong) QEMU families
> > > > and then platforms that are including a dts in-tree now because they
> > > > were told that was required.
> > >
> > > Actually it is only rpi4 that doesn't have an in-tree DT. There is
> > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot?
> > > The argument is the same.
> >
> > Because we don't need it! It serves no purpose! It exists in Linux
> > as that's the primary device tree source repository. We could _copy_ it
> > in, if it was useful. But then we need to re-sync it every so often,
> > and for less clear reasons than all of the platforms that we need to
> > sync with the kernel for, AND we use the tree.
>
> So some people don't need it and it serves no purpose for them. But
> why do they care? It is not hurting anyone. This is all overblown.
Because it's adding ongoing maintenance work, and reducing clarity of
the codebase, to summarize my concerns above.
> > There's even an argument to be made that it IS in Linux because when you
> > build that dtb, it's what the firmware then ships and uses and provides
> > to everyone at run time, possibly along with whatever other
> > modifications the binary firmware did (see the assorted threads,
> > including one this week about the problems we have because we don't just
> > always use the dtb provided to us at run time).
> >
> > > Most QEMU boards have an in-tree devicetree. It is only ARM (now
> > > copied by RISC-V) which doesn't.
> >
> > Yes, these are more examples of "someone said we need to copy it in, so
> > we copy it in".
>
> No that's not correct. With x86, ppc, integrator, ast2500 and many
> others we *need* the DT and *it is not* created by QEMU.
You're listing both QEMU virtual machines and QEMU-as-hardware-emulators
above, which confuses things. The integrator code runs on real
hardware. Real hardware which does not have the device tree on it. I
assume that QEMU + Linux - U-Boot for integrator requires you to pass
the .dtb in, just like real the real hardware does. That's true of all
of the cases I believe where we use QEMU-as-hardware-emulator because
QEMU is also authentic to the hardware.
> > > > How about adjusting the make logic so that if a tree isn't found, we use
> > > > a dummy minimal valid dts file?
> > >
> > > This is what I have done for the boards where I could not figure out
> > > how to get any sort of DT, yes. But I don't think that should be the
> > > default.
> >
> > The more I think about this, the more I think dummy minimal valid dts
> > should be the fall-back default. This then solves the "I'm a developer,
> > I need to modify the dts files" case because you then just provide the
> > dts instead where it should go, and it's used.
>
> How does it solve it? I don't even know how to get it in many cases.
> If it is a dummy then I cannot actually use it for development, right?
It solves the problem of "we must have this dts file so that the build
will not fail". The next step of "oh, we actually want to use it, and
not the run-time provided dtb" would be the same as whatever you're
doing with this series.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 18:34 ` Tom Rini
@ 2021-12-02 19:12 ` Simon Glass
2021-12-02 22:47 ` Tom Rini
2021-12-02 22:36 ` François Ozog
2021-12-03 1:57 ` Andre Przywara
2 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 19:12 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Tom,
On Thu, 2 Dec 2021 at 11:34, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > > Hi Simon
> > > > > > > >
> > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > > > >
> > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > > >
> > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > > > appended to U-Boot
> > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > > > the ELF file (also used for EFI)
> > > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > > >
> > > > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > > > >
> > > > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > > >
> > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > > >
> > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > > >
> > > > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > > > (and placeholders) to make the build work.
> > > > > > > > >
> > > > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > > > files, some patches in this series can be dropped.
> > > > > > > > >
> > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > > >
> > > > > > > > > [1]
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > Changes in v6:
> > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > - Expand the commit message based on comments
> > > > > > > >
> > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > > not in favor of this new version either.
> > > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > > mainline….
> > > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > > with DTs for the platform.
> > > > > > >
> > > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > > more.
> > > > > >
> > > > > > I understand you don't like it and that others don't as well. I wish
> > > > > > it had not come to this.
> > > > > >
> > > > > > However we are only talking about 10 boards, three of which don't even
> > > > > > have a devicetree anywhere I can find.
> > > > > >
> > > > > > I think on balance this is a substantial clean-up. I am happy to add
> > > > > > whatever caveats and documentation people want to clarify what is
> > > > > > going on here. I'm happy to look at future options where the
> > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it
> > > > > > within U-Boot for development purposes.
> > > > > >
> > > > > > I'll also note that the bootstd series shows the devicetree source:
> > > > > >
> > > > > > Core: 246 devices, 88 uclasses, devicetree: board
> > > > > >
> > > > > > But for now, I still feel this is the best path forward.
> > > > >
> > > > > I'm not sure how to proceed here. The reviews are rather strongly
> > > > > against the "include a device tree that won't be used". The use case of
> > > > > "but for development someone might need to modify the device tree" is
> > > > > handled by platforms documenting where / how to get the real one. We
> > > > > should even update the Kconfig help to note that if you enable this your
> > > > > board docs MUST explain where the device tree can be seen (or have some
> > > > > legal reason you think it's OK to not...).
> > > >
> > > > Right, we can do lots of things as we have discussed. I am very
> > > > willing to work on these and make sure it is hard to do the thing. But
> > > > this series is long enough already.
> > >
> > > Yes, I think the rest of us had hoped you would come around to all of
> > > our reasoning by this point, is why this is taking so long.
> > >
> >
> > Look, if I thought this was all wrong I would not be doing it. We have
> > a range of opinions:
>
> And the rest of us wouldn't keep trying to argue otherwise if we didn't
> see problems with it, still.
I don't claim it is perfect, just that it is better than what we have.
We have lots of ideas on how to improve things, e.g.
- upstreaming the bindings
- having a way to obtain the correct DT through a script
- syncing the DT automatically with an external source
- applying validation to the in-tree DT
- using binman to make it easier to build images
That will take a lot of effort and I don't see anyone else taking it
on. All we have is a lot of people with competing ideas, many
influenced by other projects (TF-A, QEMU, Xen, m1n1, etc.). We could
ask the coreboot people what they think, except that they banned
devicetree years ago. Sometimes I wish...
>
> > - U-Boot should not have its own nodes/properties
>
> The caveat there is that aren't documented upstream bindings. I think
> at this point the lack of screaming and otherwise "wait, no no no
> don't!" that your current patch has gotten means it's time for a pull
> request, and for that to go in, and so this line of argument would be
> simply removed.
That is going to be a long process. I have >100 patches pending and
only so much energy. We need to make incremental progress and we need
a development setup that works for U-Boot developers.
>
> > - U-Boot should not have DTs in-tree
>
> ... for the cases where the DTs are not used at run time, yes.
Except when they are. E.g. for rpi3 I do actually use the in-tree .dtb
for development. I don't what that to be a hassle. U-Boot is a
development project and it needs to be easy.
>
> > - U-Boot should have DTs only when essential
>
> I don't understand this point. Can you please elaborate?
That it should only be in U-Boot if there is no way it can be anywhere else.
>
> > - U-Boot should have DTs in-tree for all boards
>
> This is the line you're pushing and almost every other reviewer
> disagrees with.
Yes.
>
> > What's the downside here anyway?
>
> - A lack of clarity. We have dts files, you modify those dts files,
> they aren't used. What's the point? Oh, you forgot to tweak
> something else. Wait, now nothing works. Oh, it's a mismatch between
> what this dts was at one point, and what it needs to be now to
> actually work.
That's not my experience with this series. It seems to work fine.
Ilias and Heinrich have both pointed to things that 'don't work', but
actually I believe things work just as they do now.
> - We're adding more ongoing sync-up work. While I loudly applaud the
> custodians that are keeping their dts files in sync very regularly,
> and I sympathize with the custodians that want to do it more, but are
> unable to find the time, I do not want to add more of this work. Even
> more so when it's unclear who would be doing it. Or what the use is.
Well we can make this better, but it is a small number of boards. It
is in the noise.
>
> There's probably more if I think about it harder, but those are the
> first to spring to mind.
>
> > > > It is more than just development. A devicetree is needed for binman to
> > > > work, even if it is empty. The documentation idea doesn't really work,
> > > > as I think I have proven by the difficulty in getting this series
> > > > together. An automated mechanism that runs in CI might be acceptable,
> > > > but that is in the future. For now, I believe it just HAS to be
> > > > in-tree.
> > >
> > > I still don't see any reason why we need these incorrect and not
> > > functionally used device trees in-tree when a dummy invalid tree is
> > > enough to make things link. We're dealing with real "we must have X.bin
> > > in the output for things to function" issues on other platforms with
> > > binman right now. Using a dummy dts should be fine.
> >
> > Incorrect in what way?
>
> Well, in the QEMU instance, they're only as correct as the parameters
> passed to qemu-system-foo when you did -dumpdtb to start with. Lets
> take TPM as that now should show up in the device tree, or not,
> depending on if we have the backend side of it? Or all of the examples
> of how to arbitrarily configure a system as Heinrich noted.
>
> Or the Pi examples where we need to use the device tree passed to us
> because config.txt is the official way to modify things in the device
> tree on that platform.
OK, so when you add extra parameters to the ARM and RISC-V QEMU
command line, it doesn't add those extra parameters and those extra
devices are not present.That does not sound surprising to me. It
should be obvious to anyone doing development on these boards.
>
> > How do I get a real one for development? How do I turn off OF_BOARD
> > and use the in-tree one?
>
> How do you turn off the run-time device tree and instead use the in-tree
> one for development, with your series?
Disable OF_BOARD manually. As we discussed, we can put that behind an
EXPERT flag or a build flag, or other things. There is a message
printed when U-Boot starts, too (with a later series).
>
> > The documentation approach is not good enough.
>
> Why? But maybe I can better explain things in Mark's part of the thread
> about power domains and serial on M1..
Because I can't find the DT and it takes manual effort to locate it
and set it up for development. It is just too hard.
>
> > > > > And yes, we're "only" talking about 10 platforms, which include things
> > > > > like the "everyone" has one Pi family, the extraordinarily flexible (and
> > > > > so easy for the reference device tree to be very wrong) QEMU families
> > > > > and then platforms that are including a dts in-tree now because they
> > > > > were told that was required.
> > > >
> > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is
> > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot?
> > > > The argument is the same.
> > >
> > > Because we don't need it! It serves no purpose! It exists in Linux
> > > as that's the primary device tree source repository. We could _copy_ it
> > > in, if it was useful. But then we need to re-sync it every so often,
> > > and for less clear reasons than all of the platforms that we need to
> > > sync with the kernel for, AND we use the tree.
> >
> > So some people don't need it and it serves no purpose for them. But
> > why do they care? It is not hurting anyone. This is all overblown.
>
> Because it's adding ongoing maintenance work, and reducing clarity of
> the codebase, to summarize my concerns above.
Yes, but can we just accept that as a cost? We have plans and ideas to
reduce it over time, right?
>
> > > There's even an argument to be made that it IS in Linux because when you
> > > build that dtb, it's what the firmware then ships and uses and provides
> > > to everyone at run time, possibly along with whatever other
> > > modifications the binary firmware did (see the assorted threads,
> > > including one this week about the problems we have because we don't just
> > > always use the dtb provided to us at run time).
> > >
> > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now
> > > > copied by RISC-V) which doesn't.
> > >
> > > Yes, these are more examples of "someone said we need to copy it in, so
> > > we copy it in".
> >
> > No that's not correct. With x86, ppc, integrator, ast2500 and many
> > others we *need* the DT and *it is not* created by QEMU.
>
> You're listing both QEMU virtual machines and QEMU-as-hardware-emulators
> above, which confuses things. The integrator code runs on real
> hardware. Real hardware which does not have the device tree on it. I
> assume that QEMU + Linux - U-Boot for integrator requires you to pass
> the .dtb in, just like real the real hardware does. That's true of all
> of the cases I believe where we use QEMU-as-hardware-emulator because
> QEMU is also authentic to the hardware.
Yes, I get it. But the common case just works and I want to use binman
images in CI as well as development with these things, without hacking
QEMU itself. It is just not sensible to have to upgrade QEMU just to
get an updated DT for trying something out.
>
> > > > > How about adjusting the make logic so that if a tree isn't found, we use
> > > > > a dummy minimal valid dts file?
> > > >
> > > > This is what I have done for the boards where I could not figure out
> > > > how to get any sort of DT, yes. But I don't think that should be the
> > > > default.
> > >
> > > The more I think about this, the more I think dummy minimal valid dts
> > > should be the fall-back default. This then solves the "I'm a developer,
> > > I need to modify the dts files" case because you then just provide the
> > > dts instead where it should go, and it's used.
> >
> > How does it solve it? I don't even know how to get it in many cases.
> > If it is a dummy then I cannot actually use it for development, right?
>
> It solves the problem of "we must have this dts file so that the build
> will not fail". The next step of "oh, we actually want to use it, and
> not the run-time provided dtb" would be the same as whatever you're
> doing with this series.
Not in my experience. For example, with QEMU I was able to use an
in-tree .dts for the bootstd stuff without any issues. This series
also explains how to discover the DT, at least for the two QEMU boards
that need it.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 19:12 ` Simon Glass
@ 2021-12-02 22:47 ` Tom Rini
2021-12-02 23:46 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-02 22:47 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 22329 bytes --]
On Thu, Dec 02, 2021 at 12:12:16PM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 2 Dec 2021 at 11:34, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > > > Hi Simon
> > > > > > > > >
> > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > > > > >
> > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > > > >
> > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > > > > appended to U-Boot
> > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > > > > the ELF file (also used for EFI)
> > > > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > > > >
> > > > > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > > > > >
> > > > > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > > > >
> > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > > > >
> > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > > > >
> > > > > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > > > > (and placeholders) to make the build work.
> > > > > > > > > >
> > > > > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > > > > files, some patches in this series can be dropped.
> > > > > > > > > >
> > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > > > >
> > > > > > > > > > [1]
> > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > >
> > > > > > > > > > Changes in v6:
> > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > >
> > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > > > not in favor of this new version either.
> > > > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > > > mainline….
> > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > > > with DTs for the platform.
> > > > > > > >
> > > > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > > > more.
> > > > > > >
> > > > > > > I understand you don't like it and that others don't as well. I wish
> > > > > > > it had not come to this.
> > > > > > >
> > > > > > > However we are only talking about 10 boards, three of which don't even
> > > > > > > have a devicetree anywhere I can find.
> > > > > > >
> > > > > > > I think on balance this is a substantial clean-up. I am happy to add
> > > > > > > whatever caveats and documentation people want to clarify what is
> > > > > > > going on here. I'm happy to look at future options where the
> > > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it
> > > > > > > within U-Boot for development purposes.
> > > > > > >
> > > > > > > I'll also note that the bootstd series shows the devicetree source:
> > > > > > >
> > > > > > > Core: 246 devices, 88 uclasses, devicetree: board
> > > > > > >
> > > > > > > But for now, I still feel this is the best path forward.
> > > > > >
> > > > > > I'm not sure how to proceed here. The reviews are rather strongly
> > > > > > against the "include a device tree that won't be used". The use case of
> > > > > > "but for development someone might need to modify the device tree" is
> > > > > > handled by platforms documenting where / how to get the real one. We
> > > > > > should even update the Kconfig help to note that if you enable this your
> > > > > > board docs MUST explain where the device tree can be seen (or have some
> > > > > > legal reason you think it's OK to not...).
> > > > >
> > > > > Right, we can do lots of things as we have discussed. I am very
> > > > > willing to work on these and make sure it is hard to do the thing. But
> > > > > this series is long enough already.
> > > >
> > > > Yes, I think the rest of us had hoped you would come around to all of
> > > > our reasoning by this point, is why this is taking so long.
> > > >
> > >
> > > Look, if I thought this was all wrong I would not be doing it. We have
> > > a range of opinions:
> >
> > And the rest of us wouldn't keep trying to argue otherwise if we didn't
> > see problems with it, still.
>
> I don't claim it is perfect, just that it is better than what we have.
> We have lots of ideas on how to improve things, e.g.
>
> - upstreaming the bindings
> - having a way to obtain the correct DT through a script
> - syncing the DT automatically with an external source
> - applying validation to the in-tree DT
> - using binman to make it easier to build images
>
> That will take a lot of effort and I don't see anyone else taking it
> on. All we have is a lot of people with competing ideas, many
> influenced by other projects (TF-A, QEMU, Xen, m1n1, etc.). We could
> ask the coreboot people what they think, except that they banned
> devicetree years ago. Sometimes I wish...
Maybe part of the problem here is disagreement on the problems with what
we have. The problems I see are:
- We have some dts files out of sync with upstream, but this ISN'T a
problem for them as the dtb in U-Boot never leaves the U-Boot world.
It could, but it doesn't, so no one notices, and no one works to
update it. This is typically 32bit ARM.
- We have some dts files out of sync with upstream, AND this IS a
problem for them as the dtb can be passed along to the OS, typically
via bootefi and so 64bit ARM platforms.
- We have a number of u-boot prefixed properties and they need to be
both upstreamed and perhaps re-evaluated because it's sometimes very
much not clear when / why people need them, as can be seen by some of
the copy/paste that's in the -u-boot.dtsi files now, including the
typod ones we talked about on IRC.
- We're very very inconsistent with the case of "a valid device tree for
the OS and/or us exists in memory".
It's this last case that's causing all of the headaches in this series
because on the one hand, there's only a few platforms here, today. On
the other hand, there's a very very strong push for 64bit ARM platforms
to all join in this group because given the nature of the architecture,
some other firmware runs before us and in theory could / should be
responsible.
> > > - U-Boot should not have its own nodes/properties
> >
> > The caveat there is that aren't documented upstream bindings. I think
> > at this point the lack of screaming and otherwise "wait, no no no
> > don't!" that your current patch has gotten means it's time for a pull
> > request, and for that to go in, and so this line of argument would be
> > simply removed.
>
> That is going to be a long process. I have >100 patches pending and
> only so much energy. We need to make incremental progress and we need
> a development setup that works for U-Boot developers.
Right, it will take a bit of time. But it's also the case that you're
the person that most deeply understands a good number of them.
> > > - U-Boot should not have DTs in-tree
> >
> > ... for the cases where the DTs are not used at run time, yes.
>
> Except when they are. E.g. for rpi3 I do actually use the in-tree .dtb
> for development. I don't what that to be a hassle. U-Boot is a
> development project and it needs to be easy.
But it's also a user platform. And it's causing us problems. This is
the thread I was referring to earlier:
https://lore.kernel.org/u-boot/20211125194223.1094066-1-sjoerd@collabora.com/
and it's not the first, or possibly even only outstanding problem right
now.
I very much get that part of the overall device tree development cycle
is painful. One thought I had today was that one issue here is that you
see a problem of "I have 10 boards and each board wants me to supply an
updated device tree in its own way, let me unify that". Others of us
(at least myself) see a problem of "10 vendors have officially declared
you update the device tree for their platform like $this, which is
unfortunate but pretty well set in stone, with things well outside our
control depending on this".
So, to me, the root cause problem with Pi support is that we have rpi_4
and rpi_3 and so forth defconfigs when they should all be supported via
rpi_arm64 which uses the device tree passed from the firmware blob and
ready for Linux to consume. And if you need to modify the dtb, you do
it the supported way via config.txt. Which means that yes, we're back
at my point about 10 vendors and so 10 ways to do the same concept.
Which is a huge sink when you're working with 10 different platforms.
> > > - U-Boot should have DTs only when essential
> >
> > I don't understand this point. Can you please elaborate?
>
> That it should only be in U-Boot if there is no way it can be anywhere else.
Because of say u-boot,dm-pre-reloc properties, or do you mean the whole
device tree itself?
> > > - U-Boot should have DTs in-tree for all boards
> >
> > This is the line you're pushing and almost every other reviewer
> > disagrees with.
>
> Yes.
>
> >
> > > What's the downside here anyway?
> >
> > - A lack of clarity. We have dts files, you modify those dts files,
> > they aren't used. What's the point? Oh, you forgot to tweak
> > something else. Wait, now nothing works. Oh, it's a mismatch between
> > what this dts was at one point, and what it needs to be now to
> > actually work.
>
> That's not my experience with this series. It seems to work fine.
> Ilias and Heinrich have both pointed to things that 'don't work', but
> actually I believe things work just as they do now.
I'm talking about for average developers. I just answered a question on
StackOverflow earlier this week about what all the device trees that are
everywhere are even used for, and what needs to be modified to have a
change actually show up. The DTS situation in general has a very steep
learning curve and this will make things harder I believe.
> > - We're adding more ongoing sync-up work. While I loudly applaud the
> > custodians that are keeping their dts files in sync very regularly,
> > and I sympathize with the custodians that want to do it more, but are
> > unable to find the time, I do not want to add more of this work. Even
> > more so when it's unclear who would be doing it. Or what the use is.
>
> Well we can make this better, but it is a small number of boards. It
> is in the noise.
I'm basing my concern here on the number of SoCs that regularly resync
vs the ones that do not.
> > There's probably more if I think about it harder, but those are the
> > first to spring to mind.
> >
> > > > > It is more than just development. A devicetree is needed for binman to
> > > > > work, even if it is empty. The documentation idea doesn't really work,
> > > > > as I think I have proven by the difficulty in getting this series
> > > > > together. An automated mechanism that runs in CI might be acceptable,
> > > > > but that is in the future. For now, I believe it just HAS to be
> > > > > in-tree.
> > > >
> > > > I still don't see any reason why we need these incorrect and not
> > > > functionally used device trees in-tree when a dummy invalid tree is
> > > > enough to make things link. We're dealing with real "we must have X.bin
> > > > in the output for things to function" issues on other platforms with
> > > > binman right now. Using a dummy dts should be fine.
> > >
> > > Incorrect in what way?
> >
> > Well, in the QEMU instance, they're only as correct as the parameters
> > passed to qemu-system-foo when you did -dumpdtb to start with. Lets
> > take TPM as that now should show up in the device tree, or not,
> > depending on if we have the backend side of it? Or all of the examples
> > of how to arbitrarily configure a system as Heinrich noted.
> >
> > Or the Pi examples where we need to use the device tree passed to us
> > because config.txt is the official way to modify things in the device
> > tree on that platform.
>
> OK, so when you add extra parameters to the ARM and RISC-V QEMU
> command line, it doesn't add those extra parameters and those extra
> devices are not present.That does not sound surprising to me. It
> should be obvious to anyone doing development on these boards.
Why is it going to be obvious that we're ignoring the supplied device
tree? Why is it expected that U-Boot works like this, when nothing else
does?
> > > How do I get a real one for development? How do I turn off OF_BOARD
> > > and use the in-tree one?
> >
> > How do you turn off the run-time device tree and instead use the in-tree
> > one for development, with your series?
>
> Disable OF_BOARD manually. As we discussed, we can put that behind an
> EXPERT flag or a build flag, or other things. There is a message
> printed when U-Boot starts, too (with a later series).
OK, so what I'm saying is that for rpi_arm64, qemu_arm*, etc, etc, the
default builds that dummy empty device tree, and when you want to do
your developer use case you disable OF_BOARD and set it to point at what
you want.
> > > The documentation approach is not good enough.
> >
> > Why? But maybe I can better explain things in Mark's part of the thread
> > about power domains and serial on M1..
>
> Because I can't find the DT and it takes manual effort to locate it
> and set it up for development. It is just too hard.
You're optimizing things for the "I'm developing on 10 arbitrary
different SoCs" which isn't the common use case. Mark for example
doesn't have a problem figuring out where the M1 dts files live, no one
working on Pi has problems finding the Pi dts files, the Xen folks know
what's up in their case, and so on. Yes, the developing broadly use
case is hard and needs better documentation so that it's not too hard to
come up to speed on a new platform. That's true for everyone.
> > > > > > And yes, we're "only" talking about 10 platforms, which include things
> > > > > > like the "everyone" has one Pi family, the extraordinarily flexible (and
> > > > > > so easy for the reference device tree to be very wrong) QEMU families
> > > > > > and then platforms that are including a dts in-tree now because they
> > > > > > were told that was required.
> > > > >
> > > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is
> > > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot?
> > > > > The argument is the same.
> > > >
> > > > Because we don't need it! It serves no purpose! It exists in Linux
> > > > as that's the primary device tree source repository. We could _copy_ it
> > > > in, if it was useful. But then we need to re-sync it every so often,
> > > > and for less clear reasons than all of the platforms that we need to
> > > > sync with the kernel for, AND we use the tree.
> > >
> > > So some people don't need it and it serves no purpose for them. But
> > > why do they care? It is not hurting anyone. This is all overblown.
> >
> > Because it's adding ongoing maintenance work, and reducing clarity of
> > the codebase, to summarize my concerns above.
>
> Yes, but can we just accept that as a cost? We have plans and ideas to
> reduce it over time, right?
In that there's lessons to learn from other projects about source layout
so it's easier to re-sync files, sure, there's ideas. But it also
continues to just ignore / set aside the problem of how frequently how
much of device trees change. It's getting better over time and
validation being non-optional in Linux moving forward will really help.
But it's still work, and still makes things unclear where / why we're
doing what we would be doing. If we're given a perfectly functional and
correct device tree in memory for a Pi for example, why do we not use
it by default and instead pick one that was built in to U-Boot and
misses the changes the user may have made on purpose. That is part of
clarity as well.
> > > > There's even an argument to be made that it IS in Linux because when you
> > > > build that dtb, it's what the firmware then ships and uses and provides
> > > > to everyone at run time, possibly along with whatever other
> > > > modifications the binary firmware did (see the assorted threads,
> > > > including one this week about the problems we have because we don't just
> > > > always use the dtb provided to us at run time).
> > > >
> > > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now
> > > > > copied by RISC-V) which doesn't.
> > > >
> > > > Yes, these are more examples of "someone said we need to copy it in, so
> > > > we copy it in".
> > >
> > > No that's not correct. With x86, ppc, integrator, ast2500 and many
> > > others we *need* the DT and *it is not* created by QEMU.
> >
> > You're listing both QEMU virtual machines and QEMU-as-hardware-emulators
> > above, which confuses things. The integrator code runs on real
> > hardware. Real hardware which does not have the device tree on it. I
> > assume that QEMU + Linux - U-Boot for integrator requires you to pass
> > the .dtb in, just like real the real hardware does. That's true of all
> > of the cases I believe where we use QEMU-as-hardware-emulator because
> > QEMU is also authentic to the hardware.
>
> Yes, I get it. But the common case just works and I want to use binman
> images in CI as well as development with these things, without hacking
> QEMU itself. It is just not sensible to have to upgrade QEMU just to
> get an updated DT for trying something out.
I don't follow you. There's nothing special about the integrator build
in CI, which is the whole point.
And then I keep saying that if you're modifying the dtb from QEMU, and
it's not just a proof of concept or something being developed and
upstreamed, something is wrong with our flow. We have something
backwards and need to evaluate it.
> > > > > > How about adjusting the make logic so that if a tree isn't found, we use
> > > > > > a dummy minimal valid dts file?
> > > > >
> > > > > This is what I have done for the boards where I could not figure out
> > > > > how to get any sort of DT, yes. But I don't think that should be the
> > > > > default.
> > > >
> > > > The more I think about this, the more I think dummy minimal valid dts
> > > > should be the fall-back default. This then solves the "I'm a developer,
> > > > I need to modify the dts files" case because you then just provide the
> > > > dts instead where it should go, and it's used.
> > >
> > > How does it solve it? I don't even know how to get it in many cases.
> > > If it is a dummy then I cannot actually use it for development, right?
> >
> > It solves the problem of "we must have this dts file so that the build
> > will not fail". The next step of "oh, we actually want to use it, and
> > not the run-time provided dtb" would be the same as whatever you're
> > doing with this series.
>
> Not in my experience. For example, with QEMU I was able to use an
> in-tree .dts for the bootstd stuff without any issues. This series
> also explains how to discover the DT, at least for the two QEMU boards
> that need it.
Then something is backwards still. You should be able to flip the
CONFIG switch to have the arbitrary dtb you want used, but the default
should be the provided device tree.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 22:47 ` Tom Rini
@ 2021-12-02 23:46 ` Simon Glass
0 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 23:46 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Tom,
On Thu, 2 Dec 2021 at 15:47, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 02, 2021 at 12:12:16PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 2 Dec 2021 at 11:34, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > > > > Hi Simon
> > > > > > > > > >
> > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > > > > > >
> > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > > > > >
> > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > > > > > appended to U-Boot
> > > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > > > > > the ELF file (also used for EFI)
> > > > > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > > > > >
> > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > > > > > >
> > > > > > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > > > > >
> > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > > > > >
> > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > > > > >
> > > > > > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > > > > > (and placeholders) to make the build work.
> > > > > > > > > > >
> > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > > > > > files, some patches in this series can be dropped.
> > > > > > > > > > >
> > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > > > > >
> > > > > > > > > > > [1]
> > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > > >
> > > > > > > > > > > Changes in v6:
> > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > >
> > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > > > > not in favor of this new version either.
> > > > > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > > > > mainline….
> > > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > > > > with DTs for the platform.
> > > > > > > > >
> > > > > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > > > > more.
> > > > > > > >
> > > > > > > > I understand you don't like it and that others don't as well. I wish
> > > > > > > > it had not come to this.
> > > > > > > >
> > > > > > > > However we are only talking about 10 boards, three of which don't even
> > > > > > > > have a devicetree anywhere I can find.
> > > > > > > >
> > > > > > > > I think on balance this is a substantial clean-up. I am happy to add
> > > > > > > > whatever caveats and documentation people want to clarify what is
> > > > > > > > going on here. I'm happy to look at future options where the
> > > > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it
> > > > > > > > within U-Boot for development purposes.
> > > > > > > >
> > > > > > > > I'll also note that the bootstd series shows the devicetree source:
> > > > > > > >
> > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board
> > > > > > > >
> > > > > > > > But for now, I still feel this is the best path forward.
> > > > > > >
> > > > > > > I'm not sure how to proceed here. The reviews are rather strongly
> > > > > > > against the "include a device tree that won't be used". The use case of
> > > > > > > "but for development someone might need to modify the device tree" is
> > > > > > > handled by platforms documenting where / how to get the real one. We
> > > > > > > should even update the Kconfig help to note that if you enable this your
> > > > > > > board docs MUST explain where the device tree can be seen (or have some
> > > > > > > legal reason you think it's OK to not...).
> > > > > >
> > > > > > Right, we can do lots of things as we have discussed. I am very
> > > > > > willing to work on these and make sure it is hard to do the thing. But
> > > > > > this series is long enough already.
> > > > >
> > > > > Yes, I think the rest of us had hoped you would come around to all of
> > > > > our reasoning by this point, is why this is taking so long.
> > > > >
> > > >
> > > > Look, if I thought this was all wrong I would not be doing it. We have
> > > > a range of opinions:
> > >
> > > And the rest of us wouldn't keep trying to argue otherwise if we didn't
> > > see problems with it, still.
> >
> > I don't claim it is perfect, just that it is better than what we have.
> > We have lots of ideas on how to improve things, e.g.
> >
> > - upstreaming the bindings
> > - having a way to obtain the correct DT through a script
> > - syncing the DT automatically with an external source
> > - applying validation to the in-tree DT
> > - using binman to make it easier to build images
> >
> > That will take a lot of effort and I don't see anyone else taking it
> > on. All we have is a lot of people with competing ideas, many
> > influenced by other projects (TF-A, QEMU, Xen, m1n1, etc.). We could
> > ask the coreboot people what they think, except that they banned
> > devicetree years ago. Sometimes I wish...
>
> Maybe part of the problem here is disagreement on the problems with what
> we have. The problems I see are:
> - We have some dts files out of sync with upstream, but this ISN'T a
> problem for them as the dtb in U-Boot never leaves the U-Boot world.
> It could, but it doesn't, so no one notices, and no one works to
> update it. This is typically 32bit ARM.
> - We have some dts files out of sync with upstream, AND this IS a
> problem for them as the dtb can be passed along to the OS, typically
> via bootefi and so 64bit ARM platforms.
> - We have a number of u-boot prefixed properties and they need to be
> both upstreamed and perhaps re-evaluated because it's sometimes very
> much not clear when / why people need them, as can be seen by some of
> the copy/paste that's in the -u-boot.dtsi files now, including the
> typod ones we talked about on IRC.
> - We're very very inconsistent with the case of "a valid device tree for
> the OS and/or us exists in memory".
>
> It's this last case that's causing all of the headaches in this series
> because on the one hand, there's only a few platforms here, today. On
> the other hand, there's a very very strong push for 64bit ARM platforms
> to all join in this group because given the nature of the architecture,
> some other firmware runs before us and in theory could / should be
> responsible.
I don't think it will matter much, though, in the end. If what you say
comes to pass then we will have a consistent DT everywhere and it
won't matter where it comes from.
After all, in the end we need to produce a single firmware image. If
binman is used for that, the DT will be placed there.
For development, we may have a situation where all the other bits are
blobs and just U-Boot is being iterated, to get the higher-level
features working properly. We need a way to update the DT easily, e.g.
just building it with U-Boot. That is something I do a *lot* and that
is what I'm not giving up. Not until it is clearer how things are
going to land over the next few years.
>
> > > > - U-Boot should not have its own nodes/properties
> > >
> > > The caveat there is that aren't documented upstream bindings. I think
> > > at this point the lack of screaming and otherwise "wait, no no no
> > > don't!" that your current patch has gotten means it's time for a pull
> > > request, and for that to go in, and so this line of argument would be
> > > simply removed.
> >
> > That is going to be a long process. I have >100 patches pending and
> > only so much energy. We need to make incremental progress and we need
> > a development setup that works for U-Boot developers.
>
> Right, it will take a bit of time. But it's also the case that you're
> the person that most deeply understands a good number of them.
>
> > > > - U-Boot should not have DTs in-tree
> > >
> > > ... for the cases where the DTs are not used at run time, yes.
> >
> > Except when they are. E.g. for rpi3 I do actually use the in-tree .dtb
> > for development. I don't what that to be a hassle. U-Boot is a
> > development project and it needs to be easy.
>
> But it's also a user platform. And it's causing us problems. This is
> the thread I was referring to earlier:
> https://lore.kernel.org/u-boot/20211125194223.1094066-1-sjoerd@collabora.com/
> and it's not the first, or possibly even only outstanding problem right
> now.
That is dealing with fixing up a loaded DT, as I understand it. We
have that problem anyway when we use a loaded DT to pass to Linux. If
so, it isn't really related to what we are talking about here.
>
> I very much get that part of the overall device tree development cycle
> is painful. One thought I had today was that one issue here is that you
> see a problem of "I have 10 boards and each board wants me to supply an
> updated device tree in its own way, let me unify that". Others of us
> (at least myself) see a problem of "10 vendors have officially declared
> you update the device tree for their platform like $this, which is
> unfortunate but pretty well set in stone, with things well outside our
> control depending on this".
>
> So, to me, the root cause problem with Pi support is that we have rpi_4
> and rpi_3 and so forth defconfigs when they should all be supported via
> rpi_arm64 which uses the device tree passed from the firmware blob and
> ready for Linux to consume. And if you need to modify the dtb, you do
> it the supported way via config.txt. Which means that yes, we're back
> at my point about 10 vendors and so 10 ways to do the same concept.
> Which is a huge sink when you're working with 10 different platforms.
OK.
>
> > > > - U-Boot should have DTs only when essential
> > >
> > > I don't understand this point. Can you please elaborate?
> >
> > That it should only be in U-Boot if there is no way it can be anywhere else.
>
> Because of say u-boot,dm-pre-reloc properties, or do you mean the whole
> device tree itself?
No I mean this is a position people are taking. I think it
destructive. U-Boot should be able to have the DT, just like any other
project. They should all be identical (one day), but there is no
reason to strip things out of U-Boot just because some other random
project decides it wants to pass one along at runtime.
>
> > > > - U-Boot should have DTs in-tree for all boards
> > >
> > > This is the line you're pushing and almost every other reviewer
> > > disagrees with.
> >
> > Yes.
> >
> > >
> > > > What's the downside here anyway?
> > >
> > > - A lack of clarity. We have dts files, you modify those dts files,
> > > they aren't used. What's the point? Oh, you forgot to tweak
> > > something else. Wait, now nothing works. Oh, it's a mismatch between
> > > what this dts was at one point, and what it needs to be now to
> > > actually work.
> >
> > That's not my experience with this series. It seems to work fine.
> > Ilias and Heinrich have both pointed to things that 'don't work', but
> > actually I believe things work just as they do now.
>
> I'm talking about for average developers. I just answered a question on
> StackOverflow earlier this week about what all the device trees that are
> everywhere are even used for, and what needs to be modified to have a
> change actually show up. The DTS situation in general has a very steep
> learning curve and this will make things harder I believe.
OK so I have added:
- a way to detect where the DT comes from
- showing that on the console
- OF_BOARD Is still the default for boards that use it
I have offered later:
- EXPERT mode to override turning OF_BOARD for boards where it should be enabled
- build-time warnings
- a build-time environment var/flag to enable this
What more do you want? :-) Honestly, let's just go with it.
>
> > > - We're adding more ongoing sync-up work. While I loudly applaud the
> > > custodians that are keeping their dts files in sync very regularly,
> > > and I sympathize with the custodians that want to do it more, but are
> > > unable to find the time, I do not want to add more of this work. Even
> > > more so when it's unclear who would be doing it. Or what the use is.
> >
> > Well we can make this better, but it is a small number of boards. It
> > is in the noise.
>
> I'm basing my concern here on the number of SoCs that regularly resync
> vs the ones that do not.
This is not going to be solved this week or next. But we have a plan
to resolve it and the current state actually makes all this harder.
>
> > > There's probably more if I think about it harder, but those are the
> > > first to spring to mind.
> > >
> > > > > > It is more than just development. A devicetree is needed for binman to
> > > > > > work, even if it is empty. The documentation idea doesn't really work,
> > > > > > as I think I have proven by the difficulty in getting this series
> > > > > > together. An automated mechanism that runs in CI might be acceptable,
> > > > > > but that is in the future. For now, I believe it just HAS to be
> > > > > > in-tree.
> > > > >
> > > > > I still don't see any reason why we need these incorrect and not
> > > > > functionally used device trees in-tree when a dummy invalid tree is
> > > > > enough to make things link. We're dealing with real "we must have X.bin
> > > > > in the output for things to function" issues on other platforms with
> > > > > binman right now. Using a dummy dts should be fine.
> > > >
> > > > Incorrect in what way?
> > >
> > > Well, in the QEMU instance, they're only as correct as the parameters
> > > passed to qemu-system-foo when you did -dumpdtb to start with. Lets
> > > take TPM as that now should show up in the device tree, or not,
> > > depending on if we have the backend side of it? Or all of the examples
> > > of how to arbitrarily configure a system as Heinrich noted.
> > >
> > > Or the Pi examples where we need to use the device tree passed to us
> > > because config.txt is the official way to modify things in the device
> > > tree on that platform.
> >
> > OK, so when you add extra parameters to the ARM and RISC-V QEMU
> > command line, it doesn't add those extra parameters and those extra
> > devices are not present.That does not sound surprising to me. It
> > should be obvious to anyone doing development on these boards.
>
> Why is it going to be obvious that we're ignoring the supplied device
> tree? Why is it expected that U-Boot works like this, when nothing else
> does?
Because U-Boot will print that out on boot:
U-Boot 2021.10-00190 (Oct 30 2021 - 09:01:29 -0600)
DRAM: 128 MiB
> Core: 42 devices, 11 uclasses, devicetree: board [or passage, or separate]
Flash: 64 MiB
https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-23-sjg@chromium.org/
>
> > > > How do I get a real one for development? How do I turn off OF_BOARD
> > > > and use the in-tree one?
> > >
> > > How do you turn off the run-time device tree and instead use the in-tree
> > > one for development, with your series?
> >
> > Disable OF_BOARD manually. As we discussed, we can put that behind an
> > EXPERT flag or a build flag, or other things. There is a message
> > printed when U-Boot starts, too (with a later series).
>
> OK, so what I'm saying is that for rpi_arm64, qemu_arm*, etc, etc, the
> default builds that dummy empty device tree, and when you want to do
> your developer use case you disable OF_BOARD and set it to point at what
> you want.
Where does that 'what you want' come from?
>
> > > > The documentation approach is not good enough.
> > >
> > > Why? But maybe I can better explain things in Mark's part of the thread
> > > about power domains and serial on M1..
> >
> > Because I can't find the DT and it takes manual effort to locate it
> > and set it up for development. It is just too hard.
>
> You're optimizing things for the "I'm developing on 10 arbitrary
> different SoCs" which isn't the common use case. Mark for example
> doesn't have a problem figuring out where the M1 dts files live, no one
> working on Pi has problems finding the Pi dts files, the Xen folks know
> what's up in their case, and so on. Yes, the developing broadly use
> case is hard and needs better documentation so that it's not too hard to
> come up to speed on a new platform. That's true for everyone.
It's not remotely feasible for me, at least. I'm pleased that it works
for you, but a bit surprised.
I don't want to give up the easy building that we have now, until we
have something just as easy in place.
>
> > > > > > > And yes, we're "only" talking about 10 platforms, which include things
> > > > > > > like the "everyone" has one Pi family, the extraordinarily flexible (and
> > > > > > > so easy for the reference device tree to be very wrong) QEMU families
> > > > > > > and then platforms that are including a dts in-tree now because they
> > > > > > > were told that was required.
> > > > > >
> > > > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is
> > > > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot?
> > > > > > The argument is the same.
> > > > >
> > > > > Because we don't need it! It serves no purpose! It exists in Linux
> > > > > as that's the primary device tree source repository. We could _copy_ it
> > > > > in, if it was useful. But then we need to re-sync it every so often,
> > > > > and for less clear reasons than all of the platforms that we need to
> > > > > sync with the kernel for, AND we use the tree.
> > > >
> > > > So some people don't need it and it serves no purpose for them. But
> > > > why do they care? It is not hurting anyone. This is all overblown.
> > >
> > > Because it's adding ongoing maintenance work, and reducing clarity of
> > > the codebase, to summarize my concerns above.
> >
> > Yes, but can we just accept that as a cost? We have plans and ideas to
> > reduce it over time, right?
>
> In that there's lessons to learn from other projects about source layout
> so it's easier to re-sync files, sure, there's ideas. But it also
> continues to just ignore / set aside the problem of how frequently how
> much of device trees change. It's getting better over time and
> validation being non-optional in Linux moving forward will really help.
> But it's still work, and still makes things unclear where / why we're
> doing what we would be doing. If we're given a perfectly functional and
> correct device tree in memory for a Pi for example, why do we not use
> it by default and instead pick one that was built in to U-Boot and
> misses the changes the user may have made on purpose. That is part of
> clarity as well.
But I'm not saying we should not use it by default. This is what I
find so confusing, that people are imputing some strange change here.
I just want to be able to (as a dev) use the in-tree DT, if I want to,
if I know what I am doing.
When we have a better system for getting the DT for development
purposes, let's use it. But we don't.
Again, this series changes *nothing* about how rpi works by default.
>
> > > > > There's even an argument to be made that it IS in Linux because when you
> > > > > build that dtb, it's what the firmware then ships and uses and provides
> > > > > to everyone at run time, possibly along with whatever other
> > > > > modifications the binary firmware did (see the assorted threads,
> > > > > including one this week about the problems we have because we don't just
> > > > > always use the dtb provided to us at run time).
> > > > >
> > > > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now
> > > > > > copied by RISC-V) which doesn't.
> > > > >
> > > > > Yes, these are more examples of "someone said we need to copy it in, so
> > > > > we copy it in".
> > > >
> > > > No that's not correct. With x86, ppc, integrator, ast2500 and many
> > > > others we *need* the DT and *it is not* created by QEMU.
> > >
> > > You're listing both QEMU virtual machines and QEMU-as-hardware-emulators
> > > above, which confuses things. The integrator code runs on real
> > > hardware. Real hardware which does not have the device tree on it. I
> > > assume that QEMU + Linux - U-Boot for integrator requires you to pass
> > > the .dtb in, just like real the real hardware does. That's true of all
> > > of the cases I believe where we use QEMU-as-hardware-emulator because
> > > QEMU is also authentic to the hardware.
> >
> > Yes, I get it. But the common case just works and I want to use binman
> > images in CI as well as development with these things, without hacking
> > QEMU itself. It is just not sensible to have to upgrade QEMU just to
> > get an updated DT for trying something out.
>
> I don't follow you. There's nothing special about the integrator build
> in CI, which is the whole point.
>
> And then I keep saying that if you're modifying the dtb from QEMU, and
> it's not just a proof of concept or something being developed and
> upstreamed, something is wrong with our flow. We have something
> backwards and need to evaluate it.
Why? There are going to be dozens of different pre-boot loaders,
right? Everyone loves writing a new pre-boot loader. How else are you
going to deal with whatever weird way each one of them produces a DT
so you can modify it for development purposes.
Do you want to have to rebuild that pre-boot loader from source every
time you want to make a change?
Inserting it with U-Boot is the only sane way to develop U-Boot. Mark
has found that. I know it for a fact.
So we have to make it *impossible* to insert a DT that U-Boot actually
uses. Why?
>
> > > > > > > How about adjusting the make logic so that if a tree isn't found, we use
> > > > > > > a dummy minimal valid dts file?
> > > > > >
> > > > > > This is what I have done for the boards where I could not figure out
> > > > > > how to get any sort of DT, yes. But I don't think that should be the
> > > > > > default.
> > > > >
> > > > > The more I think about this, the more I think dummy minimal valid dts
> > > > > should be the fall-back default. This then solves the "I'm a developer,
> > > > > I need to modify the dts files" case because you then just provide the
> > > > > dts instead where it should go, and it's used.
> > > >
> > > > How does it solve it? I don't even know how to get it in many cases.
> > > > If it is a dummy then I cannot actually use it for development, right?
> > >
> > > It solves the problem of "we must have this dts file so that the build
> > > will not fail". The next step of "oh, we actually want to use it, and
> > > not the run-time provided dtb" would be the same as whatever you're
> > > doing with this series.
> >
> > Not in my experience. For example, with QEMU I was able to use an
> > in-tree .dts for the bootstd stuff without any issues. This series
> > also explains how to discover the DT, at least for the two QEMU boards
> > that need it.
>
> Then something is backwards still. You should be able to flip the
> CONFIG switch to have the arbitrary dtb you want used, but the default
> should be the provided device tree.
Yes, agreed. Have I not been saying that from the start? What are we
still discussing?
I cannot reconcile that statement with what you have said above. Email
is such a nightmare.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 18:34 ` Tom Rini
2021-12-02 19:12 ` Simon Glass
@ 2021-12-02 22:36 ` François Ozog
2021-12-02 22:52 ` Tom Rini
2021-12-03 1:57 ` Andre Przywara
2 siblings, 1 reply; 136+ messages in thread
From: François Ozog @ 2021-12-02 22:36 UTC (permalink / raw)
To: Tom Rini
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Simon Glass, Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Simon,Tom
Le jeu. 2 déc. 2021 à 19:34, Tom Rini <trini@konsulko.com> a écrit :
> On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com>
> wrote:
> > > > > > >
> > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > > Hi Simon
> > > > > > > >
> > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org>
> a écrit :
> > > > > > > >
> > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and
> OF_HOSTFILE so
> > > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > > >
> > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is
> built and
> > > > > > > > > appended to U-Boot
> > > > > > > > > - OF_EMBED - for development purposes, the devicetree
> is embedded in
> > > > > > > > > the ELF file (also used for EFI)
> > > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > > >
> > > > > > > > > The last one is currently set up so that no devicetree is
> needed at all
> > > > > > > > > in the U-Boot tree. Most boards do provide one, but some
> don't. Some
> > > > > > > > > don't even provide instructions on how to boot on the
> board.
> > > > > > > > >
> > > > > > > > > The problems with this approach are documented in another
> patch in this
> > > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > > >
> > > > > > > > > In practice, OF_BOARD is not really distinct from
> OF_SEPARATE. Any board
> > > > > > > > > can obtain its devicetree at runtime, even it is has a
> devicetree built
> > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage
> bootloader and its
> > > > > > > > > caller may have a better idea about the hardware available
> in the machine.
> > > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > > >
> > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It
> should be an
> > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > > >
> > > > > > > > > This series makes this change, adding various missing
> devicetree files
> > > > > > > > > (and placeholders) to make the build work.
> > > > > > > > >
> > > > > > > > > Note: If board maintainers are able to add their own patch
> to add the
> > > > > > > > > files, some patches in this series can be dropped.
> > > > > > > > >
> > > > > > > > > It also provides a few qemu clean-ups discovered along the
> way. The
> > > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > > >
> > > > > > > > > [1]
> > > > > > > > >
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > Changes in v6:
> > > > > > > > > - Fix description of OF_BOARD so it refers just to the
> current state
> > > > > > > > > - Explain that the 'two devicetrees' refers to two
> *control* devicetrees
> > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > - Expand the commit message based on comments
> > > > > > > >
> > > > > > > > You haven’t addressed any concerns expressed on the mailing
> list.so I am
> > > > > > > > not in favor of this new version either.
> > > > > > > > If you make a version without « fake DTs » as you name them,
> there are good
> > > > > > > > advances in the documentation and other areas that would be
> better in
> > > > > > > > mainline….
> > > > > > > > If I am the only one thinking this way and the patch can be
> accepted, I
> > > > > > > > would love there is a warning in capital letters at the top
> of the DTS fake
> > > > > > > > files that explains the intent of this fake DT, the possible
> outcomes of
> > > > > > > > not using the one provided by the platform and the right way
> of dealing
> > > > > > > > with DTs for the platform.
> > > > > > >
> > > > > > > This is the part that I too am still unhappy about. I do not
> want
> > > > > > > reference or fake or whatever device trees in the U-Boot
> source tree.
> > > > > > > We should be able to _remove_ the ones we have, that are not
> required,
> > > > > > > with doc/board/...rst explaining how to get / view one. Not
> adding
> > > > > > > more.
> > > > > >
> > > > > > I understand you don't like it and that others don't as well. I
> wish
> > > > > > it had not come to this.
> > > > > >
> > > > > > However we are only talking about 10 boards, three of which
> don't even
> > > > > > have a devicetree anywhere I can find.
> > > > > >
> > > > > > I think on balance this is a substantial clean-up. I am happy to
> add
> > > > > > whatever caveats and documentation people want to clarify what is
> > > > > > going on here. I'm happy to look at future options where the
> > > > > > devicetree is hosted elsewhere, so long as it is trivial to
> build it
> > > > > > within U-Boot for development purposes.
> > > > > >
> > > > > > I'll also note that the bootstd series shows the devicetree
> source:
> > > > > >
> > > > > > Core: 246 devices, 88 uclasses, devicetree: board
> > > > > >
> > > > > > But for now, I still feel this is the best path forward.
> > > > >
> > > > > I'm not sure how to proceed here. The reviews are rather strongly
> > > > > against the "include a device tree that won't be used". The use
> case of
> > > > > "but for development someone might need to modify the device tree"
> is
> > > > > handled by platforms documenting where / how to get the real one.
> We
> > > > > should even update the Kconfig help to note that if you enable
> this your
> > > > > board docs MUST explain where the device tree can be seen (or have
> some
> > > > > legal reason you think it's OK to not...).
> > > >
> > > > Right, we can do lots of things as we have discussed. I am very
> > > > willing to work on these and make sure it is hard to do the thing.
> But
> > > > this series is long enough already.
> > >
> > > Yes, I think the rest of us had hoped you would come around to all of
> > > our reasoning by this point, is why this is taking so long.
> > >
> >
> > Look, if I thought this was all wrong I would not be doing it. We have
> > a range of opinions:
>
> And the rest of us wouldn't keep trying to argue otherwise if we didn't
> see problems with it, still.
>
> > - U-Boot should not have its own nodes/properties
>
> The caveat there is that aren't documented upstream bindings. I think
> at this point the lack of screaming and otherwise "wait, no no no
> don't!" that your current patch has gotten means it's time for a pull
> request, and for that to go in, and so this line of argument would be
> simply removed.
>
> > - U-Boot should not have DTs in-tree
>
> ... for the cases where the DTs are not used at run time, yes.
>
> > - U-Boot should have DTs only when essential
>
> I don't understand this point. Can you please elaborate?
>
> > - U-Boot should have DTs in-tree for all boards
>
> This is the line you're pushing and almost every other reviewer
> disagrees with.
For the sake of getting interesting parts of the patch set in and “move
on”, what about:
providing an empty (see below) DT for boards for which U-Boot receives the
“source of truth” so that there are no build issues.
The empty DT contains a comment that explains the DT lifecycle for the
board and points to the documentation tree for sample DTs.
The boards would the ones we talked about and SystemReady boards
https://www.arm.com/why-arm/architecture/systems/systemready-certification-program/ir?_ga=2.35159527.79382615.1638484482-159131740.1638484482
>
> > What's the downside here anyway?
>
> - A lack of clarity. We have dts files, you modify those dts files,
> they aren't used. What's the point? Oh, you forgot to tweak
> something else. Wait, now nothing works. Oh, it's a mismatch between
> what this dts was at one point, and what it needs to be now to
> actually work.
> - We're adding more ongoing sync-up work. While I loudly applaud the
> custodians that are keeping their dts files in sync very regularly,
> and I sympathize with the custodians that want to do it more, but are
> unable to find the time, I do not want to add more of this work. Even
> more so when it's unclear who would be doing it. Or what the use is.
>
> There's probably more if I think about it harder, but those are the
> first to spring to mind.
>
> > > > It is more than just development. A devicetree is needed for binman
> to
> > > > work, even if it is empty. The documentation idea doesn't really
> work,
> > > > as I think I have proven by the difficulty in getting this series
> > > > together. An automated mechanism that runs in CI might be acceptable,
> > > > but that is in the future. For now, I believe it just HAS to be
> > > > in-tree.
> > >
> > > I still don't see any reason why we need these incorrect and not
> > > functionally used device trees in-tree when a dummy invalid tree is
> > > enough to make things link. We're dealing with real "we must have
> X.bin
> > > in the output for things to function" issues on other platforms with
> > > binman right now. Using a dummy dts should be fine.
> >
> > Incorrect in what way?
>
> Well, in the QEMU instance, they're only as correct as the parameters
> passed to qemu-system-foo when you did -dumpdtb to start with. Lets
> take TPM as that now should show up in the device tree, or not,
> depending on if we have the backend side of it? Or all of the examples
> of how to arbitrarily configure a system as Heinrich noted.
>
> Or the Pi examples where we need to use the device tree passed to us
> because config.txt is the official way to modify things in the device
> tree on that platform.
>
> > How do I get a real one for development? How do I turn off OF_BOARD
> > and use the in-tree one?
>
> How do you turn off the run-time device tree and instead use the in-tree
> one for development, with your series?
>
> > The documentation approach is not good enough.
>
> Why? But maybe I can better explain things in Mark's part of the thread
> about power domains and serial on M1..
>
> > > > > And yes, we're "only" talking about 10 platforms, which include
> things
> > > > > like the "everyone" has one Pi family, the extraordinarily
> flexible (and
> > > > > so easy for the reference device tree to be very wrong) QEMU
> families
> > > > > and then platforms that are including a dts in-tree now because
> they
> > > > > were told that was required.
> > > >
> > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is
> > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot?
> > > > The argument is the same.
> > >
> > > Because we don't need it! It serves no purpose! It exists in Linux
> > > as that's the primary device tree source repository. We could _copy_
> it
> > > in, if it was useful. But then we need to re-sync it every so often,
> > > and for less clear reasons than all of the platforms that we need to
> > > sync with the kernel for, AND we use the tree.
> >
> > So some people don't need it and it serves no purpose for them. But
> > why do they care? It is not hurting anyone. This is all overblown.
>
> Because it's adding ongoing maintenance work, and reducing clarity of
> the codebase, to summarize my concerns above.
>
> > > There's even an argument to be made that it IS in Linux because when
> you
> > > build that dtb, it's what the firmware then ships and uses and provides
> > > to everyone at run time, possibly along with whatever other
> > > modifications the binary firmware did (see the assorted threads,
> > > including one this week about the problems we have because we don't
> just
> > > always use the dtb provided to us at run time).
> > >
> > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now
> > > > copied by RISC-V) which doesn't.
> > >
> > > Yes, these are more examples of "someone said we need to copy it in, so
> > > we copy it in".
> >
> > No that's not correct. With x86, ppc, integrator, ast2500 and many
> > others we *need* the DT and *it is not* created by QEMU.
>
> You're listing both QEMU virtual machines and QEMU-as-hardware-emulators
> above, which confuses things. The integrator code runs on real
> hardware. Real hardware which does not have the device tree on it. I
> assume that QEMU + Linux - U-Boot for integrator requires you to pass
> the .dtb in, just like real the real hardware does. That's true of all
> of the cases I believe where we use QEMU-as-hardware-emulator because
> QEMU is also authentic to the hardware.
>
> > > > > How about adjusting the make logic so that if a tree isn't found,
> we use
> > > > > a dummy minimal valid dts file?
> > > >
> > > > This is what I have done for the boards where I could not figure out
> > > > how to get any sort of DT, yes. But I don't think that should be the
> > > > default.
> > >
> > > The more I think about this, the more I think dummy minimal valid dts
> > > should be the fall-back default. This then solves the "I'm a
> developer,
> > > I need to modify the dts files" case because you then just provide the
> > > dts instead where it should go, and it's used.
> >
> > How does it solve it? I don't even know how to get it in many cases.
> > If it is a dummy then I cannot actually use it for development, right?
>
> It solves the problem of "we must have this dts file so that the build
> will not fail". The next step of "oh, we actually want to use it, and
> not the run-time provided dtb" would be the same as whatever you're
> doing with this series.
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 22:36 ` François Ozog
@ 2021-12-02 22:52 ` Tom Rini
2021-12-02 22:55 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-02 22:52 UTC (permalink / raw)
To: François Ozog
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Simon Glass, Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 8986 bytes --]
On Thu, Dec 02, 2021 at 11:36:59PM +0100, François Ozog wrote:
> Hi Simon,Tom
>
> Le jeu. 2 déc. 2021 à 19:34, Tom Rini <trini@konsulko.com> a écrit :
>
> > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com>
> > wrote:
> > > > > > > >
> > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > > > Hi Simon
> > > > > > > > >
> > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org>
> > a écrit :
> > > > > > > > >
> > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and
> > OF_HOSTFILE so
> > > > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > > > >
> > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is
> > built and
> > > > > > > > > > appended to U-Boot
> > > > > > > > > > - OF_EMBED - for development purposes, the devicetree
> > is embedded in
> > > > > > > > > > the ELF file (also used for EFI)
> > > > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > > > >
> > > > > > > > > > The last one is currently set up so that no devicetree is
> > needed at all
> > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some
> > don't. Some
> > > > > > > > > > don't even provide instructions on how to boot on the
> > board.
> > > > > > > > > >
> > > > > > > > > > The problems with this approach are documented in another
> > patch in this
> > > > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > > > >
> > > > > > > > > > In practice, OF_BOARD is not really distinct from
> > OF_SEPARATE. Any board
> > > > > > > > > > can obtain its devicetree at runtime, even it is has a
> > devicetree built
> > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage
> > bootloader and its
> > > > > > > > > > caller may have a better idea about the hardware available
> > in the machine.
> > > > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > > > >
> > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It
> > should be an
> > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > > > >
> > > > > > > > > > This series makes this change, adding various missing
> > devicetree files
> > > > > > > > > > (and placeholders) to make the build work.
> > > > > > > > > >
> > > > > > > > > > Note: If board maintainers are able to add their own patch
> > to add the
> > > > > > > > > > files, some patches in this series can be dropped.
> > > > > > > > > >
> > > > > > > > > > It also provides a few qemu clean-ups discovered along the
> > way. The
> > > > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > > > >
> > > > > > > > > > [1]
> > > > > > > > > >
> > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > >
> > > > > > > > > > Changes in v6:
> > > > > > > > > > - Fix description of OF_BOARD so it refers just to the
> > current state
> > > > > > > > > > - Explain that the 'two devicetrees' refers to two
> > *control* devicetrees
> > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > >
> > > > > > > > > You haven’t addressed any concerns expressed on the mailing
> > list.so I am
> > > > > > > > > not in favor of this new version either.
> > > > > > > > > If you make a version without « fake DTs » as you name them,
> > there are good
> > > > > > > > > advances in the documentation and other areas that would be
> > better in
> > > > > > > > > mainline….
> > > > > > > > > If I am the only one thinking this way and the patch can be
> > accepted, I
> > > > > > > > > would love there is a warning in capital letters at the top
> > of the DTS fake
> > > > > > > > > files that explains the intent of this fake DT, the possible
> > outcomes of
> > > > > > > > > not using the one provided by the platform and the right way
> > of dealing
> > > > > > > > > with DTs for the platform.
> > > > > > > >
> > > > > > > > This is the part that I too am still unhappy about. I do not
> > want
> > > > > > > > reference or fake or whatever device trees in the U-Boot
> > source tree.
> > > > > > > > We should be able to _remove_ the ones we have, that are not
> > required,
> > > > > > > > with doc/board/...rst explaining how to get / view one. Not
> > adding
> > > > > > > > more.
> > > > > > >
> > > > > > > I understand you don't like it and that others don't as well. I
> > wish
> > > > > > > it had not come to this.
> > > > > > >
> > > > > > > However we are only talking about 10 boards, three of which
> > don't even
> > > > > > > have a devicetree anywhere I can find.
> > > > > > >
> > > > > > > I think on balance this is a substantial clean-up. I am happy to
> > add
> > > > > > > whatever caveats and documentation people want to clarify what is
> > > > > > > going on here. I'm happy to look at future options where the
> > > > > > > devicetree is hosted elsewhere, so long as it is trivial to
> > build it
> > > > > > > within U-Boot for development purposes.
> > > > > > >
> > > > > > > I'll also note that the bootstd series shows the devicetree
> > source:
> > > > > > >
> > > > > > > Core: 246 devices, 88 uclasses, devicetree: board
> > > > > > >
> > > > > > > But for now, I still feel this is the best path forward.
> > > > > >
> > > > > > I'm not sure how to proceed here. The reviews are rather strongly
> > > > > > against the "include a device tree that won't be used". The use
> > case of
> > > > > > "but for development someone might need to modify the device tree"
> > is
> > > > > > handled by platforms documenting where / how to get the real one.
> > We
> > > > > > should even update the Kconfig help to note that if you enable
> > this your
> > > > > > board docs MUST explain where the device tree can be seen (or have
> > some
> > > > > > legal reason you think it's OK to not...).
> > > > >
> > > > > Right, we can do lots of things as we have discussed. I am very
> > > > > willing to work on these and make sure it is hard to do the thing.
> > But
> > > > > this series is long enough already.
> > > >
> > > > Yes, I think the rest of us had hoped you would come around to all of
> > > > our reasoning by this point, is why this is taking so long.
> > > >
> > >
> > > Look, if I thought this was all wrong I would not be doing it. We have
> > > a range of opinions:
> >
> > And the rest of us wouldn't keep trying to argue otherwise if we didn't
> > see problems with it, still.
> >
> > > - U-Boot should not have its own nodes/properties
> >
> > The caveat there is that aren't documented upstream bindings. I think
> > at this point the lack of screaming and otherwise "wait, no no no
> > don't!" that your current patch has gotten means it's time for a pull
> > request, and for that to go in, and so this line of argument would be
> > simply removed.
> >
> > > - U-Boot should not have DTs in-tree
> >
> > ... for the cases where the DTs are not used at run time, yes.
> >
> > > - U-Boot should have DTs only when essential
> >
> > I don't understand this point. Can you please elaborate?
> >
> > > - U-Boot should have DTs in-tree for all boards
> >
> > This is the line you're pushing and almost every other reviewer
> > disagrees with.
>
> For the sake of getting interesting parts of the patch set in and “move
> on”, what about:
> providing an empty (see below) DT for boards for which U-Boot receives the
> “source of truth” so that there are no build issues.
> The empty DT contains a comment that explains the DT lifecycle for the
> board and points to the documentation tree for sample DTs.
> The boards would the ones we talked about and SystemReady boards
> https://www.arm.com/why-arm/architecture/systems/systemready-certification-program/ir?_ga=2.35159527.79382615.1638484482-159131740.1638484482
My ROCKPro64 is on the way still, but I'm not sure what SystemReady IR
has to do with this exactly. I mean this very much seriously as I was
doing some testing with another platform in preparation for
certification and I was just using the device tree that in U-Boot.
Perhaps I just missed a section in one of the documents however.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 22:52 ` Tom Rini
@ 2021-12-02 22:55 ` Simon Glass
2021-12-03 15:14 ` Tom Rini
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 22:55 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Tom,
On Thu, 2 Dec 2021 at 15:53, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 02, 2021 at 11:36:59PM +0100, François Ozog wrote:
> > Hi Simon,Tom
> >
> > Le jeu. 2 déc. 2021 à 19:34, Tom Rini <trini@konsulko.com> a écrit :
> >
> > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com>
> > > wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > > > > Hi Simon
> > > > > > > > > >
> > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org>
> > > a écrit :
> > > > > > > > > >
> > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and
> > > OF_HOSTFILE so
> > > > > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > > > > >
> > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is
> > > built and
> > > > > > > > > > > appended to U-Boot
> > > > > > > > > > > - OF_EMBED - for development purposes, the devicetree
> > > is embedded in
> > > > > > > > > > > the ELF file (also used for EFI)
> > > > > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > > > > >
> > > > > > > > > > > The last one is currently set up so that no devicetree is
> > > needed at all
> > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some
> > > don't. Some
> > > > > > > > > > > don't even provide instructions on how to boot on the
> > > board.
> > > > > > > > > > >
> > > > > > > > > > > The problems with this approach are documented in another
> > > patch in this
> > > > > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > > > > >
> > > > > > > > > > > In practice, OF_BOARD is not really distinct from
> > > OF_SEPARATE. Any board
> > > > > > > > > > > can obtain its devicetree at runtime, even it is has a
> > > devicetree built
> > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage
> > > bootloader and its
> > > > > > > > > > > caller may have a better idea about the hardware available
> > > in the machine.
> > > > > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > > > > >
> > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It
> > > should be an
> > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > > > > >
> > > > > > > > > > > This series makes this change, adding various missing
> > > devicetree files
> > > > > > > > > > > (and placeholders) to make the build work.
> > > > > > > > > > >
> > > > > > > > > > > Note: If board maintainers are able to add their own patch
> > > to add the
> > > > > > > > > > > files, some patches in this series can be dropped.
> > > > > > > > > > >
> > > > > > > > > > > It also provides a few qemu clean-ups discovered along the
> > > way. The
> > > > > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > > > > >
> > > > > > > > > > > [1]
> > > > > > > > > > >
> > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > > >
> > > > > > > > > > > Changes in v6:
> > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the
> > > current state
> > > > > > > > > > > - Explain that the 'two devicetrees' refers to two
> > > *control* devicetrees
> > > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > >
> > > > > > > > > > You haven’t addressed any concerns expressed on the mailing
> > > list.so I am
> > > > > > > > > > not in favor of this new version either.
> > > > > > > > > > If you make a version without « fake DTs » as you name them,
> > > there are good
> > > > > > > > > > advances in the documentation and other areas that would be
> > > better in
> > > > > > > > > > mainline….
> > > > > > > > > > If I am the only one thinking this way and the patch can be
> > > accepted, I
> > > > > > > > > > would love there is a warning in capital letters at the top
> > > of the DTS fake
> > > > > > > > > > files that explains the intent of this fake DT, the possible
> > > outcomes of
> > > > > > > > > > not using the one provided by the platform and the right way
> > > of dealing
> > > > > > > > > > with DTs for the platform.
> > > > > > > > >
> > > > > > > > > This is the part that I too am still unhappy about. I do not
> > > want
> > > > > > > > > reference or fake or whatever device trees in the U-Boot
> > > source tree.
> > > > > > > > > We should be able to _remove_ the ones we have, that are not
> > > required,
> > > > > > > > > with doc/board/...rst explaining how to get / view one. Not
> > > adding
> > > > > > > > > more.
> > > > > > > >
> > > > > > > > I understand you don't like it and that others don't as well. I
> > > wish
> > > > > > > > it had not come to this.
> > > > > > > >
> > > > > > > > However we are only talking about 10 boards, three of which
> > > don't even
> > > > > > > > have a devicetree anywhere I can find.
> > > > > > > >
> > > > > > > > I think on balance this is a substantial clean-up. I am happy to
> > > add
> > > > > > > > whatever caveats and documentation people want to clarify what is
> > > > > > > > going on here. I'm happy to look at future options where the
> > > > > > > > devicetree is hosted elsewhere, so long as it is trivial to
> > > build it
> > > > > > > > within U-Boot for development purposes.
> > > > > > > >
> > > > > > > > I'll also note that the bootstd series shows the devicetree
> > > source:
> > > > > > > >
> > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board
> > > > > > > >
> > > > > > > > But for now, I still feel this is the best path forward.
> > > > > > >
> > > > > > > I'm not sure how to proceed here. The reviews are rather strongly
> > > > > > > against the "include a device tree that won't be used". The use
> > > case of
> > > > > > > "but for development someone might need to modify the device tree"
> > > is
> > > > > > > handled by platforms documenting where / how to get the real one.
> > > We
> > > > > > > should even update the Kconfig help to note that if you enable
> > > this your
> > > > > > > board docs MUST explain where the device tree can be seen (or have
> > > some
> > > > > > > legal reason you think it's OK to not...).
> > > > > >
> > > > > > Right, we can do lots of things as we have discussed. I am very
> > > > > > willing to work on these and make sure it is hard to do the thing.
> > > But
> > > > > > this series is long enough already.
> > > > >
> > > > > Yes, I think the rest of us had hoped you would come around to all of
> > > > > our reasoning by this point, is why this is taking so long.
> > > > >
> > > >
> > > > Look, if I thought this was all wrong I would not be doing it. We have
> > > > a range of opinions:
> > >
> > > And the rest of us wouldn't keep trying to argue otherwise if we didn't
> > > see problems with it, still.
> > >
> > > > - U-Boot should not have its own nodes/properties
> > >
> > > The caveat there is that aren't documented upstream bindings. I think
> > > at this point the lack of screaming and otherwise "wait, no no no
> > > don't!" that your current patch has gotten means it's time for a pull
> > > request, and for that to go in, and so this line of argument would be
> > > simply removed.
> > >
> > > > - U-Boot should not have DTs in-tree
> > >
> > > ... for the cases where the DTs are not used at run time, yes.
> > >
> > > > - U-Boot should have DTs only when essential
> > >
> > > I don't understand this point. Can you please elaborate?
> > >
> > > > - U-Boot should have DTs in-tree for all boards
> > >
> > > This is the line you're pushing and almost every other reviewer
> > > disagrees with.
> >
> > For the sake of getting interesting parts of the patch set in and “move
> > on”, what about:
> > providing an empty (see below) DT for boards for which U-Boot receives the
> > “source of truth” so that there are no build issues.
> > The empty DT contains a comment that explains the DT lifecycle for the
> > board and points to the documentation tree for sample DTs.
> > The boards would the ones we talked about and SystemReady boards
> > https://www.arm.com/why-arm/architecture/systems/systemready-certification-program/ir?_ga=2.35159527.79382615.1638484482-159131740.1638484482
>
> My ROCKPro64 is on the way still, but I'm not sure what SystemReady IR
> has to do with this exactly. I mean this very much seriously as I was
> doing some testing with another platform in preparation for
> certification and I was just using the device tree that in U-Boot.
> Perhaps I just missed a section in one of the documents however.
So now we find out the full horror of the fragmented mess that things
are to become. No way does this make sense.
It is already too hard to build things. Just look at the meson/binman
series I sent last week. We need to make things easier for people, not
harder.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 22:55 ` Simon Glass
@ 2021-12-03 15:14 ` Tom Rini
2021-12-03 15:47 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-03 15:14 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 964 bytes --]
On Thu, Dec 02, 2021 at 03:55:03PM -0700, Simon Glass wrote:
[snip]
> So now we find out the full horror of the fragmented mess that things
> are to become. No way does this make sense.
>
> It is already too hard to build things. Just look at the meson/binman
> series I sent last week. We need to make things easier for people, not
> harder.
I think this gets at one of my points. It seems exceedingly unlikely to
me that every semi vendor is going to stop making their own tooling and
per SoC requirements here and instead converge on a common one. I feel
like that's not even true in x86, but it's largely just Intel or AMD
rather than a handful of vendors. I see places we can make change
happen and places we're going to have to use what we're given. Unless
Arm Ltd pushes something, every semi gets to "innovate" in this area up
until the point where SystemReady (well, the underlying specifications)
say you MUST do X.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 15:14 ` Tom Rini
@ 2021-12-03 15:47 ` Simon Glass
0 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-03 15:47 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Tom,
On Fri, 3 Dec 2021 at 08:14, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 02, 2021 at 03:55:03PM -0700, Simon Glass wrote:
>
> [snip]
> > So now we find out the full horror of the fragmented mess that things
> > are to become. No way does this make sense.
> >
> > It is already too hard to build things. Just look at the meson/binman
> > series I sent last week. We need to make things easier for people, not
> > harder.
>
> I think this gets at one of my points. It seems exceedingly unlikely to
> me that every semi vendor is going to stop making their own tooling and
> per SoC requirements here and instead converge on a common one. I feel
> like that's not even true in x86, but it's largely just Intel or AMD
> rather than a handful of vendors. I see places we can make change
> happen and places we're going to have to use what we're given. Unless
> Arm Ltd pushes something, every semi gets to "innovate" in this area up
> until the point where SystemReady (well, the underlying specifications)
> say you MUST do X.
Yes, I think you are right. So I think the best we can do for now is
describe the image and the tools needed to make it, leaving the user
to collect the required binaries and tools that are needed, repeating
until binman stops saying 'missing external blobs'. BTW binman does
have a way to show help for how to get each blob
(tools/binman/missing-blob-help) and I plan to do the same for tools
when I respin the meson series.
For x86, Intel tools have ended up open source over time, e.g. under
the influence of Chrome OS. I am less sure on the AMD side though, but
will check that and push there if needed.
I'd suggest that Arm should require the tools to be open-source. I
will make that point next time I have a chance.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 18:34 ` Tom Rini
2021-12-02 19:12 ` Simon Glass
2021-12-02 22:36 ` François Ozog
@ 2021-12-03 1:57 ` Andre Przywara
2021-12-03 2:03 ` Simon Glass
2 siblings, 1 reply; 136+ messages in thread
From: Andre Przywara @ 2021-12-03 1:57 UTC (permalink / raw)
To: Tom Rini
Cc: Simon Glass, François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
On Thu, 2 Dec 2021 13:34:07 -0500
Tom Rini <trini@konsulko.com> wrote:
Hi,
> On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > > Hi Simon
> > > > > > > >
> > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > > > >
> > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > > >
> > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > > > appended to U-Boot
> > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > > > the ELF file (also used for EFI)
> > > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > > >
> > > > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > > > >
> > > > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > > >
> > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > > >
> > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > > >
> > > > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > > > (and placeholders) to make the build work.
> > > > > > > > >
> > > > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > > > files, some patches in this series can be dropped.
> > > > > > > > >
> > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > > >
> > > > > > > > > [1]
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > Changes in v6:
> > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > - Expand the commit message based on comments
> > > > > > > >
> > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > > not in favor of this new version either.
> > > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > > mainline….
> > > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > > with DTs for the platform.
> > > > > > >
> > > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > > more.
> > > > > >
> > > > > > I understand you don't like it and that others don't as well. I wish
> > > > > > it had not come to this.
> > > > > >
> > > > > > However we are only talking about 10 boards, three of which don't even
> > > > > > have a devicetree anywhere I can find.
> > > > > >
> > > > > > I think on balance this is a substantial clean-up. I am happy to add
> > > > > > whatever caveats and documentation people want to clarify what is
> > > > > > going on here. I'm happy to look at future options where the
> > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it
> > > > > > within U-Boot for development purposes.
> > > > > >
> > > > > > I'll also note that the bootstd series shows the devicetree source:
> > > > > >
> > > > > > Core: 246 devices, 88 uclasses, devicetree: board
> > > > > >
> > > > > > But for now, I still feel this is the best path forward.
> > > > >
> > > > > I'm not sure how to proceed here. The reviews are rather strongly
> > > > > against the "include a device tree that won't be used". The use case of
> > > > > "but for development someone might need to modify the device tree" is
> > > > > handled by platforms documenting where / how to get the real one. We
> > > > > should even update the Kconfig help to note that if you enable this your
> > > > > board docs MUST explain where the device tree can be seen (or have some
> > > > > legal reason you think it's OK to not...).
> > > >
> > > > Right, we can do lots of things as we have discussed. I am very
> > > > willing to work on these and make sure it is hard to do the thing. But
> > > > this series is long enough already.
> > >
> > > Yes, I think the rest of us had hoped you would come around to all of
> > > our reasoning by this point, is why this is taking so long.
> > >
> >
> > Look, if I thought this was all wrong I would not be doing it. We have
> > a range of opinions:
>
> And the rest of us wouldn't keep trying to argue otherwise if we didn't
> see problems with it, still.
>
> > - U-Boot should not have its own nodes/properties
>
> The caveat there is that aren't documented upstream bindings. I think
> at this point the lack of screaming and otherwise "wait, no no no
> don't!" that your current patch has gotten means it's time for a pull
> request, and for that to go in, and so this line of argument would be
> simply removed.
>
> > - U-Boot should not have DTs in-tree
>
> ... for the cases where the DTs are not used at run time, yes.
>
> > - U-Boot should have DTs only when essential
>
> I don't understand this point. Can you please elaborate?
>
> > - U-Boot should have DTs in-tree for all boards
>
> This is the line you're pushing and almost every other reviewer
> disagrees with.
>
> > What's the downside here anyway?
>
> - A lack of clarity. We have dts files, you modify those dts files,
> they aren't used. What's the point? Oh, you forgot to tweak
> something else. Wait, now nothing works. Oh, it's a mismatch between
> what this dts was at one point, and what it needs to be now to
> actually work.
> - We're adding more ongoing sync-up work. While I loudly applaud the
> custodians that are keeping their dts files in sync very regularly,
> and I sympathize with the custodians that want to do it more, but are
> unable to find the time, I do not want to add more of this work. Even
> more so when it's unclear who would be doing it. Or what the use is.
>
> There's probably more if I think about it harder, but those are the
> first to spring to mind.
>
> > > > It is more than just development. A devicetree is needed for binman to
> > > > work, even if it is empty. The documentation idea doesn't really work,
> > > > as I think I have proven by the difficulty in getting this series
> > > > together. An automated mechanism that runs in CI might be acceptable,
> > > > but that is in the future. For now, I believe it just HAS to be
> > > > in-tree.
> > >
> > > I still don't see any reason why we need these incorrect and not
> > > functionally used device trees in-tree when a dummy invalid tree is
> > > enough to make things link. We're dealing with real "we must have X.bin
> > > in the output for things to function" issues on other platforms with
> > > binman right now. Using a dummy dts should be fine.
> >
> > Incorrect in what way?
>
> Well, in the QEMU instance, they're only as correct as the parameters
> passed to qemu-system-foo when you did -dumpdtb to start with. Lets
> take TPM as that now should show up in the device tree, or not,
> depending on if we have the backend side of it? Or all of the examples
> of how to arbitrarily configure a system as Heinrich noted.
>
> Or the Pi examples where we need to use the device tree passed to us
> because config.txt is the official way to modify things in the device
> tree on that platform.
I feel like a lot of the confusion stems from the very different
roles that U-Boot plays on various platforms:
- In the traditional way U-Boot is the first and only piece of code
that runs between reset and the kernel. Having the DT as part of the
U-Boot image, and thus in the U-Boot source tree, makes sense, given
that we talk about a particular board only.
- Many platforms run other pieces of software (TF-A, SCP firmware)
alongside or before U-Boot, but still U-Boot is the main attraction,
and is doing firmware and setup duties. Most cheap ARM SoCs (sunxi,
RK) fall under this category. Depending on the particular firmware
setup, having the DTs in the tree (as a copy of the canonical Linux
source) again makes sense, and the DTB should probably be part of the
built U-Boot image as well, unless there is some better place.
But there is a quite different category of boards, where U-Boot is a
mere *loader*, and UEFI provider. The heavy lifting of platform setup
(clocks, DRAM, power) is either done by prior firmware code, or by a
separate management processor. The RPis, ARM Juno boards, Highbank and
many other (typically advanced) platforms fall under this category.
U-Boot should be happy about the lesser burden, and just consume
whatever DTB it finds in memory.
Virtual/dynamic platforms like QEMU or the ARM FVP models also fall
into this category: for a virtual platform hardware setup is mostly not
needed (DRAM, clock gating), or the emulator takes care of this already.
For all those platforms the DTB naturally lives with the other firmware
bits already, or is even amended by them, and U-Boot should not try to
duplicate this, especially when the hardware is somewhat dynamic.
Cheers,
Andre
> > How do I get a real one for development? How do I turn off OF_BOARD
> > and use the in-tree one?
>
> How do you turn off the run-time device tree and instead use the in-tree
> one for development, with your series?
>
> > The documentation approach is not good enough.
>
> Why? But maybe I can better explain things in Mark's part of the thread
> about power domains and serial on M1..
>
> > > > > And yes, we're "only" talking about 10 platforms, which include things
> > > > > like the "everyone" has one Pi family, the extraordinarily flexible (and
> > > > > so easy for the reference device tree to be very wrong) QEMU families
> > > > > and then platforms that are including a dts in-tree now because they
> > > > > were told that was required.
> > > >
> > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is
> > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot?
> > > > The argument is the same.
> > >
> > > Because we don't need it! It serves no purpose! It exists in Linux
> > > as that's the primary device tree source repository. We could _copy_ it
> > > in, if it was useful. But then we need to re-sync it every so often,
> > > and for less clear reasons than all of the platforms that we need to
> > > sync with the kernel for, AND we use the tree.
> >
> > So some people don't need it and it serves no purpose for them. But
> > why do they care? It is not hurting anyone. This is all overblown.
>
> Because it's adding ongoing maintenance work, and reducing clarity of
> the codebase, to summarize my concerns above.
>
> > > There's even an argument to be made that it IS in Linux because when you
> > > build that dtb, it's what the firmware then ships and uses and provides
> > > to everyone at run time, possibly along with whatever other
> > > modifications the binary firmware did (see the assorted threads,
> > > including one this week about the problems we have because we don't just
> > > always use the dtb provided to us at run time).
> > >
> > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now
> > > > copied by RISC-V) which doesn't.
> > >
> > > Yes, these are more examples of "someone said we need to copy it in, so
> > > we copy it in".
> >
> > No that's not correct. With x86, ppc, integrator, ast2500 and many
> > others we *need* the DT and *it is not* created by QEMU.
>
> You're listing both QEMU virtual machines and QEMU-as-hardware-emulators
> above, which confuses things. The integrator code runs on real
> hardware. Real hardware which does not have the device tree on it. I
> assume that QEMU + Linux - U-Boot for integrator requires you to pass
> the .dtb in, just like real the real hardware does. That's true of all
> of the cases I believe where we use QEMU-as-hardware-emulator because
> QEMU is also authentic to the hardware.
>
> > > > > How about adjusting the make logic so that if a tree isn't found, we use
> > > > > a dummy minimal valid dts file?
> > > >
> > > > This is what I have done for the boards where I could not figure out
> > > > how to get any sort of DT, yes. But I don't think that should be the
> > > > default.
> > >
> > > The more I think about this, the more I think dummy minimal valid dts
> > > should be the fall-back default. This then solves the "I'm a developer,
> > > I need to modify the dts files" case because you then just provide the
> > > dts instead where it should go, and it's used.
> >
> > How does it solve it? I don't even know how to get it in many cases.
> > If it is a dummy then I cannot actually use it for development, right?
>
> It solves the problem of "we must have this dts file so that the build
> will not fail". The next step of "oh, we actually want to use it, and
> not the run-time provided dtb" would be the same as whatever you're
> doing with this series.
>
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 1:57 ` Andre Przywara
@ 2021-12-03 2:03 ` Simon Glass
2021-12-03 20:43 ` Tom Rini
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-03 2:03 UTC (permalink / raw)
To: Andre Przywara
Cc: Tom Rini, François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Andre,
On Thu, 2 Dec 2021 at 18:59, Andre Przywara <andre.przywara@arm.com> wrote:
>
> On Thu, 2 Dec 2021 13:34:07 -0500
> Tom Rini <trini@konsulko.com> wrote:
>
> Hi,
>
> > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > > > Hi Simon
> > > > > > > > >
> > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > > > > >
> > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > > > >
> > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > > > > appended to U-Boot
> > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > > > > the ELF file (also used for EFI)
> > > > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > > > >
> > > > > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > > > > >
> > > > > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > > > >
> > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > > > >
> > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > > > >
> > > > > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > > > > (and placeholders) to make the build work.
> > > > > > > > > >
> > > > > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > > > > files, some patches in this series can be dropped.
> > > > > > > > > >
> > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > > > >
> > > > > > > > > > [1]
> > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > >
> > > > > > > > > > Changes in v6:
> > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > >
> > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > > > not in favor of this new version either.
> > > > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > > > mainline….
> > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > > > with DTs for the platform.
> > > > > > > >
> > > > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > > > more.
> > > > > > >
> > > > > > > I understand you don't like it and that others don't as well. I wish
> > > > > > > it had not come to this.
> > > > > > >
> > > > > > > However we are only talking about 10 boards, three of which don't even
> > > > > > > have a devicetree anywhere I can find.
> > > > > > >
> > > > > > > I think on balance this is a substantial clean-up. I am happy to add
> > > > > > > whatever caveats and documentation people want to clarify what is
> > > > > > > going on here. I'm happy to look at future options where the
> > > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it
> > > > > > > within U-Boot for development purposes.
> > > > > > >
> > > > > > > I'll also note that the bootstd series shows the devicetree source:
> > > > > > >
> > > > > > > Core: 246 devices, 88 uclasses, devicetree: board
> > > > > > >
> > > > > > > But for now, I still feel this is the best path forward.
> > > > > >
> > > > > > I'm not sure how to proceed here. The reviews are rather strongly
> > > > > > against the "include a device tree that won't be used". The use case of
> > > > > > "but for development someone might need to modify the device tree" is
> > > > > > handled by platforms documenting where / how to get the real one. We
> > > > > > should even update the Kconfig help to note that if you enable this your
> > > > > > board docs MUST explain where the device tree can be seen (or have some
> > > > > > legal reason you think it's OK to not...).
> > > > >
> > > > > Right, we can do lots of things as we have discussed. I am very
> > > > > willing to work on these and make sure it is hard to do the thing. But
> > > > > this series is long enough already.
> > > >
> > > > Yes, I think the rest of us had hoped you would come around to all of
> > > > our reasoning by this point, is why this is taking so long.
> > > >
> > >
> > > Look, if I thought this was all wrong I would not be doing it. We have
> > > a range of opinions:
> >
> > And the rest of us wouldn't keep trying to argue otherwise if we didn't
> > see problems with it, still.
> >
> > > - U-Boot should not have its own nodes/properties
> >
> > The caveat there is that aren't documented upstream bindings. I think
> > at this point the lack of screaming and otherwise "wait, no no no
> > don't!" that your current patch has gotten means it's time for a pull
> > request, and for that to go in, and so this line of argument would be
> > simply removed.
> >
> > > - U-Boot should not have DTs in-tree
> >
> > ... for the cases where the DTs are not used at run time, yes.
> >
> > > - U-Boot should have DTs only when essential
> >
> > I don't understand this point. Can you please elaborate?
> >
> > > - U-Boot should have DTs in-tree for all boards
> >
> > This is the line you're pushing and almost every other reviewer
> > disagrees with.
> >
> > > What's the downside here anyway?
> >
> > - A lack of clarity. We have dts files, you modify those dts files,
> > they aren't used. What's the point? Oh, you forgot to tweak
> > something else. Wait, now nothing works. Oh, it's a mismatch between
> > what this dts was at one point, and what it needs to be now to
> > actually work.
> > - We're adding more ongoing sync-up work. While I loudly applaud the
> > custodians that are keeping their dts files in sync very regularly,
> > and I sympathize with the custodians that want to do it more, but are
> > unable to find the time, I do not want to add more of this work. Even
> > more so when it's unclear who would be doing it. Or what the use is.
> >
> > There's probably more if I think about it harder, but those are the
> > first to spring to mind.
> >
> > > > > It is more than just development. A devicetree is needed for binman to
> > > > > work, even if it is empty. The documentation idea doesn't really work,
> > > > > as I think I have proven by the difficulty in getting this series
> > > > > together. An automated mechanism that runs in CI might be acceptable,
> > > > > but that is in the future. For now, I believe it just HAS to be
> > > > > in-tree.
> > > >
> > > > I still don't see any reason why we need these incorrect and not
> > > > functionally used device trees in-tree when a dummy invalid tree is
> > > > enough to make things link. We're dealing with real "we must have X.bin
> > > > in the output for things to function" issues on other platforms with
> > > > binman right now. Using a dummy dts should be fine.
> > >
> > > Incorrect in what way?
> >
> > Well, in the QEMU instance, they're only as correct as the parameters
> > passed to qemu-system-foo when you did -dumpdtb to start with. Lets
> > take TPM as that now should show up in the device tree, or not,
> > depending on if we have the backend side of it? Or all of the examples
> > of how to arbitrarily configure a system as Heinrich noted.
> >
> > Or the Pi examples where we need to use the device tree passed to us
> > because config.txt is the official way to modify things in the device
> > tree on that platform.
>
> I feel like a lot of the confusion stems from the very different
> roles that U-Boot plays on various platforms:
> - In the traditional way U-Boot is the first and only piece of code
> that runs between reset and the kernel. Having the DT as part of the
> U-Boot image, and thus in the U-Boot source tree, makes sense, given
> that we talk about a particular board only.
> - Many platforms run other pieces of software (TF-A, SCP firmware)
> alongside or before U-Boot, but still U-Boot is the main attraction,
> and is doing firmware and setup duties. Most cheap ARM SoCs (sunxi,
> RK) fall under this category. Depending on the particular firmware
> setup, having the DTs in the tree (as a copy of the canonical Linux
> source) again makes sense, and the DTB should probably be part of the
> built U-Boot image as well, unless there is some better place.
>
> But there is a quite different category of boards, where U-Boot is a
> mere *loader*, and UEFI provider. The heavy lifting of platform setup
> (clocks, DRAM, power) is either done by prior firmware code, or by a
> separate management processor. The RPis, ARM Juno boards, Highbank and
> many other (typically advanced) platforms fall under this category.
> U-Boot should be happy about the lesser burden, and just consume
> whatever DTB it finds in memory.
> Virtual/dynamic platforms like QEMU or the ARM FVP models also fall
> into this category: for a virtual platform hardware setup is mostly not
> needed (DRAM, clock gating), or the emulator takes care of this already.
>
> For all those platforms the DTB naturally lives with the other firmware
> bits already, or is even amended by them, and U-Boot should not try to
> duplicate this, especially when the hardware is somewhat dynamic.
Yes that is all understood and have been bashed to death in various
threads. Still, it is not unreasonable, I think, for U-Boot to have a
way to use an in-tree devicetree for development and testing purposes.
It also reasonable, I think, to require some in-tree documentation
about how to get U-Boot running on the board.
BTW I hope these other pieces of software are open-source!
Regards,
Simon
>
> Cheers,
> Andre
>
> > > How do I get a real one for development? How do I turn off OF_BOARD
> > > and use the in-tree one?
> >
> > How do you turn off the run-time device tree and instead use the in-tree
> > one for development, with your series?
> >
> > > The documentation approach is not good enough.
> >
> > Why? But maybe I can better explain things in Mark's part of the thread
> > about power domains and serial on M1..
> >
> > > > > > And yes, we're "only" talking about 10 platforms, which include things
> > > > > > like the "everyone" has one Pi family, the extraordinarily flexible (and
> > > > > > so easy for the reference device tree to be very wrong) QEMU families
> > > > > > and then platforms that are including a dts in-tree now because they
> > > > > > were told that was required.
> > > > >
> > > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is
> > > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot?
> > > > > The argument is the same.
> > > >
> > > > Because we don't need it! It serves no purpose! It exists in Linux
> > > > as that's the primary device tree source repository. We could _copy_ it
> > > > in, if it was useful. But then we need to re-sync it every so often,
> > > > and for less clear reasons than all of the platforms that we need to
> > > > sync with the kernel for, AND we use the tree.
> > >
> > > So some people don't need it and it serves no purpose for them. But
> > > why do they care? It is not hurting anyone. This is all overblown.
> >
> > Because it's adding ongoing maintenance work, and reducing clarity of
> > the codebase, to summarize my concerns above.
> >
> > > > There's even an argument to be made that it IS in Linux because when you
> > > > build that dtb, it's what the firmware then ships and uses and provides
> > > > to everyone at run time, possibly along with whatever other
> > > > modifications the binary firmware did (see the assorted threads,
> > > > including one this week about the problems we have because we don't just
> > > > always use the dtb provided to us at run time).
> > > >
> > > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now
> > > > > copied by RISC-V) which doesn't.
> > > >
> > > > Yes, these are more examples of "someone said we need to copy it in, so
> > > > we copy it in".
> > >
> > > No that's not correct. With x86, ppc, integrator, ast2500 and many
> > > others we *need* the DT and *it is not* created by QEMU.
> >
> > You're listing both QEMU virtual machines and QEMU-as-hardware-emulators
> > above, which confuses things. The integrator code runs on real
> > hardware. Real hardware which does not have the device tree on it. I
> > assume that QEMU + Linux - U-Boot for integrator requires you to pass
> > the .dtb in, just like real the real hardware does. That's true of all
> > of the cases I believe where we use QEMU-as-hardware-emulator because
> > QEMU is also authentic to the hardware.
> >
> > > > > > How about adjusting the make logic so that if a tree isn't found, we use
> > > > > > a dummy minimal valid dts file?
> > > > >
> > > > > This is what I have done for the boards where I could not figure out
> > > > > how to get any sort of DT, yes. But I don't think that should be the
> > > > > default.
> > > >
> > > > The more I think about this, the more I think dummy minimal valid dts
> > > > should be the fall-back default. This then solves the "I'm a developer,
> > > > I need to modify the dts files" case because you then just provide the
> > > > dts instead where it should go, and it's used.
> > >
> > > How does it solve it? I don't even know how to get it in many cases.
> > > If it is a dummy then I cannot actually use it for development, right?
> >
> > It solves the problem of "we must have this dts file so that the build
> > will not fail". The next step of "oh, we actually want to use it, and
> > not the run-time provided dtb" would be the same as whatever you're
> > doing with this series.
> >
>
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 2:03 ` Simon Glass
@ 2021-12-03 20:43 ` Tom Rini
2021-12-04 1:02 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-03 20:43 UTC (permalink / raw)
To: Simon Glass
Cc: Andre Przywara, François Ozog, Aaron Williams,
Albert Aribaud, Alexander Graf, Anastasiia Lukianenko, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 13072 bytes --]
On Thu, Dec 02, 2021 at 07:03:30PM -0700, Simon Glass wrote:
> Hi Andre,
>
> On Thu, 2 Dec 2021 at 18:59, Andre Przywara <andre.przywara@arm.com> wrote:
> >
> > On Thu, 2 Dec 2021 13:34:07 -0500
> > Tom Rini <trini@konsulko.com> wrote:
> >
> > Hi,
> >
> > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > > > > Hi Simon
> > > > > > > > > >
> > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > > > > > >
> > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > > > > >
> > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > > > > > appended to U-Boot
> > > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > > > > > the ELF file (also used for EFI)
> > > > > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > > > > >
> > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > > > > > >
> > > > > > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > > > > >
> > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > > > > >
> > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > > > > >
> > > > > > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > > > > > (and placeholders) to make the build work.
> > > > > > > > > > >
> > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > > > > > files, some patches in this series can be dropped.
> > > > > > > > > > >
> > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > > > > >
> > > > > > > > > > > [1]
> > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > > >
> > > > > > > > > > > Changes in v6:
> > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > >
> > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > > > > not in favor of this new version either.
> > > > > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > > > > mainline….
> > > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > > > > with DTs for the platform.
> > > > > > > > >
> > > > > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > > > > more.
> > > > > > > >
> > > > > > > > I understand you don't like it and that others don't as well. I wish
> > > > > > > > it had not come to this.
> > > > > > > >
> > > > > > > > However we are only talking about 10 boards, three of which don't even
> > > > > > > > have a devicetree anywhere I can find.
> > > > > > > >
> > > > > > > > I think on balance this is a substantial clean-up. I am happy to add
> > > > > > > > whatever caveats and documentation people want to clarify what is
> > > > > > > > going on here. I'm happy to look at future options where the
> > > > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it
> > > > > > > > within U-Boot for development purposes.
> > > > > > > >
> > > > > > > > I'll also note that the bootstd series shows the devicetree source:
> > > > > > > >
> > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board
> > > > > > > >
> > > > > > > > But for now, I still feel this is the best path forward.
> > > > > > >
> > > > > > > I'm not sure how to proceed here. The reviews are rather strongly
> > > > > > > against the "include a device tree that won't be used". The use case of
> > > > > > > "but for development someone might need to modify the device tree" is
> > > > > > > handled by platforms documenting where / how to get the real one. We
> > > > > > > should even update the Kconfig help to note that if you enable this your
> > > > > > > board docs MUST explain where the device tree can be seen (or have some
> > > > > > > legal reason you think it's OK to not...).
> > > > > >
> > > > > > Right, we can do lots of things as we have discussed. I am very
> > > > > > willing to work on these and make sure it is hard to do the thing. But
> > > > > > this series is long enough already.
> > > > >
> > > > > Yes, I think the rest of us had hoped you would come around to all of
> > > > > our reasoning by this point, is why this is taking so long.
> > > > >
> > > >
> > > > Look, if I thought this was all wrong I would not be doing it. We have
> > > > a range of opinions:
> > >
> > > And the rest of us wouldn't keep trying to argue otherwise if we didn't
> > > see problems with it, still.
> > >
> > > > - U-Boot should not have its own nodes/properties
> > >
> > > The caveat there is that aren't documented upstream bindings. I think
> > > at this point the lack of screaming and otherwise "wait, no no no
> > > don't!" that your current patch has gotten means it's time for a pull
> > > request, and for that to go in, and so this line of argument would be
> > > simply removed.
> > >
> > > > - U-Boot should not have DTs in-tree
> > >
> > > ... for the cases where the DTs are not used at run time, yes.
> > >
> > > > - U-Boot should have DTs only when essential
> > >
> > > I don't understand this point. Can you please elaborate?
> > >
> > > > - U-Boot should have DTs in-tree for all boards
> > >
> > > This is the line you're pushing and almost every other reviewer
> > > disagrees with.
> > >
> > > > What's the downside here anyway?
> > >
> > > - A lack of clarity. We have dts files, you modify those dts files,
> > > they aren't used. What's the point? Oh, you forgot to tweak
> > > something else. Wait, now nothing works. Oh, it's a mismatch between
> > > what this dts was at one point, and what it needs to be now to
> > > actually work.
> > > - We're adding more ongoing sync-up work. While I loudly applaud the
> > > custodians that are keeping their dts files in sync very regularly,
> > > and I sympathize with the custodians that want to do it more, but are
> > > unable to find the time, I do not want to add more of this work. Even
> > > more so when it's unclear who would be doing it. Or what the use is.
> > >
> > > There's probably more if I think about it harder, but those are the
> > > first to spring to mind.
> > >
> > > > > > It is more than just development. A devicetree is needed for binman to
> > > > > > work, even if it is empty. The documentation idea doesn't really work,
> > > > > > as I think I have proven by the difficulty in getting this series
> > > > > > together. An automated mechanism that runs in CI might be acceptable,
> > > > > > but that is in the future. For now, I believe it just HAS to be
> > > > > > in-tree.
> > > > >
> > > > > I still don't see any reason why we need these incorrect and not
> > > > > functionally used device trees in-tree when a dummy invalid tree is
> > > > > enough to make things link. We're dealing with real "we must have X.bin
> > > > > in the output for things to function" issues on other platforms with
> > > > > binman right now. Using a dummy dts should be fine.
> > > >
> > > > Incorrect in what way?
> > >
> > > Well, in the QEMU instance, they're only as correct as the parameters
> > > passed to qemu-system-foo when you did -dumpdtb to start with. Lets
> > > take TPM as that now should show up in the device tree, or not,
> > > depending on if we have the backend side of it? Or all of the examples
> > > of how to arbitrarily configure a system as Heinrich noted.
> > >
> > > Or the Pi examples where we need to use the device tree passed to us
> > > because config.txt is the official way to modify things in the device
> > > tree on that platform.
> >
> > I feel like a lot of the confusion stems from the very different
> > roles that U-Boot plays on various platforms:
> > - In the traditional way U-Boot is the first and only piece of code
> > that runs between reset and the kernel. Having the DT as part of the
> > U-Boot image, and thus in the U-Boot source tree, makes sense, given
> > that we talk about a particular board only.
> > - Many platforms run other pieces of software (TF-A, SCP firmware)
> > alongside or before U-Boot, but still U-Boot is the main attraction,
> > and is doing firmware and setup duties. Most cheap ARM SoCs (sunxi,
> > RK) fall under this category. Depending on the particular firmware
> > setup, having the DTs in the tree (as a copy of the canonical Linux
> > source) again makes sense, and the DTB should probably be part of the
> > built U-Boot image as well, unless there is some better place.
> >
> > But there is a quite different category of boards, where U-Boot is a
> > mere *loader*, and UEFI provider. The heavy lifting of platform setup
> > (clocks, DRAM, power) is either done by prior firmware code, or by a
> > separate management processor. The RPis, ARM Juno boards, Highbank and
> > many other (typically advanced) platforms fall under this category.
> > U-Boot should be happy about the lesser burden, and just consume
> > whatever DTB it finds in memory.
> > Virtual/dynamic platforms like QEMU or the ARM FVP models also fall
> > into this category: for a virtual platform hardware setup is mostly not
> > needed (DRAM, clock gating), or the emulator takes care of this already.
> >
> > For all those platforms the DTB naturally lives with the other firmware
> > bits already, or is even amended by them, and U-Boot should not try to
> > duplicate this, especially when the hardware is somewhat dynamic.
>
> Yes that is all understood and have been bashed to death in various
> threads. Still, it is not unreasonable, I think, for U-Boot to have a
> way to use an in-tree devicetree for development and testing purposes.
> It also reasonable, I think, to require some in-tree documentation
> about how to get U-Boot running on the board.
OK, but what at least I'm saying (and I think others are too), is that
it's also not unreasonable to say that on some platforms that
development and testing purpose might require the developer to enable
things, rather than be the out of the box case (and may be more or less
hard to do, depending on the platform).
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 20:43 ` Tom Rini
@ 2021-12-04 1:02 ` Simon Glass
0 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-04 1:02 UTC (permalink / raw)
To: Tom Rini
Cc: Andre Przywara, François Ozog, Aaron Williams,
Albert Aribaud, Alexander Graf, Anastasiia Lukianenko, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Tom,
On Fri, 3 Dec 2021 at 13:43, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 02, 2021 at 07:03:30PM -0700, Simon Glass wrote:
> > Hi Andre,
> >
> > On Thu, 2 Dec 2021 at 18:59, Andre Przywara <andre.przywara@arm.com> wrote:
> > >
> > > On Thu, 2 Dec 2021 13:34:07 -0500
> > > Tom Rini <trini@konsulko.com> wrote:
> > >
> > > Hi,
> > >
> > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > > > > > Hi Simon
> > > > > > > > > > >
> > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > > > > > > >
> > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > > > > > >
> > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > > > > > > appended to U-Boot
> > > > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > > > > > > the ELF file (also used for EFI)
> > > > > > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > > > > > >
> > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > > > > > > >
> > > > > > > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > > > > > >
> > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > > > > > >
> > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > > > > > >
> > > > > > > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > > > > > > (and placeholders) to make the build work.
> > > > > > > > > > > >
> > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > > > > > > files, some patches in this series can be dropped.
> > > > > > > > > > > >
> > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > > > > > >
> > > > > > > > > > > > [1]
> > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > > > >
> > > > > > > > > > > > Changes in v6:
> > > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > > >
> > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > > > > > not in favor of this new version either.
> > > > > > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > > > > > mainline….
> > > > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > > > > > with DTs for the platform.
> > > > > > > > > >
> > > > > > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > > > > > more.
> > > > > > > > >
> > > > > > > > > I understand you don't like it and that others don't as well. I wish
> > > > > > > > > it had not come to this.
> > > > > > > > >
> > > > > > > > > However we are only talking about 10 boards, three of which don't even
> > > > > > > > > have a devicetree anywhere I can find.
> > > > > > > > >
> > > > > > > > > I think on balance this is a substantial clean-up. I am happy to add
> > > > > > > > > whatever caveats and documentation people want to clarify what is
> > > > > > > > > going on here. I'm happy to look at future options where the
> > > > > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it
> > > > > > > > > within U-Boot for development purposes.
> > > > > > > > >
> > > > > > > > > I'll also note that the bootstd series shows the devicetree source:
> > > > > > > > >
> > > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board
> > > > > > > > >
> > > > > > > > > But for now, I still feel this is the best path forward.
> > > > > > > >
> > > > > > > > I'm not sure how to proceed here. The reviews are rather strongly
> > > > > > > > against the "include a device tree that won't be used". The use case of
> > > > > > > > "but for development someone might need to modify the device tree" is
> > > > > > > > handled by platforms documenting where / how to get the real one. We
> > > > > > > > should even update the Kconfig help to note that if you enable this your
> > > > > > > > board docs MUST explain where the device tree can be seen (or have some
> > > > > > > > legal reason you think it's OK to not...).
> > > > > > >
> > > > > > > Right, we can do lots of things as we have discussed. I am very
> > > > > > > willing to work on these and make sure it is hard to do the thing. But
> > > > > > > this series is long enough already.
> > > > > >
> > > > > > Yes, I think the rest of us had hoped you would come around to all of
> > > > > > our reasoning by this point, is why this is taking so long.
> > > > > >
> > > > >
> > > > > Look, if I thought this was all wrong I would not be doing it. We have
> > > > > a range of opinions:
> > > >
> > > > And the rest of us wouldn't keep trying to argue otherwise if we didn't
> > > > see problems with it, still.
> > > >
> > > > > - U-Boot should not have its own nodes/properties
> > > >
> > > > The caveat there is that aren't documented upstream bindings. I think
> > > > at this point the lack of screaming and otherwise "wait, no no no
> > > > don't!" that your current patch has gotten means it's time for a pull
> > > > request, and for that to go in, and so this line of argument would be
> > > > simply removed.
> > > >
> > > > > - U-Boot should not have DTs in-tree
> > > >
> > > > ... for the cases where the DTs are not used at run time, yes.
> > > >
> > > > > - U-Boot should have DTs only when essential
> > > >
> > > > I don't understand this point. Can you please elaborate?
> > > >
> > > > > - U-Boot should have DTs in-tree for all boards
> > > >
> > > > This is the line you're pushing and almost every other reviewer
> > > > disagrees with.
> > > >
> > > > > What's the downside here anyway?
> > > >
> > > > - A lack of clarity. We have dts files, you modify those dts files,
> > > > they aren't used. What's the point? Oh, you forgot to tweak
> > > > something else. Wait, now nothing works. Oh, it's a mismatch between
> > > > what this dts was at one point, and what it needs to be now to
> > > > actually work.
> > > > - We're adding more ongoing sync-up work. While I loudly applaud the
> > > > custodians that are keeping their dts files in sync very regularly,
> > > > and I sympathize with the custodians that want to do it more, but are
> > > > unable to find the time, I do not want to add more of this work. Even
> > > > more so when it's unclear who would be doing it. Or what the use is.
> > > >
> > > > There's probably more if I think about it harder, but those are the
> > > > first to spring to mind.
> > > >
> > > > > > > It is more than just development. A devicetree is needed for binman to
> > > > > > > work, even if it is empty. The documentation idea doesn't really work,
> > > > > > > as I think I have proven by the difficulty in getting this series
> > > > > > > together. An automated mechanism that runs in CI might be acceptable,
> > > > > > > but that is in the future. For now, I believe it just HAS to be
> > > > > > > in-tree.
> > > > > >
> > > > > > I still don't see any reason why we need these incorrect and not
> > > > > > functionally used device trees in-tree when a dummy invalid tree is
> > > > > > enough to make things link. We're dealing with real "we must have X.bin
> > > > > > in the output for things to function" issues on other platforms with
> > > > > > binman right now. Using a dummy dts should be fine.
> > > > >
> > > > > Incorrect in what way?
> > > >
> > > > Well, in the QEMU instance, they're only as correct as the parameters
> > > > passed to qemu-system-foo when you did -dumpdtb to start with. Lets
> > > > take TPM as that now should show up in the device tree, or not,
> > > > depending on if we have the backend side of it? Or all of the examples
> > > > of how to arbitrarily configure a system as Heinrich noted.
> > > >
> > > > Or the Pi examples where we need to use the device tree passed to us
> > > > because config.txt is the official way to modify things in the device
> > > > tree on that platform.
> > >
> > > I feel like a lot of the confusion stems from the very different
> > > roles that U-Boot plays on various platforms:
> > > - In the traditional way U-Boot is the first and only piece of code
> > > that runs between reset and the kernel. Having the DT as part of the
> > > U-Boot image, and thus in the U-Boot source tree, makes sense, given
> > > that we talk about a particular board only.
> > > - Many platforms run other pieces of software (TF-A, SCP firmware)
> > > alongside or before U-Boot, but still U-Boot is the main attraction,
> > > and is doing firmware and setup duties. Most cheap ARM SoCs (sunxi,
> > > RK) fall under this category. Depending on the particular firmware
> > > setup, having the DTs in the tree (as a copy of the canonical Linux
> > > source) again makes sense, and the DTB should probably be part of the
> > > built U-Boot image as well, unless there is some better place.
> > >
> > > But there is a quite different category of boards, where U-Boot is a
> > > mere *loader*, and UEFI provider. The heavy lifting of platform setup
> > > (clocks, DRAM, power) is either done by prior firmware code, or by a
> > > separate management processor. The RPis, ARM Juno boards, Highbank and
> > > many other (typically advanced) platforms fall under this category.
> > > U-Boot should be happy about the lesser burden, and just consume
> > > whatever DTB it finds in memory.
> > > Virtual/dynamic platforms like QEMU or the ARM FVP models also fall
> > > into this category: for a virtual platform hardware setup is mostly not
> > > needed (DRAM, clock gating), or the emulator takes care of this already.
> > >
> > > For all those platforms the DTB naturally lives with the other firmware
> > > bits already, or is even amended by them, and U-Boot should not try to
> > > duplicate this, especially when the hardware is somewhat dynamic.
> >
> > Yes that is all understood and have been bashed to death in various
> > threads. Still, it is not unreasonable, I think, for U-Boot to have a
> > way to use an in-tree devicetree for development and testing purposes.
> > It also reasonable, I think, to require some in-tree documentation
> > about how to get U-Boot running on the board.
>
> OK, but what at least I'm saying (and I think others are too), is that
> it's also not unreasonable to say that on some platforms that
> development and testing purpose might require the developer to enable
> things, rather than be the out of the box case (and may be more or less
> hard to do, depending on the platform).
Can we just say that *for now*, that is actually not acceptable and
we'll move to that model when we have our various pre-conditions
(bindings upstream, a central repo for DTs with easy downloading for
builds, automated validation) set up? I am trying to keep firmware
together and make it easy to build and understand.
Perhaps I can indicate how easy I'd like it to be. I'd like to build
the board in U-Boot. I'd like Binman (or whatever tool we end up with
here) to spit out a
- list of missing binaries along with instructions on where to get
them from / how to build them
- list of missing tools along with instructions on where to get them
from / how to build them
and once we have installed those once, we can build U-Boot again and
that platform successfully boots. Future iteration in U-Boot should be
simply a case of rebuilding U-Boot. Iteration in other projects should
just involve building that project, then running the packaging tool
again.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 18:17 ` Simon Glass
2021-12-02 18:34 ` Tom Rini
@ 2021-12-03 1:29 ` Andre Przywara
2021-12-03 1:43 ` Simon Glass
1 sibling, 1 reply; 136+ messages in thread
From: Andre Przywara @ 2021-12-03 1:29 UTC (permalink / raw)
To: Simon Glass
Cc: Tom Rini, François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
On Thu, 2 Dec 2021 11:17:38 -0700
Simon Glass <sjg@chromium.org> wrote:
> Hi Tom,
>
> On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > Hi Simon
> > > > > > >
> > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > > >
> > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > >
> > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > > appended to U-Boot
> > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > > the ELF file (also used for EFI)
> > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > >
> > > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > > >
> > > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > >
> > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > >
> > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > >
> > > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > > (and placeholders) to make the build work.
> > > > > > > >
> > > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > > files, some patches in this series can be dropped.
> > > > > > > >
> > > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > >
> > > > > > > > [1]
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > >
> > > > > > > > Changes in v6:
> > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > - Expand the commit message based on comments
> > > > > > > > - Expand the commit message based on comments
> > > > > > >
> > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > not in favor of this new version either.
> > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > mainline….
> > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > with DTs for the platform.
> > > > > >
> > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > more.
> > > > >
> > > > > I understand you don't like it and that others don't as well. I wish
> > > > > it had not come to this.
> > > > >
> > > > > However we are only talking about 10 boards, three of which don't even
> > > > > have a devicetree anywhere I can find.
> > > > >
> > > > > I think on balance this is a substantial clean-up. I am happy to add
> > > > > whatever caveats and documentation people want to clarify what is
> > > > > going on here. I'm happy to look at future options where the
> > > > > devicetree is hosted elsewhere, so long as it is trivial to build it
> > > > > within U-Boot for development purposes.
> > > > >
> > > > > I'll also note that the bootstd series shows the devicetree source:
> > > > >
> > > > > Core: 246 devices, 88 uclasses, devicetree: board
> > > > >
> > > > > But for now, I still feel this is the best path forward.
> > > >
> > > > I'm not sure how to proceed here. The reviews are rather strongly
> > > > against the "include a device tree that won't be used". The use case of
> > > > "but for development someone might need to modify the device tree" is
> > > > handled by platforms documenting where / how to get the real one. We
> > > > should even update the Kconfig help to note that if you enable this your
> > > > board docs MUST explain where the device tree can be seen (or have some
> > > > legal reason you think it's OK to not...).
> > >
> > > Right, we can do lots of things as we have discussed. I am very
> > > willing to work on these and make sure it is hard to do the thing. But
> > > this series is long enough already.
> >
> > Yes, I think the rest of us had hoped you would come around to all of
> > our reasoning by this point, is why this is taking so long.
> >
>
> Look, if I thought this was all wrong I would not be doing it. We have
> a range of opinions:
>
> - U-Boot should not have its own nodes/properties
> - U-Boot should not have DTs in-tree
> - U-Boot should have DTs only when essential
> - U-Boot should have DTs in-tree for all boards
>
> What's the downside here anyway?
>
> > > It is more than just development. A devicetree is needed for binman to
> > > work, even if it is empty. The documentation idea doesn't really work,
> > > as I think I have proven by the difficulty in getting this series
> > > together. An automated mechanism that runs in CI might be acceptable,
> > > but that is in the future. For now, I believe it just HAS to be
> > > in-tree.
> >
> > I still don't see any reason why we need these incorrect and not
> > functionally used device trees in-tree when a dummy invalid tree is
> > enough to make things link. We're dealing with real "we must have X.bin
> > in the output for things to function" issues on other platforms with
> > binman right now. Using a dummy dts should be fine.
>
> Incorrect in what way?
>
> How do I get a real one for development? How do I turn off OF_BOARD
> and use the in-tree one?
>
> The documentation approach is not good enough.
>
> >
> > > > And yes, we're "only" talking about 10 platforms, which include things
> > > > like the "everyone" has one Pi family, the extraordinarily flexible (and
> > > > so easy for the reference device tree to be very wrong) QEMU families
> > > > and then platforms that are including a dts in-tree now because they
> > > > were told that was required.
> > >
> > > Actually it is only rpi4 that doesn't have an in-tree DT. There is
> > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot?
> > > The argument is the same.
> >
> > Because we don't need it! It serves no purpose! It exists in Linux
> > as that's the primary device tree source repository. We could _copy_ it
> > in, if it was useful. But then we need to re-sync it every so often,
> > and for less clear reasons than all of the platforms that we need to
> > sync with the kernel for, AND we use the tree.
>
> So some people don't need it and it serves no purpose for them. But
> why do they care? It is not hurting anyone. This is all overblown.
>
> >
> > There's even an argument to be made that it IS in Linux because when you
> > build that dtb, it's what the firmware then ships and uses and provides
> > to everyone at run time, possibly along with whatever other
> > modifications the binary firmware did (see the assorted threads,
> > including one this week about the problems we have because we don't just
> > always use the dtb provided to us at run time).
> >
> > > Most QEMU boards have an in-tree devicetree. It is only ARM (now
> > > copied by RISC-V) which doesn't.
> >
> > Yes, these are more examples of "someone said we need to copy it in, so
> > we copy it in".
>
> No that's not correct. With x86, ppc, integrator, ast2500 and many
> others we *need* the DT and *it is not* created by QEMU.
Maybe because those are fixed platforms, and/or have ways to autodetect
most of their hardware? I feel like U-Boot just has a DT here because
it uses it as some kind of configuration file, short of hardcoding the
hardware information.
I think this is one reason that x86 PCs don't use DTs: there is only
*one* fixed base platform (1981 IBM PC, with all its oddities), plus
probeable hardware (PCI) for most of the devices.
I personally absolutely love that QEMU creates the DT based on its
command line parameters: that's the way it should be, and the only way
it makes sense to me for this dynamic platform. Having some random QEMU
DT in the U-Boot tree sounds wrong, IMHO.
Cheers,
Andre.
>
> >
> > > > How about adjusting the make logic so that if a tree isn't found, we use
> > > > a dummy minimal valid dts file?
> > >
> > > This is what I have done for the boards where I could not figure out
> > > how to get any sort of DT, yes. But I don't think that should be the
> > > default.
> >
> > The more I think about this, the more I think dummy minimal valid dts
> > should be the fall-back default. This then solves the "I'm a developer,
> > I need to modify the dts files" case because you then just provide the
> > dts instead where it should go, and it's used.
>
> How does it solve it? I don't even know how to get it in many cases.
> If it is a dummy then I cannot actually use it for development, right?
>
> Regards,
> Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 1:29 ` Andre Przywara
@ 2021-12-03 1:43 ` Simon Glass
0 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-03 1:43 UTC (permalink / raw)
To: Andre Przywara
Cc: Tom Rini, François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Andre,
On Thu, 2 Dec 2021 at 18:31, Andre Przywara <andre.przywara@arm.com> wrote:
>
> On Thu, 2 Dec 2021 11:17:38 -0700
> Simon Glass <sjg@chromium.org> wrote:
>
> > Hi Tom,
> >
> > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > > Hi Simon
> > > > > > > >
> > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > > > >
> > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > > >
> > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > > > appended to U-Boot
> > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > > > the ELF file (also used for EFI)
> > > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > > >
> > > > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > > > >
> > > > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > > >
> > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > > >
> > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > > >
> > > > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > > > (and placeholders) to make the build work.
> > > > > > > > >
> > > > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > > > files, some patches in this series can be dropped.
> > > > > > > > >
> > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > > >
> > > > > > > > > [1]
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > Changes in v6:
> > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > - Expand the commit message based on comments
> > > > > > > >
> > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > > not in favor of this new version either.
> > > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > > mainline….
> > > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > > with DTs for the platform.
> > > > > > >
> > > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > > more.
> > > > > >
> > > > > > I understand you don't like it and that others don't as well. I wish
> > > > > > it had not come to this.
> > > > > >
> > > > > > However we are only talking about 10 boards, three of which don't even
> > > > > > have a devicetree anywhere I can find.
> > > > > >
> > > > > > I think on balance this is a substantial clean-up. I am happy to add
> > > > > > whatever caveats and documentation people want to clarify what is
> > > > > > going on here. I'm happy to look at future options where the
> > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it
> > > > > > within U-Boot for development purposes.
> > > > > >
> > > > > > I'll also note that the bootstd series shows the devicetree source:
> > > > > >
> > > > > > Core: 246 devices, 88 uclasses, devicetree: board
> > > > > >
> > > > > > But for now, I still feel this is the best path forward.
> > > > >
> > > > > I'm not sure how to proceed here. The reviews are rather strongly
> > > > > against the "include a device tree that won't be used". The use case of
> > > > > "but for development someone might need to modify the device tree" is
> > > > > handled by platforms documenting where / how to get the real one. We
> > > > > should even update the Kconfig help to note that if you enable this your
> > > > > board docs MUST explain where the device tree can be seen (or have some
> > > > > legal reason you think it's OK to not...).
> > > >
> > > > Right, we can do lots of things as we have discussed. I am very
> > > > willing to work on these and make sure it is hard to do the thing. But
> > > > this series is long enough already.
> > >
> > > Yes, I think the rest of us had hoped you would come around to all of
> > > our reasoning by this point, is why this is taking so long.
> > >
> >
> > Look, if I thought this was all wrong I would not be doing it. We have
> > a range of opinions:
> >
> > - U-Boot should not have its own nodes/properties
> > - U-Boot should not have DTs in-tree
> > - U-Boot should have DTs only when essential
> > - U-Boot should have DTs in-tree for all boards
> >
> > What's the downside here anyway?
> >
> > > > It is more than just development. A devicetree is needed for binman to
> > > > work, even if it is empty. The documentation idea doesn't really work,
> > > > as I think I have proven by the difficulty in getting this series
> > > > together. An automated mechanism that runs in CI might be acceptable,
> > > > but that is in the future. For now, I believe it just HAS to be
> > > > in-tree.
> > >
> > > I still don't see any reason why we need these incorrect and not
> > > functionally used device trees in-tree when a dummy invalid tree is
> > > enough to make things link. We're dealing with real "we must have X.bin
> > > in the output for things to function" issues on other platforms with
> > > binman right now. Using a dummy dts should be fine.
> >
> > Incorrect in what way?
> >
> > How do I get a real one for development? How do I turn off OF_BOARD
> > and use the in-tree one?
> >
> > The documentation approach is not good enough.
> >
> > >
> > > > > And yes, we're "only" talking about 10 platforms, which include things
> > > > > like the "everyone" has one Pi family, the extraordinarily flexible (and
> > > > > so easy for the reference device tree to be very wrong) QEMU families
> > > > > and then platforms that are including a dts in-tree now because they
> > > > > were told that was required.
> > > >
> > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is
> > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot?
> > > > The argument is the same.
> > >
> > > Because we don't need it! It serves no purpose! It exists in Linux
> > > as that's the primary device tree source repository. We could _copy_ it
> > > in, if it was useful. But then we need to re-sync it every so often,
> > > and for less clear reasons than all of the platforms that we need to
> > > sync with the kernel for, AND we use the tree.
> >
> > So some people don't need it and it serves no purpose for them. But
> > why do they care? It is not hurting anyone. This is all overblown.
> >
> > >
> > > There's even an argument to be made that it IS in Linux because when you
> > > build that dtb, it's what the firmware then ships and uses and provides
> > > to everyone at run time, possibly along with whatever other
> > > modifications the binary firmware did (see the assorted threads,
> > > including one this week about the problems we have because we don't just
> > > always use the dtb provided to us at run time).
> > >
> > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now
> > > > copied by RISC-V) which doesn't.
> > >
> > > Yes, these are more examples of "someone said we need to copy it in, so
> > > we copy it in".
> >
> > No that's not correct. With x86, ppc, integrator, ast2500 and many
> > others we *need* the DT and *it is not* created by QEMU.
>
> Maybe because those are fixed platforms, and/or have ways to autodetect
> most of their hardware? I feel like U-Boot just has a DT here because
> it uses it as some kind of configuration file, short of hardcoding the
> hardware information.
> I think this is one reason that x86 PCs don't use DTs: there is only
> *one* fixed base platform (1981 IBM PC, with all its oddities), plus
> probeable hardware (PCI) for most of the devices.
>
> I personally absolutely love that QEMU creates the DT based on its
> command line parameters: that's the way it should be, and the only way
> it makes sense to me for this dynamic platform. Having some random QEMU
> DT in the U-Boot tree sounds wrong, IMHO.
The QEMU arm virt maintainer seems less enthusiastic, but I agree it
is a useful idea. One might argue that it should work by enabling
nodes rather than making them out of whole cloth, or provide a way to
add/delete things, but at least it works in the common case.
But when you want to develop a new feature, where QEMU doesn't have a
node you need, or want to run qemu with SPL, what do you do? Just give
up? Go and hack QEMU?
Anyway, no one is making you to use the U-Boot devicetree, so don't
worry about it.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 16:38 ` Tom Rini
2021-12-02 16:49 ` Simon Glass
@ 2021-12-02 17:03 ` Ilias Apalodimas
2021-12-02 17:09 ` Simon Glass
` (2 more replies)
1 sibling, 3 replies; 136+ messages in thread
From: Ilias Apalodimas @ 2021-12-02 17:03 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Simon Glass, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Jerry Van Baren, Linus Walleij,
Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > Hi Simon
> >
> > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> >
> > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > there are only three ways to obtain a devicetree:
> > >
> > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > appended to U-Boot
> > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > the ELF file (also used for EFI)
> > > - OF_BOARD - the board figures it out on its own
> > >
> > > The last one is currently set up so that no devicetree is needed at all
> > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > don't even provide instructions on how to boot on the board.
> > >
> > > The problems with this approach are documented in another patch in this
> > > series: "doc: Add documentation about devicetree usage"
> > >
> > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > caller may have a better idea about the hardware available in the machine.
> > > This is the case with a few QEMU boards, for example.
> > >
> > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > option, available with either OF_SEPARATE or OF_EMBED.
> > >
> > > This series makes this change, adding various missing devicetree files
> > > (and placeholders) to make the build work.
> > >
> > > Note: If board maintainers are able to add their own patch to add the
> > > files, some patches in this series can be dropped.
> > >
> > > It also provides a few qemu clean-ups discovered along the way. The
> > > qemu-riscv64_spl problem is fixed.
> > >
> > > [1]
> > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > >
> > > Changes in v6:
> > > - Fix description of OF_BOARD so it refers just to the current state
> > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > - Expand the commit message based on comments
> > > - Expand the commit message based on comments
> >
> > You haven’t addressed any concerns expressed on the mailing list.so I am
> > not in favor of this new version either.
> > If you make a version without « fake DTs » as you name them, there are good
> > advances in the documentation and other areas that would be better in
> > mainline….
> > If I am the only one thinking this way and the patch can be accepted, I
> > would love there is a warning in capital letters at the top of the DTS fake
> > files that explains the intent of this fake DT, the possible outcomes of
> > not using the one provided by the platform and the right way of dealing
> > with DTs for the platform.
>
> This is the part that I too am still unhappy about. I do not want
> reference or fake or whatever device trees in the U-Boot source tree.
> We should be able to _remove_ the ones we have, that are not required,
> with doc/board/...rst explaining how to get / view one. Not adding
> more.
So this is a key point for me and the reason I completely disagree
with this approach. This proposal is working in the *exact* opposite
direction and we'll never be able to get rid of device trees from
U-Boot, even if at some point they move out of the kernel to a
'common' repo'. I'll just repeat what I've been saying since v1.
Personally I'd be way happier if we could figure out were the specific
U-Boot config nodes are needed and when are they needed. Based on
what we figure out we could, pick up the device tree from a previous
state bootloader and fix it up with our special nodes before we start
using it, using internal DTS files (compiled to .dtbos or similar)
that indeed belong in the u-boot tree.
Regards
/Ilias
>
> --
> Tom
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 17:03 ` Ilias Apalodimas
@ 2021-12-02 17:09 ` Simon Glass
2021-12-03 7:54 ` Ilias Apalodimas
2021-12-02 18:15 ` Mark Kettenis
2021-12-03 1:19 ` Andre Przywara
2 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 17:09 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Tom Rini, François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Jerry Van Baren, Linus Walleij,
Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Ilias,
On Thu, 2 Dec 2021 at 10:04, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > Hi Simon
> > >
> > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > >
> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > there are only three ways to obtain a devicetree:
> > > >
> > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > appended to U-Boot
> > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > the ELF file (also used for EFI)
> > > > - OF_BOARD - the board figures it out on its own
> > > >
> > > > The last one is currently set up so that no devicetree is needed at all
> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > don't even provide instructions on how to boot on the board.
> > > >
> > > > The problems with this approach are documented in another patch in this
> > > > series: "doc: Add documentation about devicetree usage"
> > > >
> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > caller may have a better idea about the hardware available in the machine.
> > > > This is the case with a few QEMU boards, for example.
> > > >
> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > >
> > > > This series makes this change, adding various missing devicetree files
> > > > (and placeholders) to make the build work.
> > > >
> > > > Note: If board maintainers are able to add their own patch to add the
> > > > files, some patches in this series can be dropped.
> > > >
> > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > qemu-riscv64_spl problem is fixed.
> > > >
> > > > [1]
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > >
> > > > Changes in v6:
> > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > - Expand the commit message based on comments
> > > > - Expand the commit message based on comments
> > >
> > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > not in favor of this new version either.
> > > If you make a version without « fake DTs » as you name them, there are good
> > > advances in the documentation and other areas that would be better in
> > > mainline….
> > > If I am the only one thinking this way and the patch can be accepted, I
> > > would love there is a warning in capital letters at the top of the DTS fake
> > > files that explains the intent of this fake DT, the possible outcomes of
> > > not using the one provided by the platform and the right way of dealing
> > > with DTs for the platform.
> >
> > This is the part that I too am still unhappy about. I do not want
> > reference or fake or whatever device trees in the U-Boot source tree.
> > We should be able to _remove_ the ones we have, that are not required,
> > with doc/board/...rst explaining how to get / view one. Not adding
> > more.
>
> So this is a key point for me and the reason I completely disagree
> with this approach. This proposal is working in the *exact* opposite
> direction and we'll never be able to get rid of device trees from
> U-Boot, even if at some point they move out of the kernel to a
> 'common' repo'. I'll just repeat what I've been saying since v1.
> Personally I'd be way happier if we could figure out were the specific
> U-Boot config nodes are needed and when are they needed. Based on
> what we figure out we could, pick up the device tree from a previous
> state bootloader and fix it up with our special nodes before we start
> using it, using internal DTS files (compiled to .dtbos or similar)
> that indeed belong in the u-boot tree.
Eh? If the device tree files are actually common then there should be
a single source. If U-Boot has a copy then it should be identical.
The special node thing makes no sense for U-Boot. We just need to
upstream our bindings and I am working on that.
Are the device tree files moving out of Linux?
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 17:09 ` Simon Glass
@ 2021-12-03 7:54 ` Ilias Apalodimas
0 siblings, 0 replies; 136+ messages in thread
From: Ilias Apalodimas @ 2021-12-03 7:54 UTC (permalink / raw)
To: Simon Glass
Cc: Tom Rini, François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Jerry Van Baren, Linus Walleij,
Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Simon,
> > > > >
[...]
> > > > > Changes in v6:
> > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > - Expand the commit message based on comments
> > > > > - Expand the commit message based on comments
> > > >
> > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > not in favor of this new version either.
> > > > If you make a version without « fake DTs » as you name them, there are good
> > > > advances in the documentation and other areas that would be better in
> > > > mainline….
> > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > not using the one provided by the platform and the right way of dealing
> > > > with DTs for the platform.
> > >
> > > This is the part that I too am still unhappy about. I do not want
> > > reference or fake or whatever device trees in the U-Boot source tree.
> > > We should be able to _remove_ the ones we have, that are not required,
> > > with doc/board/...rst explaining how to get / view one. Not adding
> > > more.
> >
> > So this is a key point for me and the reason I completely disagree
> > with this approach. This proposal is working in the *exact* opposite
> > direction and we'll never be able to get rid of device trees from
> > U-Boot, even if at some point they move out of the kernel to a
> > 'common' repo'. I'll just repeat what I've been saying since v1.
> > Personally I'd be way happier if we could figure out were the specific
> > U-Boot config nodes are needed and when are they needed. Based on
> > what we figure out we could, pick up the device tree from a previous
> > state bootloader and fix it up with our special nodes before we start
> > using it, using internal DTS files (compiled to .dtbos or similar)
> > that indeed belong in the u-boot tree.
>
> Eh? If the device tree files are actually common then there should be
> a single source. If U-Boot has a copy then it should be identical.
>
> The special node thing makes no sense for U-Boot. We just need to
> upstream our bindings and I am working on that.
Yea we discussed this on v5. If the device bindings are upstreamed things
gets substantially easier. But that's a big if.
>
> Are the device tree files moving out of Linux?
There was an effort from Linaro and iirc we tried to move a few and see
how things would work out, but there's nothing official.
Regards
/Ilias
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 17:03 ` Ilias Apalodimas
2021-12-02 17:09 ` Simon Glass
@ 2021-12-02 18:15 ` Mark Kettenis
2021-12-02 18:21 ` Simon Glass
` (2 more replies)
2021-12-03 1:19 ` Andre Przywara
2 siblings, 3 replies; 136+ messages in thread
From: Mark Kettenis @ 2021-12-02 18:15 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: trini, francois.ozog, sjg, awilliams, albert.u.boot, agraf,
anastasiia_lukianenko, andre.przywara, bmeng.cn, xypron.glpk,
vanbaren, linus.walleij, mbrugger, michal.simek,
oleksandr_andrushchenko, peter.maydell, seanga2, swarren,
swarren, fitzsim, tuomas.tynkkynen, u-boot
> From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Date: Thu, 2 Dec 2021 19:03:46 +0200
>
> On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > Hi Simon
> > >
> > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > >
> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > there are only three ways to obtain a devicetree:
> > > >
> > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > appended to U-Boot
> > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > the ELF file (also used for EFI)
> > > > - OF_BOARD - the board figures it out on its own
> > > >
> > > > The last one is currently set up so that no devicetree is needed at all
> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > don't even provide instructions on how to boot on the board.
> > > >
> > > > The problems with this approach are documented in another patch in this
> > > > series: "doc: Add documentation about devicetree usage"
> > > >
> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > caller may have a better idea about the hardware available in the machine.
> > > > This is the case with a few QEMU boards, for example.
> > > >
> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > >
> > > > This series makes this change, adding various missing devicetree files
> > > > (and placeholders) to make the build work.
> > > >
> > > > Note: If board maintainers are able to add their own patch to add the
> > > > files, some patches in this series can be dropped.
> > > >
> > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > qemu-riscv64_spl problem is fixed.
> > > >
> > > > [1]
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > >
> > > > Changes in v6:
> > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > - Expand the commit message based on comments
> > > > - Expand the commit message based on comments
> > >
> > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > not in favor of this new version either.
> > > If you make a version without « fake DTs » as you name them, there are good
> > > advances in the documentation and other areas that would be better in
> > > mainline….
> > > If I am the only one thinking this way and the patch can be accepted, I
> > > would love there is a warning in capital letters at the top of the DTS fake
> > > files that explains the intent of this fake DT, the possible outcomes of
> > > not using the one provided by the platform and the right way of dealing
> > > with DTs for the platform.
> >
> > This is the part that I too am still unhappy about. I do not want
> > reference or fake or whatever device trees in the U-Boot source tree.
> > We should be able to _remove_ the ones we have, that are not required,
> > with doc/board/...rst explaining how to get / view one. Not adding
> > more.
>
> So this is a key point for me and the reason I completely disagree
> with this approach. This proposal is working in the *exact* opposite
> direction and we'll never be able to get rid of device trees from
> U-Boot, even if at some point they move out of the kernel to a
> 'common' repo'. I'll just repeat what I've been saying since v1.
> Personally I'd be way happier if we could figure out were the specific
> U-Boot config nodes are needed and when are they needed. Based on
> what we figure out we could, pick up the device tree from a previous
> state bootloader and fix it up with our special nodes before we start
> using it, using internal DTS files (compiled to .dtbos or similar)
> that indeed belong in the u-boot tree.
I don't think it makes sense to put stuff in the DT that is specific
for U-Boot only to pull it out moments later. Maybe it does make some
sense to do this to pass information between TPL/SPL and U-Boot
proper. But otherwise you can just use global variables...
Now I just ran into an issue on Apple M1 that may have some relevance
here. I'm adding support for power domains and the serial port
requires certain power domains to be on. Since the serial port is
initialized in the pre-relocation phase this means that the device
tree nodes for the power domain controllers need to have the
"u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't
be able to bind the power domain controller driver in this phase and
binding the serial port driver itself will fail. Which makes U-Boot
hang without any visible output on the serial console.
Within the Asahi Linux group we're currently discussing how to solve
this. We could just add the "u-boot,dm-pre-reloc" properties in the
device trees that we're going to distribute as part of m1n1 (the
"bootloader" than embeds U-Boot). Or we can write some code that adds
those properties to the device tree nodes that are dependencies for
the serial port.
I don't think the suggestion of applying an overlay embedded in U-Boot
would work here. The code applying the overlay would need to run very
early on in the pre-relocation phase. We'd also have to include
overlays for all the models that Apple offers and pick the right one.
And if a new model appears we can no longer just add a new device tree
to m1n1.
But maybe there is a case where the overlay approach would make sense...
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 18:15 ` Mark Kettenis
@ 2021-12-02 18:21 ` Simon Glass
2021-12-02 18:38 ` Tom Rini
2021-12-02 18:47 ` Mark Kettenis
2021-12-02 18:32 ` François Ozog
2021-12-03 7:50 ` Ilias Apalodimas
2 siblings, 2 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 18:21 UTC (permalink / raw)
To: Mark Kettenis
Cc: Ilias Apalodimas, trini, francois.ozog, awilliams, albert.u.boot,
agraf, Anastasiia_Lukianenko, andre.przywara, bmeng.cn,
xypron.glpk, vanbaren, linus.walleij, mbrugger, michal.simek,
Oleksandr_Andrushchenko, peter.maydell, seanga2, swarren,
swarren, fitzsim, tuomas.tynkkynen, u-boot
Hi Mark,
On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > Date: Thu, 2 Dec 2021 19:03:46 +0200
> >
> > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > Hi Simon
> > > >
> > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > >
> > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > there are only three ways to obtain a devicetree:
> > > > >
> > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > appended to U-Boot
> > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > the ELF file (also used for EFI)
> > > > > - OF_BOARD - the board figures it out on its own
> > > > >
> > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > don't even provide instructions on how to boot on the board.
> > > > >
> > > > > The problems with this approach are documented in another patch in this
> > > > > series: "doc: Add documentation about devicetree usage"
> > > > >
> > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > caller may have a better idea about the hardware available in the machine.
> > > > > This is the case with a few QEMU boards, for example.
> > > > >
> > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > >
> > > > > This series makes this change, adding various missing devicetree files
> > > > > (and placeholders) to make the build work.
> > > > >
> > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > files, some patches in this series can be dropped.
> > > > >
> > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > qemu-riscv64_spl problem is fixed.
> > > > >
> > > > > [1]
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > >
> > > > > Changes in v6:
> > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > - Expand the commit message based on comments
> > > > > - Expand the commit message based on comments
> > > >
> > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > not in favor of this new version either.
> > > > If you make a version without « fake DTs » as you name them, there are good
> > > > advances in the documentation and other areas that would be better in
> > > > mainline….
> > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > not using the one provided by the platform and the right way of dealing
> > > > with DTs for the platform.
> > >
> > > This is the part that I too am still unhappy about. I do not want
> > > reference or fake or whatever device trees in the U-Boot source tree.
> > > We should be able to _remove_ the ones we have, that are not required,
> > > with doc/board/...rst explaining how to get / view one. Not adding
> > > more.
> >
> > So this is a key point for me and the reason I completely disagree
> > with this approach. This proposal is working in the *exact* opposite
> > direction and we'll never be able to get rid of device trees from
> > U-Boot, even if at some point they move out of the kernel to a
> > 'common' repo'. I'll just repeat what I've been saying since v1.
> > Personally I'd be way happier if we could figure out were the specific
> > U-Boot config nodes are needed and when are they needed. Based on
> > what we figure out we could, pick up the device tree from a previous
> > state bootloader and fix it up with our special nodes before we start
> > using it, using internal DTS files (compiled to .dtbos or similar)
> > that indeed belong in the u-boot tree.
>
> I don't think it makes sense to put stuff in the DT that is specific
> for U-Boot only to pull it out moments later. Maybe it does make some
> sense to do this to pass information between TPL/SPL and U-Boot
> proper. But otherwise you can just use global variables...
>
> Now I just ran into an issue on Apple M1 that may have some relevance
> here. I'm adding support for power domains and the serial port
> requires certain power domains to be on. Since the serial port is
> initialized in the pre-relocation phase this means that the device
> tree nodes for the power domain controllers need to have the
> "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't
> be able to bind the power domain controller driver in this phase and
> binding the serial port driver itself will fail. Which makes U-Boot
> hang without any visible output on the serial console.
>
> Within the Asahi Linux group we're currently discussing how to solve
> this. We could just add the "u-boot,dm-pre-reloc" properties in the
> device trees that we're going to distribute as part of m1n1 (the
> "bootloader" than embeds U-Boot). Or we can write some code that adds
> those properties to the device tree nodes that are dependencies for
> the serial port.
>
> I don't think the suggestion of applying an overlay embedded in U-Boot
> would work here. The code applying the overlay would need to run very
> early on in the pre-relocation phase. We'd also have to include
> overlays for all the models that Apple offers and pick the right one.
> And if a new model appears we can no longer just add a new device tree
> to m1n1.
Well put.
>
> But maybe there is a case where the overlay approach would make sense...
There might be, but I haven't found it yet.
BTW I suggest we figure out how to upstream the binding for this. I
will see if I can send a patch to start the process. The last patch
didn't get any comments though.
In the interim there is probably no choice but to add the properties
into the m1n1 project. Of course, for development, you could just turn
off OF_BOARD, with my series applied. Which is a lot of the point of
all of this discussion...
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 18:21 ` Simon Glass
@ 2021-12-02 18:38 ` Tom Rini
2021-12-02 18:47 ` Mark Kettenis
1 sibling, 0 replies; 136+ messages in thread
From: Tom Rini @ 2021-12-02 18:38 UTC (permalink / raw)
To: Simon Glass
Cc: Mark Kettenis, Ilias Apalodimas, francois.ozog, awilliams,
albert.u.boot, agraf, Anastasiia_Lukianenko, andre.przywara,
bmeng.cn, xypron.glpk, vanbaren, linus.walleij, mbrugger,
michal.simek, Oleksandr_Andrushchenko, peter.maydell, seanga2,
swarren, swarren, fitzsim, tuomas.tynkkynen, u-boot
[-- Attachment #1: Type: text/plain, Size: 7056 bytes --]
On Thu, Dec 02, 2021 at 11:21:22AM -0700, Simon Glass wrote:
> Hi Mark,
>
> On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >
> > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > Date: Thu, 2 Dec 2021 19:03:46 +0200
> > >
> > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > Hi Simon
> > > > >
> > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > >
> > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > there are only three ways to obtain a devicetree:
> > > > > >
> > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > appended to U-Boot
> > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > the ELF file (also used for EFI)
> > > > > > - OF_BOARD - the board figures it out on its own
> > > > > >
> > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > don't even provide instructions on how to boot on the board.
> > > > > >
> > > > > > The problems with this approach are documented in another patch in this
> > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > >
> > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > This is the case with a few QEMU boards, for example.
> > > > > >
> > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > >
> > > > > > This series makes this change, adding various missing devicetree files
> > > > > > (and placeholders) to make the build work.
> > > > > >
> > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > files, some patches in this series can be dropped.
> > > > > >
> > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > qemu-riscv64_spl problem is fixed.
> > > > > >
> > > > > > [1]
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > >
> > > > > > Changes in v6:
> > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > - Expand the commit message based on comments
> > > > > > - Expand the commit message based on comments
> > > > >
> > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > not in favor of this new version either.
> > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > advances in the documentation and other areas that would be better in
> > > > > mainline….
> > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > not using the one provided by the platform and the right way of dealing
> > > > > with DTs for the platform.
> > > >
> > > > This is the part that I too am still unhappy about. I do not want
> > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > We should be able to _remove_ the ones we have, that are not required,
> > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > more.
> > >
> > > So this is a key point for me and the reason I completely disagree
> > > with this approach. This proposal is working in the *exact* opposite
> > > direction and we'll never be able to get rid of device trees from
> > > U-Boot, even if at some point they move out of the kernel to a
> > > 'common' repo'. I'll just repeat what I've been saying since v1.
> > > Personally I'd be way happier if we could figure out were the specific
> > > U-Boot config nodes are needed and when are they needed. Based on
> > > what we figure out we could, pick up the device tree from a previous
> > > state bootloader and fix it up with our special nodes before we start
> > > using it, using internal DTS files (compiled to .dtbos or similar)
> > > that indeed belong in the u-boot tree.
> >
> > I don't think it makes sense to put stuff in the DT that is specific
> > for U-Boot only to pull it out moments later. Maybe it does make some
> > sense to do this to pass information between TPL/SPL and U-Boot
> > proper. But otherwise you can just use global variables...
> >
> > Now I just ran into an issue on Apple M1 that may have some relevance
> > here. I'm adding support for power domains and the serial port
> > requires certain power domains to be on. Since the serial port is
> > initialized in the pre-relocation phase this means that the device
> > tree nodes for the power domain controllers need to have the
> > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't
> > be able to bind the power domain controller driver in this phase and
> > binding the serial port driver itself will fail. Which makes U-Boot
> > hang without any visible output on the serial console.
> >
> > Within the Asahi Linux group we're currently discussing how to solve
> > this. We could just add the "u-boot,dm-pre-reloc" properties in the
> > device trees that we're going to distribute as part of m1n1 (the
> > "bootloader" than embeds U-Boot). Or we can write some code that adds
> > those properties to the device tree nodes that are dependencies for
> > the serial port.
> >
> > I don't think the suggestion of applying an overlay embedded in U-Boot
> > would work here. The code applying the overlay would need to run very
> > early on in the pre-relocation phase. We'd also have to include
> > overlays for all the models that Apple offers and pick the right one.
> > And if a new model appears we can no longer just add a new device tree
> > to m1n1.
>
> Well put.
>
> >
> > But maybe there is a case where the overlay approach would make sense...
>
> There might be, but I haven't found it yet.
>
> BTW I suggest we figure out how to upstream the binding for this. I
> will see if I can send a patch to start the process. The last patch
> didn't get any comments though.
Yes, it's probably time to submit and defend some of the more
non-trivial properties such as "u-boot,dm-pre-reloc" which I think
starts to get at the heart of our issues.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 18:21 ` Simon Glass
2021-12-02 18:38 ` Tom Rini
@ 2021-12-02 18:47 ` Mark Kettenis
2021-12-02 18:53 ` Simon Glass
1 sibling, 1 reply; 136+ messages in thread
From: Mark Kettenis @ 2021-12-02 18:47 UTC (permalink / raw)
To: Simon Glass
Cc: ilias.apalodimas, trini, francois.ozog, awilliams, albert.u.boot,
agraf, Anastasiia_Lukianenko, andre.przywara, bmeng.cn,
xypron.glpk, vanbaren, linus.walleij, mbrugger, michal.simek,
Oleksandr_Andrushchenko, peter.maydell, seanga2, swarren,
swarren, fitzsim, tuomas.tynkkynen, u-boot
> From: Simon Glass <sjg@chromium.org>
> Date: Thu, 2 Dec 2021 11:21:22 -0700
>
> Hi Mark,
>
> On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >
> > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > Date: Thu, 2 Dec 2021 19:03:46 +0200
> > >
> > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > Hi Simon
> > > > >
> > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > >
> > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > there are only three ways to obtain a devicetree:
> > > > > >
> > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > appended to U-Boot
> > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > the ELF file (also used for EFI)
> > > > > > - OF_BOARD - the board figures it out on its own
> > > > > >
> > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > don't even provide instructions on how to boot on the board.
> > > > > >
> > > > > > The problems with this approach are documented in another patch in this
> > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > >
> > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > This is the case with a few QEMU boards, for example.
> > > > > >
> > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > >
> > > > > > This series makes this change, adding various missing devicetree files
> > > > > > (and placeholders) to make the build work.
> > > > > >
> > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > files, some patches in this series can be dropped.
> > > > > >
> > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > qemu-riscv64_spl problem is fixed.
> > > > > >
> > > > > > [1]
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > >
> > > > > > Changes in v6:
> > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > - Expand the commit message based on comments
> > > > > > - Expand the commit message based on comments
> > > > >
> > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > not in favor of this new version either.
> > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > advances in the documentation and other areas that would be better in
> > > > > mainline….
> > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > not using the one provided by the platform and the right way of dealing
> > > > > with DTs for the platform.
> > > >
> > > > This is the part that I too am still unhappy about. I do not want
> > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > We should be able to _remove_ the ones we have, that are not required,
> > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > more.
> > >
> > > So this is a key point for me and the reason I completely disagree
> > > with this approach. This proposal is working in the *exact* opposite
> > > direction and we'll never be able to get rid of device trees from
> > > U-Boot, even if at some point they move out of the kernel to a
> > > 'common' repo'. I'll just repeat what I've been saying since v1.
> > > Personally I'd be way happier if we could figure out were the specific
> > > U-Boot config nodes are needed and when are they needed. Based on
> > > what we figure out we could, pick up the device tree from a previous
> > > state bootloader and fix it up with our special nodes before we start
> > > using it, using internal DTS files (compiled to .dtbos or similar)
> > > that indeed belong in the u-boot tree.
> >
> > I don't think it makes sense to put stuff in the DT that is specific
> > for U-Boot only to pull it out moments later. Maybe it does make some
> > sense to do this to pass information between TPL/SPL and U-Boot
> > proper. But otherwise you can just use global variables...
> >
> > Now I just ran into an issue on Apple M1 that may have some relevance
> > here. I'm adding support for power domains and the serial port
> > requires certain power domains to be on. Since the serial port is
> > initialized in the pre-relocation phase this means that the device
> > tree nodes for the power domain controllers need to have the
> > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't
> > be able to bind the power domain controller driver in this phase and
> > binding the serial port driver itself will fail. Which makes U-Boot
> > hang without any visible output on the serial console.
> >
> > Within the Asahi Linux group we're currently discussing how to solve
> > this. We could just add the "u-boot,dm-pre-reloc" properties in the
> > device trees that we're going to distribute as part of m1n1 (the
> > "bootloader" than embeds U-Boot). Or we can write some code that adds
> > those properties to the device tree nodes that are dependencies for
> > the serial port.
> >
> > I don't think the suggestion of applying an overlay embedded in U-Boot
> > would work here. The code applying the overlay would need to run very
> > early on in the pre-relocation phase. We'd also have to include
> > overlays for all the models that Apple offers and pick the right one.
> > And if a new model appears we can no longer just add a new device tree
> > to m1n1.
>
> Well put.
>
> >
> > But maybe there is a case where the overlay approach would make sense...
>
> There might be, but I haven't found it yet.
>
> BTW I suggest we figure out how to upstream the binding for this. I
> will see if I can send a patch to start the process. The last patch
> didn't get any comments though.
>
> In the interim there is probably no choice but to add the properties
> into the m1n1 project. Of course, for development, you could just turn
> off OF_BOARD, with my series applied. Which is a lot of the point of
> all of this discussion...
And that is exactly why I don't see the point of this series. There
is no chance of that working. The device tree that is currently in
the U-Boot tree (essentially because you made me add one) is only a
template that gets modified by m1n1 to account for hardware
characteristics (amount of memory, cores that are actually enabled,
MAC addresses, WiFi antenna configuration, etc. etc.). If I flip
OF_BOARD U-Boot would simply not work.
The way I do development is that I simply build a device tree, build
U-boot and upload them over serial to m1n1 running on the device. I
currently do build my device trees out of the U-Boot tree, but the
main reason for that is because the Linux development model means that
too many of the device tree patches are still in flight. I often use
the device tree from a different U-Boot repository clone than the one
I do the actual U-Boot development in anyway.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 18:47 ` Mark Kettenis
@ 2021-12-02 18:53 ` Simon Glass
2021-12-02 19:22 ` Mark Kettenis
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 18:53 UTC (permalink / raw)
To: Mark Kettenis
Cc: ilias.apalodimas, trini, francois.ozog, awilliams, albert.u.boot,
agraf, Anastasiia_Lukianenko, andre.przywara, bmeng.cn,
xypron.glpk, vanbaren, linus.walleij, mbrugger, michal.simek,
Oleksandr_Andrushchenko, peter.maydell, seanga2, swarren,
swarren, fitzsim, tuomas.tynkkynen, u-boot
Hi Mark,
On Thu, 2 Dec 2021 at 11:47, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Simon Glass <sjg@chromium.org>
> > Date: Thu, 2 Dec 2021 11:21:22 -0700
> >
> > Hi Mark,
> >
> > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > >
> > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > > Date: Thu, 2 Dec 2021 19:03:46 +0200
> > > >
> > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > Hi Simon
> > > > > >
> > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > >
> > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > there are only three ways to obtain a devicetree:
> > > > > > >
> > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > appended to U-Boot
> > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > the ELF file (also used for EFI)
> > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > >
> > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > >
> > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > >
> > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > >
> > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > >
> > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > (and placeholders) to make the build work.
> > > > > > >
> > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > files, some patches in this series can be dropped.
> > > > > > >
> > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > >
> > > > > > > [1]
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > >
> > > > > > > Changes in v6:
> > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > - Expand the commit message based on comments
> > > > > > > - Expand the commit message based on comments
> > > > > >
> > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > not in favor of this new version either.
> > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > advances in the documentation and other areas that would be better in
> > > > > > mainline….
> > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > with DTs for the platform.
> > > > >
> > > > > This is the part that I too am still unhappy about. I do not want
> > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > more.
> > > >
> > > > So this is a key point for me and the reason I completely disagree
> > > > with this approach. This proposal is working in the *exact* opposite
> > > > direction and we'll never be able to get rid of device trees from
> > > > U-Boot, even if at some point they move out of the kernel to a
> > > > 'common' repo'. I'll just repeat what I've been saying since v1.
> > > > Personally I'd be way happier if we could figure out were the specific
> > > > U-Boot config nodes are needed and when are they needed. Based on
> > > > what we figure out we could, pick up the device tree from a previous
> > > > state bootloader and fix it up with our special nodes before we start
> > > > using it, using internal DTS files (compiled to .dtbos or similar)
> > > > that indeed belong in the u-boot tree.
> > >
> > > I don't think it makes sense to put stuff in the DT that is specific
> > > for U-Boot only to pull it out moments later. Maybe it does make some
> > > sense to do this to pass information between TPL/SPL and U-Boot
> > > proper. But otherwise you can just use global variables...
> > >
> > > Now I just ran into an issue on Apple M1 that may have some relevance
> > > here. I'm adding support for power domains and the serial port
> > > requires certain power domains to be on. Since the serial port is
> > > initialized in the pre-relocation phase this means that the device
> > > tree nodes for the power domain controllers need to have the
> > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't
> > > be able to bind the power domain controller driver in this phase and
> > > binding the serial port driver itself will fail. Which makes U-Boot
> > > hang without any visible output on the serial console.
> > >
> > > Within the Asahi Linux group we're currently discussing how to solve
> > > this. We could just add the "u-boot,dm-pre-reloc" properties in the
> > > device trees that we're going to distribute as part of m1n1 (the
> > > "bootloader" than embeds U-Boot). Or we can write some code that adds
> > > those properties to the device tree nodes that are dependencies for
> > > the serial port.
> > >
> > > I don't think the suggestion of applying an overlay embedded in U-Boot
> > > would work here. The code applying the overlay would need to run very
> > > early on in the pre-relocation phase. We'd also have to include
> > > overlays for all the models that Apple offers and pick the right one.
> > > And if a new model appears we can no longer just add a new device tree
> > > to m1n1.
> >
> > Well put.
> >
> > >
> > > But maybe there is a case where the overlay approach would make sense...
> >
> > There might be, but I haven't found it yet.
> >
> > BTW I suggest we figure out how to upstream the binding for this. I
> > will see if I can send a patch to start the process. The last patch
> > didn't get any comments though.
> >
> > In the interim there is probably no choice but to add the properties
> > into the m1n1 project. Of course, for development, you could just turn
> > off OF_BOARD, with my series applied. Which is a lot of the point of
> > all of this discussion...
>
> And that is exactly why I don't see the point of this series. There
> is no chance of that working. The device tree that is currently in
> the U-Boot tree (essentially because you made me add one) is only a
> template that gets modified by m1n1 to account for hardware
> characteristics (amount of memory, cores that are actually enabled,
> MAC addresses, WiFi antenna configuration, etc. etc.). If I flip
> OF_BOARD U-Boot would simply not work.
>
> The way I do development is that I simply build a device tree, build
> U-boot and upload them over serial to m1n1 running on the device. I
> currently do build my device trees out of the U-Boot tree, but the
> main reason for that is because the Linux development model means that
> too many of the device tree patches are still in flight. I often use
> the device tree from a different U-Boot repository clone than the one
> I do the actual U-Boot development in anyway.
Yes and I think you have made my point. That is all I am saying. I am
not claiming that U-Boot needs to be the golden repo for the .dts,
just that it should have something suitable that works well enough for
development, and can be modified and updated as development
progresses.
Regards,
SImon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 18:53 ` Simon Glass
@ 2021-12-02 19:22 ` Mark Kettenis
2021-12-02 19:24 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Mark Kettenis @ 2021-12-02 19:22 UTC (permalink / raw)
To: Simon Glass
Cc: ilias.apalodimas, trini, francois.ozog, awilliams, albert.u.boot,
agraf, Anastasiia_Lukianenko, andre.przywara, bmeng.cn,
xypron.glpk, vanbaren, linus.walleij, mbrugger, michal.simek,
Oleksandr_Andrushchenko, peter.maydell, seanga2, swarren,
swarren, fitzsim, tuomas.tynkkynen, u-boot
> From: Simon Glass <sjg@chromium.org>
> Date: Thu, 2 Dec 2021 11:53:53 -0700
>
> Hi Mark,
>
> On Thu, 2 Dec 2021 at 11:47, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >
> > > From: Simon Glass <sjg@chromium.org>
> > > Date: Thu, 2 Dec 2021 11:21:22 -0700
> > >
> > > Hi Mark,
> > >
> > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > >
> > > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200
> > > > >
> > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > Hi Simon
> > > > > > >
> > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > > >
> > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > >
> > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > > appended to U-Boot
> > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > > the ELF file (also used for EFI)
> > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > >
> > > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > > >
> > > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > >
> > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > >
> > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > >
> > > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > > (and placeholders) to make the build work.
> > > > > > > >
> > > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > > files, some patches in this series can be dropped.
> > > > > > > >
> > > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > >
> > > > > > > > [1]
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > >
> > > > > > > > Changes in v6:
> > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > - Expand the commit message based on comments
> > > > > > > > - Expand the commit message based on comments
> > > > > > >
> > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > not in favor of this new version either.
> > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > mainline….
> > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > with DTs for the platform.
> > > > > >
> > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > more.
> > > > >
> > > > > So this is a key point for me and the reason I completely disagree
> > > > > with this approach. This proposal is working in the *exact* opposite
> > > > > direction and we'll never be able to get rid of device trees from
> > > > > U-Boot, even if at some point they move out of the kernel to a
> > > > > 'common' repo'. I'll just repeat what I've been saying since v1.
> > > > > Personally I'd be way happier if we could figure out were the specific
> > > > > U-Boot config nodes are needed and when are they needed. Based on
> > > > > what we figure out we could, pick up the device tree from a previous
> > > > > state bootloader and fix it up with our special nodes before we start
> > > > > using it, using internal DTS files (compiled to .dtbos or similar)
> > > > > that indeed belong in the u-boot tree.
> > > >
> > > > I don't think it makes sense to put stuff in the DT that is specific
> > > > for U-Boot only to pull it out moments later. Maybe it does make some
> > > > sense to do this to pass information between TPL/SPL and U-Boot
> > > > proper. But otherwise you can just use global variables...
> > > >
> > > > Now I just ran into an issue on Apple M1 that may have some relevance
> > > > here. I'm adding support for power domains and the serial port
> > > > requires certain power domains to be on. Since the serial port is
> > > > initialized in the pre-relocation phase this means that the device
> > > > tree nodes for the power domain controllers need to have the
> > > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't
> > > > be able to bind the power domain controller driver in this phase and
> > > > binding the serial port driver itself will fail. Which makes U-Boot
> > > > hang without any visible output on the serial console.
> > > >
> > > > Within the Asahi Linux group we're currently discussing how to solve
> > > > this. We could just add the "u-boot,dm-pre-reloc" properties in the
> > > > device trees that we're going to distribute as part of m1n1 (the
> > > > "bootloader" than embeds U-Boot). Or we can write some code that adds
> > > > those properties to the device tree nodes that are dependencies for
> > > > the serial port.
> > > >
> > > > I don't think the suggestion of applying an overlay embedded in U-Boot
> > > > would work here. The code applying the overlay would need to run very
> > > > early on in the pre-relocation phase. We'd also have to include
> > > > overlays for all the models that Apple offers and pick the right one.
> > > > And if a new model appears we can no longer just add a new device tree
> > > > to m1n1.
> > >
> > > Well put.
> > >
> > > >
> > > > But maybe there is a case where the overlay approach would make sense...
> > >
> > > There might be, but I haven't found it yet.
> > >
> > > BTW I suggest we figure out how to upstream the binding for this. I
> > > will see if I can send a patch to start the process. The last patch
> > > didn't get any comments though.
> > >
> > > In the interim there is probably no choice but to add the properties
> > > into the m1n1 project. Of course, for development, you could just turn
> > > off OF_BOARD, with my series applied. Which is a lot of the point of
> > > all of this discussion...
> >
> > And that is exactly why I don't see the point of this series. There
> > is no chance of that working. The device tree that is currently in
> > the U-Boot tree (essentially because you made me add one) is only a
> > template that gets modified by m1n1 to account for hardware
> > characteristics (amount of memory, cores that are actually enabled,
> > MAC addresses, WiFi antenna configuration, etc. etc.). If I flip
> > OF_BOARD U-Boot would simply not work.
> >
> > The way I do development is that I simply build a device tree, build
> > U-boot and upload them over serial to m1n1 running on the device. I
> > currently do build my device trees out of the U-Boot tree, but the
> > main reason for that is because the Linux development model means that
> > too many of the device tree patches are still in flight. I often use
> > the device tree from a different U-Boot repository clone than the one
> > I do the actual U-Boot development in anyway.
>
> Yes and I think you have made my point. That is all I am saying. I am
> not claiming that U-Boot needs to be the golden repo for the .dts,
> just that it should have something suitable that works well enough for
> development, and can be modified and updated as development
> progresses.
No you are missing my point. I'm only doing it this way because the
Linux development model is so broken that it takes months for patches
posted on the mailing list to end up in a somewhat official source
tree and I would go bat-shit crazy having to deal with all the merges
and rebasing going on.
If there was a separate device tree project, I would very much prefer
to use that and make device tree changes there such that I could
submit any additions to the canonical sources. I'm currently spending
too much of my development time synching the device trees in my U-Boot
tree with what's going on on the Linux side.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 19:22 ` Mark Kettenis
@ 2021-12-02 19:24 ` Simon Glass
2021-12-02 21:53 ` Tom Rini
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 19:24 UTC (permalink / raw)
To: Mark Kettenis
Cc: ilias.apalodimas, trini, francois.ozog, awilliams, albert.u.boot,
agraf, Anastasiia_Lukianenko, andre.przywara, bmeng.cn,
xypron.glpk, vanbaren, linus.walleij, mbrugger, michal.simek,
Oleksandr_Andrushchenko, peter.maydell, seanga2, swarren,
swarren, fitzsim, tuomas.tynkkynen, u-boot
Hi Mark,
On Thu, 2 Dec 2021 at 12:22, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Simon Glass <sjg@chromium.org>
> > Date: Thu, 2 Dec 2021 11:53:53 -0700
> >
> > Hi Mark,
> >
> > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > >
> > > > From: Simon Glass <sjg@chromium.org>
> > > > Date: Thu, 2 Dec 2021 11:21:22 -0700
> > > >
> > > > Hi Mark,
> > > >
> > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > >
> > > > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200
> > > > > >
> > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > > Hi Simon
> > > > > > > >
> > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > > > >
> > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > > >
> > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > > > appended to U-Boot
> > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > > > the ELF file (also used for EFI)
> > > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > > >
> > > > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > > > >
> > > > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > > >
> > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > > >
> > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > > >
> > > > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > > > (and placeholders) to make the build work.
> > > > > > > > >
> > > > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > > > files, some patches in this series can be dropped.
> > > > > > > > >
> > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > > >
> > > > > > > > > [1]
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > Changes in v6:
> > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > - Expand the commit message based on comments
> > > > > > > >
> > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > > not in favor of this new version either.
> > > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > > mainline….
> > > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > > with DTs for the platform.
> > > > > > >
> > > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > > more.
> > > > > >
> > > > > > So this is a key point for me and the reason I completely disagree
> > > > > > with this approach. This proposal is working in the *exact* opposite
> > > > > > direction and we'll never be able to get rid of device trees from
> > > > > > U-Boot, even if at some point they move out of the kernel to a
> > > > > > 'common' repo'. I'll just repeat what I've been saying since v1.
> > > > > > Personally I'd be way happier if we could figure out were the specific
> > > > > > U-Boot config nodes are needed and when are they needed. Based on
> > > > > > what we figure out we could, pick up the device tree from a previous
> > > > > > state bootloader and fix it up with our special nodes before we start
> > > > > > using it, using internal DTS files (compiled to .dtbos or similar)
> > > > > > that indeed belong in the u-boot tree.
> > > > >
> > > > > I don't think it makes sense to put stuff in the DT that is specific
> > > > > for U-Boot only to pull it out moments later. Maybe it does make some
> > > > > sense to do this to pass information between TPL/SPL and U-Boot
> > > > > proper. But otherwise you can just use global variables...
> > > > >
> > > > > Now I just ran into an issue on Apple M1 that may have some relevance
> > > > > here. I'm adding support for power domains and the serial port
> > > > > requires certain power domains to be on. Since the serial port is
> > > > > initialized in the pre-relocation phase this means that the device
> > > > > tree nodes for the power domain controllers need to have the
> > > > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't
> > > > > be able to bind the power domain controller driver in this phase and
> > > > > binding the serial port driver itself will fail. Which makes U-Boot
> > > > > hang without any visible output on the serial console.
> > > > >
> > > > > Within the Asahi Linux group we're currently discussing how to solve
> > > > > this. We could just add the "u-boot,dm-pre-reloc" properties in the
> > > > > device trees that we're going to distribute as part of m1n1 (the
> > > > > "bootloader" than embeds U-Boot). Or we can write some code that adds
> > > > > those properties to the device tree nodes that are dependencies for
> > > > > the serial port.
> > > > >
> > > > > I don't think the suggestion of applying an overlay embedded in U-Boot
> > > > > would work here. The code applying the overlay would need to run very
> > > > > early on in the pre-relocation phase. We'd also have to include
> > > > > overlays for all the models that Apple offers and pick the right one.
> > > > > And if a new model appears we can no longer just add a new device tree
> > > > > to m1n1.
> > > >
> > > > Well put.
> > > >
> > > > >
> > > > > But maybe there is a case where the overlay approach would make sense...
> > > >
> > > > There might be, but I haven't found it yet.
> > > >
> > > > BTW I suggest we figure out how to upstream the binding for this. I
> > > > will see if I can send a patch to start the process. The last patch
> > > > didn't get any comments though.
> > > >
> > > > In the interim there is probably no choice but to add the properties
> > > > into the m1n1 project. Of course, for development, you could just turn
> > > > off OF_BOARD, with my series applied. Which is a lot of the point of
> > > > all of this discussion...
> > >
> > > And that is exactly why I don't see the point of this series. There
> > > is no chance of that working. The device tree that is currently in
> > > the U-Boot tree (essentially because you made me add one) is only a
> > > template that gets modified by m1n1 to account for hardware
> > > characteristics (amount of memory, cores that are actually enabled,
> > > MAC addresses, WiFi antenna configuration, etc. etc.). If I flip
> > > OF_BOARD U-Boot would simply not work.
> > >
> > > The way I do development is that I simply build a device tree, build
> > > U-boot and upload them over serial to m1n1 running on the device. I
> > > currently do build my device trees out of the U-Boot tree, but the
> > > main reason for that is because the Linux development model means that
> > > too many of the device tree patches are still in flight. I often use
> > > the device tree from a different U-Boot repository clone than the one
> > > I do the actual U-Boot development in anyway.
> >
> > Yes and I think you have made my point. That is all I am saying. I am
> > not claiming that U-Boot needs to be the golden repo for the .dts,
> > just that it should have something suitable that works well enough for
> > development, and can be modified and updated as development
> > progresses.
>
> No you are missing my point. I'm only doing it this way because the
> Linux development model is so broken that it takes months for patches
> posted on the mailing list to end up in a somewhat official source
> tree and I would go bat-shit crazy having to deal with all the merges
> and rebasing going on.
>
> If there was a separate device tree project, I would very much prefer
> to use that and make device tree changes there such that I could
> submit any additions to the canonical sources. I'm currently spending
> too much of my development time synching the device trees in my U-Boot
> tree with what's going on on the Linux side.
Right, exactly. I have exactly the same problem and so do other people
working with U-Boot. At least we have a work-around.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 19:24 ` Simon Glass
@ 2021-12-02 21:53 ` Tom Rini
2021-12-02 22:42 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-02 21:53 UTC (permalink / raw)
To: Simon Glass
Cc: Mark Kettenis, ilias.apalodimas, francois.ozog, awilliams,
albert.u.boot, agraf, Anastasiia_Lukianenko, andre.przywara,
bmeng.cn, xypron.glpk, vanbaren, linus.walleij, mbrugger,
michal.simek, Oleksandr_Andrushchenko, peter.maydell, seanga2,
swarren, swarren, fitzsim, tuomas.tynkkynen, u-boot
[-- Attachment #1: Type: text/plain, Size: 11241 bytes --]
On Thu, Dec 02, 2021 at 12:24:24PM -0700, Simon Glass wrote:
> Hi Mark,
>
> On Thu, 2 Dec 2021 at 12:22, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >
> > > From: Simon Glass <sjg@chromium.org>
> > > Date: Thu, 2 Dec 2021 11:53:53 -0700
> > >
> > > Hi Mark,
> > >
> > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > >
> > > > > From: Simon Glass <sjg@chromium.org>
> > > > > Date: Thu, 2 Dec 2021 11:21:22 -0700
> > > > >
> > > > > Hi Mark,
> > > > >
> > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > > >
> > > > > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200
> > > > > > >
> > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > > > Hi Simon
> > > > > > > > >
> > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > > > > >
> > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > > > >
> > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > > > > appended to U-Boot
> > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > > > > the ELF file (also used for EFI)
> > > > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > > > >
> > > > > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > > > > >
> > > > > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > > > >
> > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > > > >
> > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > > > >
> > > > > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > > > > (and placeholders) to make the build work.
> > > > > > > > > >
> > > > > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > > > > files, some patches in this series can be dropped.
> > > > > > > > > >
> > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > > > >
> > > > > > > > > > [1]
> > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > >
> > > > > > > > > > Changes in v6:
> > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > >
> > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > > > not in favor of this new version either.
> > > > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > > > mainline….
> > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > > > with DTs for the platform.
> > > > > > > >
> > > > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > > > more.
> > > > > > >
> > > > > > > So this is a key point for me and the reason I completely disagree
> > > > > > > with this approach. This proposal is working in the *exact* opposite
> > > > > > > direction and we'll never be able to get rid of device trees from
> > > > > > > U-Boot, even if at some point they move out of the kernel to a
> > > > > > > 'common' repo'. I'll just repeat what I've been saying since v1.
> > > > > > > Personally I'd be way happier if we could figure out were the specific
> > > > > > > U-Boot config nodes are needed and when are they needed. Based on
> > > > > > > what we figure out we could, pick up the device tree from a previous
> > > > > > > state bootloader and fix it up with our special nodes before we start
> > > > > > > using it, using internal DTS files (compiled to .dtbos or similar)
> > > > > > > that indeed belong in the u-boot tree.
> > > > > >
> > > > > > I don't think it makes sense to put stuff in the DT that is specific
> > > > > > for U-Boot only to pull it out moments later. Maybe it does make some
> > > > > > sense to do this to pass information between TPL/SPL and U-Boot
> > > > > > proper. But otherwise you can just use global variables...
> > > > > >
> > > > > > Now I just ran into an issue on Apple M1 that may have some relevance
> > > > > > here. I'm adding support for power domains and the serial port
> > > > > > requires certain power domains to be on. Since the serial port is
> > > > > > initialized in the pre-relocation phase this means that the device
> > > > > > tree nodes for the power domain controllers need to have the
> > > > > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't
> > > > > > be able to bind the power domain controller driver in this phase and
> > > > > > binding the serial port driver itself will fail. Which makes U-Boot
> > > > > > hang without any visible output on the serial console.
> > > > > >
> > > > > > Within the Asahi Linux group we're currently discussing how to solve
> > > > > > this. We could just add the "u-boot,dm-pre-reloc" properties in the
> > > > > > device trees that we're going to distribute as part of m1n1 (the
> > > > > > "bootloader" than embeds U-Boot). Or we can write some code that adds
> > > > > > those properties to the device tree nodes that are dependencies for
> > > > > > the serial port.
> > > > > >
> > > > > > I don't think the suggestion of applying an overlay embedded in U-Boot
> > > > > > would work here. The code applying the overlay would need to run very
> > > > > > early on in the pre-relocation phase. We'd also have to include
> > > > > > overlays for all the models that Apple offers and pick the right one.
> > > > > > And if a new model appears we can no longer just add a new device tree
> > > > > > to m1n1.
> > > > >
> > > > > Well put.
> > > > >
> > > > > >
> > > > > > But maybe there is a case where the overlay approach would make sense...
> > > > >
> > > > > There might be, but I haven't found it yet.
> > > > >
> > > > > BTW I suggest we figure out how to upstream the binding for this. I
> > > > > will see if I can send a patch to start the process. The last patch
> > > > > didn't get any comments though.
> > > > >
> > > > > In the interim there is probably no choice but to add the properties
> > > > > into the m1n1 project. Of course, for development, you could just turn
> > > > > off OF_BOARD, with my series applied. Which is a lot of the point of
> > > > > all of this discussion...
> > > >
> > > > And that is exactly why I don't see the point of this series. There
> > > > is no chance of that working. The device tree that is currently in
> > > > the U-Boot tree (essentially because you made me add one) is only a
> > > > template that gets modified by m1n1 to account for hardware
> > > > characteristics (amount of memory, cores that are actually enabled,
> > > > MAC addresses, WiFi antenna configuration, etc. etc.). If I flip
> > > > OF_BOARD U-Boot would simply not work.
I read this as Mark saying he builds the dtb file for U-Boot as well as
Linux out of tree, and feeds those two files to m1n1. m1n1 is
responsible for taking the dtb and adjusting as needed, and handing
along to U-Boot.
> > > > The way I do development is that I simply build a device tree, build
> > > > U-boot and upload them over serial to m1n1 running on the device. I
> > > > currently do build my device trees out of the U-Boot tree, but the
> > > > main reason for that is because the Linux development model means that
> > > > too many of the device tree patches are still in flight. I often use
> > > > the device tree from a different U-Boot repository clone than the one
> > > > I do the actual U-Boot development in anyway.
> > >
> > > Yes and I think you have made my point. That is all I am saying. I am
> > > not claiming that U-Boot needs to be the golden repo for the .dts,
> > > just that it should have something suitable that works well enough for
> > > development, and can be modified and updated as development
> > > progresses.
> >
> > No you are missing my point. I'm only doing it this way because the
> > Linux development model is so broken that it takes months for patches
> > posted on the mailing list to end up in a somewhat official source
> > tree and I would go bat-shit crazy having to deal with all the merges
> > and rebasing going on.
> >
> > If there was a separate device tree project, I would very much prefer
> > to use that and make device tree changes there such that I could
> > submit any additions to the canonical sources. I'm currently spending
> > too much of my development time synching the device trees in my U-Boot
> > tree with what's going on on the Linux side.
>
> Right, exactly. I have exactly the same problem and so do other people
> working with U-Boot. At least we have a work-around.
I'm confused. I read this as Mark says "I need to solve this problem
for all users, I can't compile the device tree in to U-Boot as it will
be wrong" and then Simon says "Yes, compile in the device tree for all
users, that's what my series brings us".
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 21:53 ` Tom Rini
@ 2021-12-02 22:42 ` Simon Glass
0 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 22:42 UTC (permalink / raw)
To: Tom Rini
Cc: Mark Kettenis, ilias.apalodimas, francois.ozog, awilliams,
albert.u.boot, agraf, Anastasiia_Lukianenko, andre.przywara,
bmeng.cn, xypron.glpk, vanbaren, linus.walleij, mbrugger,
michal.simek, Oleksandr_Andrushchenko, peter.maydell, seanga2,
swarren, swarren, fitzsim, tuomas.tynkkynen, u-boot
Hi Tom,
On Thu, 2 Dec 2021 at 14:53, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 02, 2021 at 12:24:24PM -0700, Simon Glass wrote:
> > Hi Mark,
> >
> > On Thu, 2 Dec 2021 at 12:22, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > >
> > > > From: Simon Glass <sjg@chromium.org>
> > > > Date: Thu, 2 Dec 2021 11:53:53 -0700
> > > >
> > > > Hi Mark,
> > > >
> > > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > >
> > > > > > From: Simon Glass <sjg@chromium.org>
> > > > > > Date: Thu, 2 Dec 2021 11:21:22 -0700
> > > > > >
> > > > > > Hi Mark,
> > > > > >
> > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > > > >
> > > > > > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200
> > > > > > > >
> > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > > > > > > > Hi Simon
> > > > > > > > > >
> > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > > > > > > > > >
> > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > > > > >
> > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > > > > > appended to U-Boot
> > > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > > > > > the ELF file (also used for EFI)
> > > > > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > > > > >
> > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > > > > > >
> > > > > > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > > > > >
> > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > > > > >
> > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > > > > >
> > > > > > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > > > > > (and placeholders) to make the build work.
> > > > > > > > > > >
> > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > > > > > files, some patches in this series can be dropped.
> > > > > > > > > > >
> > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > > > > > >
> > > > > > > > > > > [1]
> > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > > >
> > > > > > > > > > > Changes in v6:
> > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > >
> > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > > > > not in favor of this new version either.
> > > > > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > > > > mainline….
> > > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > > > > with DTs for the platform.
> > > > > > > > >
> > > > > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > > > > more.
> > > > > > > >
> > > > > > > > So this is a key point for me and the reason I completely disagree
> > > > > > > > with this approach. This proposal is working in the *exact* opposite
> > > > > > > > direction and we'll never be able to get rid of device trees from
> > > > > > > > U-Boot, even if at some point they move out of the kernel to a
> > > > > > > > 'common' repo'. I'll just repeat what I've been saying since v1.
> > > > > > > > Personally I'd be way happier if we could figure out were the specific
> > > > > > > > U-Boot config nodes are needed and when are they needed. Based on
> > > > > > > > what we figure out we could, pick up the device tree from a previous
> > > > > > > > state bootloader and fix it up with our special nodes before we start
> > > > > > > > using it, using internal DTS files (compiled to .dtbos or similar)
> > > > > > > > that indeed belong in the u-boot tree.
> > > > > > >
> > > > > > > I don't think it makes sense to put stuff in the DT that is specific
> > > > > > > for U-Boot only to pull it out moments later. Maybe it does make some
> > > > > > > sense to do this to pass information between TPL/SPL and U-Boot
> > > > > > > proper. But otherwise you can just use global variables...
> > > > > > >
> > > > > > > Now I just ran into an issue on Apple M1 that may have some relevance
> > > > > > > here. I'm adding support for power domains and the serial port
> > > > > > > requires certain power domains to be on. Since the serial port is
> > > > > > > initialized in the pre-relocation phase this means that the device
> > > > > > > tree nodes for the power domain controllers need to have the
> > > > > > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't
> > > > > > > be able to bind the power domain controller driver in this phase and
> > > > > > > binding the serial port driver itself will fail. Which makes U-Boot
> > > > > > > hang without any visible output on the serial console.
> > > > > > >
> > > > > > > Within the Asahi Linux group we're currently discussing how to solve
> > > > > > > this. We could just add the "u-boot,dm-pre-reloc" properties in the
> > > > > > > device trees that we're going to distribute as part of m1n1 (the
> > > > > > > "bootloader" than embeds U-Boot). Or we can write some code that adds
> > > > > > > those properties to the device tree nodes that are dependencies for
> > > > > > > the serial port.
> > > > > > >
> > > > > > > I don't think the suggestion of applying an overlay embedded in U-Boot
> > > > > > > would work here. The code applying the overlay would need to run very
> > > > > > > early on in the pre-relocation phase. We'd also have to include
> > > > > > > overlays for all the models that Apple offers and pick the right one.
> > > > > > > And if a new model appears we can no longer just add a new device tree
> > > > > > > to m1n1.
> > > > > >
> > > > > > Well put.
> > > > > >
> > > > > > >
> > > > > > > But maybe there is a case where the overlay approach would make sense...
> > > > > >
> > > > > > There might be, but I haven't found it yet.
> > > > > >
> > > > > > BTW I suggest we figure out how to upstream the binding for this. I
> > > > > > will see if I can send a patch to start the process. The last patch
> > > > > > didn't get any comments though.
> > > > > >
> > > > > > In the interim there is probably no choice but to add the properties
> > > > > > into the m1n1 project. Of course, for development, you could just turn
> > > > > > off OF_BOARD, with my series applied. Which is a lot of the point of
> > > > > > all of this discussion...
> > > > >
> > > > > And that is exactly why I don't see the point of this series. There
> > > > > is no chance of that working. The device tree that is currently in
> > > > > the U-Boot tree (essentially because you made me add one) is only a
> > > > > template that gets modified by m1n1 to account for hardware
> > > > > characteristics (amount of memory, cores that are actually enabled,
> > > > > MAC addresses, WiFi antenna configuration, etc. etc.). If I flip
> > > > > OF_BOARD U-Boot would simply not work.
>
> I read this as Mark saying he builds the dtb file for U-Boot as well as
> Linux out of tree, and feeds those two files to m1n1. m1n1 is
> responsible for taking the dtb and adjusting as needed, and handing
> along to U-Boot.
>
> > > > > The way I do development is that I simply build a device tree, build
> > > > > U-boot and upload them over serial to m1n1 running on the device. I
> > > > > currently do build my device trees out of the U-Boot tree, but the
> > > > > main reason for that is because the Linux development model means that
> > > > > too many of the device tree patches are still in flight. I often use
> > > > > the device tree from a different U-Boot repository clone than the one
> > > > > I do the actual U-Boot development in anyway.
> > > >
> > > > Yes and I think you have made my point. That is all I am saying. I am
> > > > not claiming that U-Boot needs to be the golden repo for the .dts,
> > > > just that it should have something suitable that works well enough for
> > > > development, and can be modified and updated as development
> > > > progresses.
> > >
> > > No you are missing my point. I'm only doing it this way because the
> > > Linux development model is so broken that it takes months for patches
> > > posted on the mailing list to end up in a somewhat official source
> > > tree and I would go bat-shit crazy having to deal with all the merges
> > > and rebasing going on.
> > >
> > > If there was a separate device tree project, I would very much prefer
> > > to use that and make device tree changes there such that I could
> > > submit any additions to the canonical sources. I'm currently spending
> > > too much of my development time synching the device trees in my U-Boot
> > > tree with what's going on on the Linux side.
> >
> > Right, exactly. I have exactly the same problem and so do other people
> > working with U-Boot. At least we have a work-around.
>
> I'm confused. I read this as Mark says "I need to solve this problem
> for all users, I can't compile the device tree in to U-Boot as it will
> be wrong" and then Simon says "Yes, compile in the device tree for all
> users, that's what my series brings us".
No I just mean, that for development, U-Boot is a nice place to build
and include the DT, that's all. Mark is pointing out a workflow issue
that I have had as well, in spades. It is useful to be able to modify
the DT and have it be built by U-Boot. I did exactly the same thing
when testing with m1n1. I'm not suggesting anything else. This is a
storm in a teacup.
The only reason DT has served U-Boot over all these years is that we
have had control of it. Do you honestly think driver model would have
worked without that? of-platdata? What about binman?
I'm not giving it up until we have our bindings upstream and the DTs
are discoverable and automatically downloadable as part of a build.
The OF_PRIOR_STAGE thing should never have happened while we are in
this precarious state. We need a way to keep control until we have
things sorted out. If nothing else, it should help get the support of
the people on these threads for getting bindings agreed. At least from
what I can tell, the people who said we couldn't have U-Boot
properties in the DT are quieter these days. Let's see if that
continues.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 18:15 ` Mark Kettenis
2021-12-02 18:21 ` Simon Glass
@ 2021-12-02 18:32 ` François Ozog
2021-12-02 19:00 ` Mark Kettenis
2021-12-03 7:50 ` Ilias Apalodimas
2 siblings, 1 reply; 136+ messages in thread
From: François Ozog @ 2021-12-02 18:32 UTC (permalink / raw)
To: Mark Kettenis
Cc: Ilias Apalodimas, trini, sjg, awilliams, albert.u.boot, agraf,
anastasiia_lukianenko, andre.przywara, bmeng.cn, xypron.glpk,
vanbaren, linus.walleij, mbrugger, michal.simek,
oleksandr_andrushchenko, peter.maydell, seanga2, swarren,
swarren, fitzsim, tuomas.tynkkynen, u-boot
On Thu, 2 Dec 2021 at 19:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > Date: Thu, 2 Dec 2021 19:03:46 +0200
> >
> > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > Hi Simon
> > > >
> > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit
> :
> > > >
> > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE
> so
> > > > > there are only three ways to obtain a devicetree:
> > > > >
> > > > > - OF_SEPARATE - the normal way, where the devicetree is built
> and
> > > > > appended to U-Boot
> > > > > - OF_EMBED - for development purposes, the devicetree is
> embedded in
> > > > > the ELF file (also used for EFI)
> > > > > - OF_BOARD - the board figures it out on its own
> > > > >
> > > > > The last one is currently set up so that no devicetree is needed
> at all
> > > > > in the U-Boot tree. Most boards do provide one, but some don't.
> Some
> > > > > don't even provide instructions on how to boot on the board.
> > > > >
> > > > > The problems with this approach are documented in another patch in
> this
> > > > > series: "doc: Add documentation about devicetree usage"
> > > > >
> > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any
> board
> > > > > can obtain its devicetree at runtime, even it is has a devicetree
> built
> > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader
> and its
> > > > > caller may have a better idea about the hardware available in the
> machine.
> > > > > This is the case with a few QEMU boards, for example.
> > > > >
> > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be
> an
> > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > >
> > > > > This series makes this change, adding various missing devicetree
> files
> > > > > (and placeholders) to make the build work.
> > > > >
> > > > > Note: If board maintainers are able to add their own patch to add
> the
> > > > > files, some patches in this series can be dropped.
> > > > >
> > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > qemu-riscv64_spl problem is fixed.
> > > > >
> > > > > [1]
> > > > >
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > >
> > > > > Changes in v6:
> > > > > - Fix description of OF_BOARD so it refers just to the current
> state
> > > > > - Explain that the 'two devicetrees' refers to two *control*
> devicetrees
> > > > > - Expand the commit message based on comments
> > > > > - Expand the commit message based on comments
> > > >
> > > > You haven’t addressed any concerns expressed on the mailing list.so
> I am
> > > > not in favor of this new version either.
> > > > If you make a version without « fake DTs » as you name them, there
> are good
> > > > advances in the documentation and other areas that would be better in
> > > > mainline….
> > > > If I am the only one thinking this way and the patch can be
> accepted, I
> > > > would love there is a warning in capital letters at the top of the
> DTS fake
> > > > files that explains the intent of this fake DT, the possible
> outcomes of
> > > > not using the one provided by the platform and the right way of
> dealing
> > > > with DTs for the platform.
> > >
> > > This is the part that I too am still unhappy about. I do not want
> > > reference or fake or whatever device trees in the U-Boot source tree.
> > > We should be able to _remove_ the ones we have, that are not required,
> > > with doc/board/...rst explaining how to get / view one. Not adding
> > > more.
> >
> > So this is a key point for me and the reason I completely disagree
> > with this approach. This proposal is working in the *exact* opposite
> > direction and we'll never be able to get rid of device trees from
> > U-Boot, even if at some point they move out of the kernel to a
> > 'common' repo'. I'll just repeat what I've been saying since v1.
> > Personally I'd be way happier if we could figure out were the specific
> > U-Boot config nodes are needed and when are they needed. Based on
> > what we figure out we could, pick up the device tree from a previous
> > state bootloader and fix it up with our special nodes before we start
> > using it, using internal DTS files (compiled to .dtbos or similar)
> > that indeed belong in the u-boot tree.
>
> I don't think it makes sense to put stuff in the DT that is specific
> for U-Boot only to pull it out moments later. Maybe it does make some
> sense to do this to pass information between TPL/SPL and U-Boot
> proper. But otherwise you can just use global variables...
>
> Now I just ran into an issue on Apple M1 that may have some relevance
> here. I'm adding support for power domains and the serial port
> requires certain power domains to be on. Since the serial port is
> initialized in the pre-relocation phase this means that the device
> tree nodes for the power domain controllers need to have the
> "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't
> be able to bind the power domain controller driver in this phase and
> binding the serial port driver itself will fail. Which makes U-Boot
> hang without any visible output on the serial console.
>
> Does this hint at a bigger issue that DT shall be parsed and handled in
the U-Boot process way early than it is today?
Ilias reported a similar problem with TPM handling where you need to
discover TPM very early to deal with it.
There may be one early parse and two scans (one early, one normal
enumeration)
> Within the Asahi Linux group we're currently discussing how to solve
> this. We could just add the "u-boot,dm-pre-reloc" properties in the
> device trees that we're going to distribute as part of m1n1 (the
> "bootloader" than embeds U-Boot). Or we can write some code that adds
> those properties to the device tree nodes that are dependencies for
> the serial port.
>
> I don't think the suggestion of applying an overlay embedded in U-Boot
> would work here. The code applying the overlay would need to run very
> early on in the pre-relocation phase. We'd also have to include
> overlays for all the models that Apple offers and pick the right one.
> And if a new model appears we can no longer just add a new device tree
> to m1n1.
>
> But maybe there is a case where the overlay approach would make sense...
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 18:32 ` François Ozog
@ 2021-12-02 19:00 ` Mark Kettenis
0 siblings, 0 replies; 136+ messages in thread
From: Mark Kettenis @ 2021-12-02 19:00 UTC (permalink / raw)
To: François Ozog
Cc: ilias.apalodimas, trini, sjg, awilliams, albert.u.boot, agraf,
anastasiia_lukianenko, andre.przywara, bmeng.cn, xypron.glpk,
vanbaren, linus.walleij, mbrugger, michal.simek,
oleksandr_andrushchenko, peter.maydell, seanga2, swarren,
swarren, fitzsim, tuomas.tynkkynen, u-boot
> From: François Ozog <francois.ozog@linaro.org>
> Date: Thu, 2 Dec 2021 19:32:17 +0100
>
> On Thu, 2 Dec 2021 at 19:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > Date: Thu, 2 Dec 2021 19:03:46 +0200
> >
> > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > > Hi Simon
> > > >
> > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a
> écrit :
> > > >
> > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and
> OF_HOSTFILE so
> > > > > there are only three ways to obtain a devicetree:
> > > > >
> > > > > - OF_SEPARATE - the normal way, where the devicetree is built
> and
> > > > > appended to U-Boot
> > > > > - OF_EMBED - for development purposes, the devicetree is
> embedded in
> > > > > the ELF file (also used for EFI)
> > > > > - OF_BOARD - the board figures it out on its own
> > > > >
> > > > > The last one is currently set up so that no devicetree is needed
> at all
> > > > > in the U-Boot tree. Most boards do provide one, but some don't.
> Some
> > > > > don't even provide instructions on how to boot on the board.
> > > > >
> > > > > The problems with this approach are documented in another patch
> in this
> > > > > series: "doc: Add documentation about devicetree usage"
> > > > >
> > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE.
> Any board
> > > > > can obtain its devicetree at runtime, even it is has a
> devicetree built
> > > > > in U-Boot. This is because U-Boot may be a second-stage
> bootloader and its
> > > > > caller may have a better idea about the hardware available in
> the machine.
> > > > > This is the case with a few QEMU boards, for example.
> > > > >
> > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should
> be an
> > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > >
> > > > > This series makes this change, adding various missing devicetree
> files
> > > > > (and placeholders) to make the build work.
> > > > >
> > > > > Note: If board maintainers are able to add their own patch to
> add the
> > > > > files, some patches in this series can be dropped.
> > > > >
> > > > > It also provides a few qemu clean-ups discovered along the way.
> The
> > > > > qemu-riscv64_spl problem is fixed.
> > > > >
> > > > > [1]
> > > > >
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>
> > > > >
> > > > > Changes in v6:
> > > > > - Fix description of OF_BOARD so it refers just to the current
> state
> > > > > - Explain that the 'two devicetrees' refers to two *control*
> devicetrees
> > > > > - Expand the commit message based on comments
> > > > > - Expand the commit message based on comments
> > > >
> > > > You haven’t addressed any concerns expressed on the mailing
> list.so I am
> > > > not in favor of this new version either.
> > > > If you make a version without « fake DTs » as you name them, there
> are good
> > > > advances in the documentation and other areas that would be better
> in
> > > > mainline….
> > > > If I am the only one thinking this way and the patch can be
> accepted, I
> > > > would love there is a warning in capital letters at the top of the
> DTS fake
> > > > files that explains the intent of this fake DT, the possible
> outcomes of
> > > > not using the one provided by the platform and the right way of
> dealing
> > > > with DTs for the platform.
> > >
> > > This is the part that I too am still unhappy about. I do not want
> > > reference or fake or whatever device trees in the U-Boot source
> tree.
> > > We should be able to _remove_ the ones we have, that are not
> required,
> > > with doc/board/...rst explaining how to get / view one. Not adding
> > > more.
> >
> > So this is a key point for me and the reason I completely disagree
> > with this approach. This proposal is working in the *exact* opposite
> > direction and we'll never be able to get rid of device trees from
> > U-Boot, even if at some point they move out of the kernel to a
> > 'common' repo'. I'll just repeat what I've been saying since v1.
> > Personally I'd be way happier if we could figure out were the specific
> > U-Boot config nodes are needed and when are they needed. Based on
> > what we figure out we could, pick up the device tree from a previous
> > state bootloader and fix it up with our special nodes before we start
> > using it, using internal DTS files (compiled to .dtbos or similar)
> > that indeed belong in the u-boot tree.
>
> I don't think it makes sense to put stuff in the DT that is specific
> for U-Boot only to pull it out moments later. Maybe it does make some
> sense to do this to pass information between TPL/SPL and U-Boot
> proper. But otherwise you can just use global variables...
>
> Now I just ran into an issue on Apple M1 that may have some relevance
> here. I'm adding support for power domains and the serial port
> requires certain power domains to be on. Since the serial port is
> initialized in the pre-relocation phase this means that the device
> tree nodes for the power domain controllers need to have the
> "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't
> be able to bind the power domain controller driver in this phase and
> binding the serial port driver itself will fail. Which makes U-Boot
> hang without any visible output on the serial console.
>
> Does this hint at a bigger issue that DT shall be parsed and handled in the
> U-Boot process way early than it is today?
No it doesn't. It indicates that it is already parsed and handled
very early on in the U-Boot process, which implies that applying
modifications in U-Boot itself will be a challenge.
> Ilias reported a similar problem with TPM handling where you need to
> discover TPM very early to deal with it.
> There may be one early parse and two scans (one early, one normal
> enumeration)
Serial ports are explicitly handled early on. I suppose the TPM could
be handled in a similar way if there is a valid reason to do so. But
in my opinion the TPM is way to complex for doing something like that.
> Within the Asahi Linux group we're currently discussing how to solve
> this. We could just add the "u-boot,dm-pre-reloc" properties in the
> device trees that we're going to distribute as part of m1n1 (the
> "bootloader" than embeds U-Boot). Or we can write some code that adds
> those properties to the device tree nodes that are dependencies for
> the serial port.
>
> I don't think the suggestion of applying an overlay embedded in U-Boot
> would work here. The code applying the overlay would need to run very
> early on in the pre-relocation phase. We'd also have to include
> overlays for all the models that Apple offers and pick the right one.
> And if a new model appears we can no longer just add a new device tree
> to m1n1.
>
> But maybe there is a case where the overlay approach would make sense...
>
> --
>
> * François-Frédéric Ozog | Director Business Development
> T: +33.67221.6485
> francois.ozog@linaro.org | Skype: ffozog
> *
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 18:15 ` Mark Kettenis
2021-12-02 18:21 ` Simon Glass
2021-12-02 18:32 ` François Ozog
@ 2021-12-03 7:50 ` Ilias Apalodimas
2021-12-03 10:27 ` Mark Kettenis
2 siblings, 1 reply; 136+ messages in thread
From: Ilias Apalodimas @ 2021-12-03 7:50 UTC (permalink / raw)
To: Mark Kettenis
Cc: trini, francois.ozog, sjg, awilliams, albert.u.boot, agraf,
anastasiia_lukianenko, andre.przywara, bmeng.cn, xypron.glpk,
vanbaren, linus.walleij, mbrugger, michal.simek,
oleksandr_andrushchenko, peter.maydell, seanga2, swarren,
swarren, fitzsim, tuomas.tynkkynen, u-boot
Hi Mark,
> > > > >
[...]
> > > > > Changes in v6:
> > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > - Expand the commit message based on comments
> > > > > - Expand the commit message based on comments
> > > >
> > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > not in favor of this new version either.
> > > > If you make a version without « fake DTs » as you name them, there are good
> > > > advances in the documentation and other areas that would be better in
> > > > mainline….
> > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > not using the one provided by the platform and the right way of dealing
> > > > with DTs for the platform.
> > >
> > > This is the part that I too am still unhappy about. I do not want
> > > reference or fake or whatever device trees in the U-Boot source tree.
> > > We should be able to _remove_ the ones we have, that are not required,
> > > with doc/board/...rst explaining how to get / view one. Not adding
> > > more.
> >
> > So this is a key point for me and the reason I completely disagree
> > with this approach. This proposal is working in the *exact* opposite
> > direction and we'll never be able to get rid of device trees from
> > U-Boot, even if at some point they move out of the kernel to a
> > 'common' repo'. I'll just repeat what I've been saying since v1.
> > Personally I'd be way happier if we could figure out were the specific
> > U-Boot config nodes are needed and when are they needed. Based on
> > what we figure out we could, pick up the device tree from a previous
> > state bootloader and fix it up with our special nodes before we start
> > using it, using internal DTS files (compiled to .dtbos or similar)
> > that indeed belong in the u-boot tree.
>
> I don't think it makes sense to put stuff in the DT that is specific
> for U-Boot only to pull it out moments later. Maybe it does make some
> sense to do this to pass information between TPL/SPL and U-Boot
> proper. But otherwise you can just use global variables...
Last time we said we don't really have to remove them, but I get the
point.
>
> Now I just ran into an issue on Apple M1 that may have some relevance
> here. I'm adding support for power domains and the serial port
> requires certain power domains to be on. Since the serial port is
> initialized in the pre-relocation phase this means that the device
> tree nodes for the power domain controllers need to have the
> "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't
> be able to bind the power domain controller driver in this phase and
> binding the serial port driver itself will fail. Which makes U-Boot
> hang without any visible output on the serial console.
Very relevant indeed. That's close to what I was afraid of when I said
"if we could figure out were the specific U-Boot config nodes are needed
and *when* are they needed". Obviously this is a clear no go, since more
boards will have similar requirements in the future.
>
> Within the Asahi Linux group we're currently discussing how to solve
> this. We could just add the "u-boot,dm-pre-reloc" properties in the
> device trees that we're going to distribute as part of m1n1 (the
> "bootloader" than embeds U-Boot). Or we can write some code that adds
> those properties to the device tree nodes that are dependencies for
> the serial port.
That might make sense for a project like m1n1 were you are dealing with a
handful of devices, but I think it's going to be a pain on a larger scale,
unless of course the bindings are documented in upstream. In that case we
could ask previous bootloaders to add them etc.
>
> I don't think the suggestion of applying an overlay embedded in U-Boot
> would work here. The code applying the overlay would need to run very
> early on in the pre-relocation phase.
Yep it wouldn't
> We'd also have to include
> overlays for all the models that Apple offers and pick the right one.
> And if a new model appears we can no longer just add a new device tree
> to m1n1.
>
> But maybe there is a case where the overlay approach would make sense...
I think there is, for example I was thinking of TF-A doing all the hardware init
and then handover a DTB into u-boot on a register. In that case U-boot
could fixup the DTB before initialing the rest of the subsystems and make DM
happy. However as you pointed out that's not the case for all boards and
dealing with this in the early pre-relocation stage is close to
impossible, so let's drop that.
Thanks!
/Ilias
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 7:50 ` Ilias Apalodimas
@ 2021-12-03 10:27 ` Mark Kettenis
2021-12-03 13:59 ` Heinrich Schuchardt
0 siblings, 1 reply; 136+ messages in thread
From: Mark Kettenis @ 2021-12-03 10:27 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: trini, francois.ozog, sjg, awilliams, albert.u.boot, agraf,
anastasiia_lukianenko, andre.przywara, bmeng.cn, xypron.glpk,
vanbaren, linus.walleij, mbrugger, michal.simek,
oleksandr_andrushchenko, peter.maydell, seanga2, swarren,
swarren, fitzsim, tuomas.tynkkynen, u-boot
> Date: Fri, 3 Dec 2021 09:50:44 +0200
> From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
>
> Hi Mark,
>
> > > > > >
>
> [...]
>
> > > > > > Changes in v6:
> > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > - Expand the commit message based on comments
> > > > > > - Expand the commit message based on comments
> > > > >
> > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > not in favor of this new version either.
> > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > advances in the documentation and other areas that would be better in
> > > > > mainline….
> > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > not using the one provided by the platform and the right way of dealing
> > > > > with DTs for the platform.
> > > >
> > > > This is the part that I too am still unhappy about. I do not want
> > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > We should be able to _remove_ the ones we have, that are not required,
> > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > more.
> > >
> > > So this is a key point for me and the reason I completely disagree
> > > with this approach. This proposal is working in the *exact* opposite
> > > direction and we'll never be able to get rid of device trees from
> > > U-Boot, even if at some point they move out of the kernel to a
> > > 'common' repo'. I'll just repeat what I've been saying since v1.
> > > Personally I'd be way happier if we could figure out were the specific
> > > U-Boot config nodes are needed and when are they needed. Based on
> > > what we figure out we could, pick up the device tree from a previous
> > > state bootloader and fix it up with our special nodes before we start
> > > using it, using internal DTS files (compiled to .dtbos or similar)
> > > that indeed belong in the u-boot tree.
> >
> > I don't think it makes sense to put stuff in the DT that is specific
> > for U-Boot only to pull it out moments later. Maybe it does make some
> > sense to do this to pass information between TPL/SPL and U-Boot
> > proper. But otherwise you can just use global variables...
>
> Last time we said we don't really have to remove them, but I get the
> point.
Ah, when I said "pull it out" I meant "read it back"; not "delete it".
> > Now I just ran into an issue on Apple M1 that may have some relevance
> > here. I'm adding support for power domains and the serial port
> > requires certain power domains to be on. Since the serial port is
> > initialized in the pre-relocation phase this means that the device
> > tree nodes for the power domain controllers need to have the
> > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't
> > be able to bind the power domain controller driver in this phase and
> > binding the serial port driver itself will fail. Which makes U-Boot
> > hang without any visible output on the serial console.
>
> Very relevant indeed. That's close to what I was afraid of when I said
> "if we could figure out were the specific U-Boot config nodes are needed
> and *when* are they needed". Obviously this is a clear no go, since more
> boards will have similar requirements in the future.
>
> >
> > Within the Asahi Linux group we're currently discussing how to solve
> > this. We could just add the "u-boot,dm-pre-reloc" properties in the
> > device trees that we're going to distribute as part of m1n1 (the
> > "bootloader" than embeds U-Boot). Or we can write some code that adds
> > those properties to the device tree nodes that are dependencies for
> > the serial port.
>
> That might make sense for a project like m1n1 were you are dealing with a
> handful of devices, but I think it's going to be a pain on a larger scale,
> unless of course the bindings are documented in upstream. In that case we
> could ask previous bootloaders to add them etc.
>
> >
> > I don't think the suggestion of applying an overlay embedded in U-Boot
> > would work here. The code applying the overlay would need to run very
> > early on in the pre-relocation phase.
>
> Yep it wouldn't
>
> > We'd also have to include
> > overlays for all the models that Apple offers and pick the right one.
> > And if a new model appears we can no longer just add a new device tree
> > to m1n1.
> >
> > But maybe there is a case where the overlay approach would make sense...
>
> I think there is, for example I was thinking of TF-A doing all the hardware init
> and then handover a DTB into u-boot on a register. In that case U-boot
> could fixup the DTB before initialing the rest of the subsystems and make DM
> happy. However as you pointed out that's not the case for all boards and
> dealing with this in the early pre-relocation stage is close to
> impossible, so let's drop that.
>
>
> Thanks!
> /Ilias
>
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 10:27 ` Mark Kettenis
@ 2021-12-03 13:59 ` Heinrich Schuchardt
2021-12-03 14:30 ` Ilias Apalodimas
0 siblings, 1 reply; 136+ messages in thread
From: Heinrich Schuchardt @ 2021-12-03 13:59 UTC (permalink / raw)
To: Mark Kettenis, Ilias Apalodimas
Cc: trini, francois.ozog, sjg, awilliams, albert.u.boot, agraf,
anastasiia_lukianenko, andre.przywara, bmeng.cn, vanbaren,
linus.walleij, mbrugger, michal.simek, oleksandr_andrushchenko,
peter.maydell, seanga2, swarren, swarren, fitzsim,
tuomas.tynkkynen, u-boot
On 12/3/21 11:27, Mark Kettenis wrote:
>> Date: Fri, 3 Dec 2021 09:50:44 +0200
>> From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
>>
>> Hi Mark,
>>
>>>>>>>
>>
>> [...]
>>
>>>>>>> Changes in v6:
>>>>>>> - Fix description of OF_BOARD so it refers just to the current state
>>>>>>> - Explain that the 'two devicetrees' refers to two *control* devicetrees
>>>>>>> - Expand the commit message based on comments
>>>>>>> - Expand the commit message based on comments
>>>>>>
>>>>>> You haven’t addressed any concerns expressed on the mailing list.so I am
>>>>>> not in favor of this new version either.
>>>>>> If you make a version without « fake DTs » as you name them, there are good
>>>>>> advances in the documentation and other areas that would be better in
>>>>>> mainline….
>>>>>> If I am the only one thinking this way and the patch can be accepted, I
>>>>>> would love there is a warning in capital letters at the top of the DTS fake
>>>>>> files that explains the intent of this fake DT, the possible outcomes of
>>>>>> not using the one provided by the platform and the right way of dealing
>>>>>> with DTs for the platform.
>>>>>
>>>>> This is the part that I too am still unhappy about. I do not want
>>>>> reference or fake or whatever device trees in the U-Boot source tree.
>>>>> We should be able to _remove_ the ones we have, that are not required,
>>>>> with doc/board/...rst explaining how to get / view one. Not adding
>>>>> more.
>>>>
>>>> So this is a key point for me and the reason I completely disagree
>>>> with this approach. This proposal is working in the *exact* opposite
>>>> direction and we'll never be able to get rid of device trees from
>>>> U-Boot, even if at some point they move out of the kernel to a
>>>> 'common' repo'. I'll just repeat what I've been saying since v1.
>>>> Personally I'd be way happier if we could figure out were the specific
>>>> U-Boot config nodes are needed and when are they needed. Based on
>>>> what we figure out we could, pick up the device tree from a previous
>>>> state bootloader and fix it up with our special nodes before we start
>>>> using it, using internal DTS files (compiled to .dtbos or similar)
>>>> that indeed belong in the u-boot tree.
Applying a devicetree overlay can be implemented in common/board_f.c
before the first usage of the devicetree to initialize devices (there
are some that are initialized before relocation).
>>>
>>> I don't think it makes sense to put stuff in the DT that is specific
>>> for U-Boot only to pull it out moments later. Maybe it does make some
>>> sense to do this to pass information between TPL/SPL and U-Boot
>>> proper. But otherwise you can just use global variables...
Linux will silently ignore any node for which it does not have a
compatible string. So application of an overlay once in U-Boot is
sufficient.
Best regards
Heinrich
>>
>> Last time we said we don't really have to remove them, but I get the
>> point.
>
> Ah, when I said "pull it out" I meant "read it back"; not "delete it".
>
>>> Now I just ran into an issue on Apple M1 that may have some relevance
>>> here. I'm adding support for power domains and the serial port
>>> requires certain power domains to be on. Since the serial port is
>>> initialized in the pre-relocation phase this means that the device
>>> tree nodes for the power domain controllers need to have the
>>> "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't
>>> be able to bind the power domain controller driver in this phase and
>>> binding the serial port driver itself will fail. Which makes U-Boot
>>> hang without any visible output on the serial console.
>>
>> Very relevant indeed. That's close to what I was afraid of when I said
>> "if we could figure out were the specific U-Boot config nodes are needed
>> and *when* are they needed". Obviously this is a clear no go, since more
>> boards will have similar requirements in the future.
>>
>>>
>>> Within the Asahi Linux group we're currently discussing how to solve
>>> this. We could just add the "u-boot,dm-pre-reloc" properties in the
>>> device trees that we're going to distribute as part of m1n1 (the
>>> "bootloader" than embeds U-Boot). Or we can write some code that adds
>>> those properties to the device tree nodes that are dependencies for
>>> the serial port.
>>
>> That might make sense for a project like m1n1 were you are dealing with a
>> handful of devices, but I think it's going to be a pain on a larger scale,
>> unless of course the bindings are documented in upstream. In that case we
>> could ask previous bootloaders to add them etc.
>>
>>>
>>> I don't think the suggestion of applying an overlay embedded in U-Boot
>>> would work here. The code applying the overlay would need to run very
>>> early on in the pre-relocation phase.
>>
>> Yep it wouldn't
>>
>>> We'd also have to include
>>> overlays for all the models that Apple offers and pick the right one.
>>> And if a new model appears we can no longer just add a new device tree
>>> to m1n1.
>>>
>>> But maybe there is a case where the overlay approach would make sense...
>>
>> I think there is, for example I was thinking of TF-A doing all the hardware init
>> and then handover a DTB into u-boot on a register. In that case U-boot
>> could fixup the DTB before initialing the rest of the subsystems and make DM
>> happy. However as you pointed out that's not the case for all boards and
>> dealing with this in the early pre-relocation stage is close to
>> impossible, so let's drop that.
>>
>>
>> Thanks!
>> /Ilias
>>
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 13:59 ` Heinrich Schuchardt
@ 2021-12-03 14:30 ` Ilias Apalodimas
2021-12-03 14:35 ` Tom Rini
0 siblings, 1 reply; 136+ messages in thread
From: Ilias Apalodimas @ 2021-12-03 14:30 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Mark Kettenis, trini, francois.ozog, sjg, awilliams,
albert.u.boot, agraf, anastasiia_lukianenko, andre.przywara,
bmeng.cn, vanbaren, linus.walleij, mbrugger, michal.simek,
oleksandr_andrushchenko, peter.maydell, seanga2, swarren,
swarren, fitzsim, tuomas.tynkkynen, u-boot
Hi Heinrich,
On Fri, Dec 03, 2021 at 02:59:44PM +0100, Heinrich Schuchardt wrote:
> On 12/3/21 11:27, Mark Kettenis wrote:
> > > Date: Fri, 3 Dec 2021 09:50:44 +0200
> > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > >
> > > Hi Mark,
> > >
> > > > > > > >
> > >
> > > [...]
> > >
> > > > > > > > Changes in v6:
> > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > - Expand the commit message based on comments
> > > > > > > > - Expand the commit message based on comments
> > > > > > >
> > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > not in favor of this new version either.
> > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > mainline….
> > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > with DTs for the platform.
> > > > > >
> > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > more.
> > > > >
> > > > > So this is a key point for me and the reason I completely disagree
> > > > > with this approach. This proposal is working in the *exact* opposite
> > > > > direction and we'll never be able to get rid of device trees from
> > > > > U-Boot, even if at some point they move out of the kernel to a
> > > > > 'common' repo'. I'll just repeat what I've been saying since v1.
> > > > > Personally I'd be way happier if we could figure out were the specific
> > > > > U-Boot config nodes are needed and when are they needed. Based on
> > > > > what we figure out we could, pick up the device tree from a previous
> > > > > state bootloader and fix it up with our special nodes before we start
> > > > > using it, using internal DTS files (compiled to .dtbos or similar)
> > > > > that indeed belong in the u-boot tree.
>
> Applying a devicetree overlay can be implemented in common/board_f.c
> before the first usage of the devicetree to initialize devices (there
> are some that are initialized before relocation).
Thanks for digging this up. Tbh I misunderstood the original mail from
Mark. When I read pre-reloc I assumed no C environment was up yet.
However this raises a few questions.
1. The .dtbos will need to be embedded in the u-boot binary since
there's no FS access (or in some cases storage access to begin with)
2. The RAM we have is going to be limited if we want to apply the overlays
before consoles etc are up, since it basically has to happen at some point
near 'fdtdec_setup'
3.Are we are going to need some logic on how to apply the .dtbos? E.g think of
the same hardware with different configuration. You'll be able to use the
same binary, if you can somehow configure which overlays you want to apply.
Thanks
/Ilias
>
> > > >
> > > > I don't think it makes sense to put stuff in the DT that is specific
> > > > for U-Boot only to pull it out moments later. Maybe it does make some
> > > > sense to do this to pass information between TPL/SPL and U-Boot
> > > > proper. But otherwise you can just use global variables...
>
> Linux will silently ignore any node for which it does not have a
> compatible string. So application of an overlay once in U-Boot is
> sufficient.
>
> Best regards
>
> Heinrich
>
> > >
> > > Last time we said we don't really have to remove them, but I get the
> > > point.
> >
> > Ah, when I said "pull it out" I meant "read it back"; not "delete it".
> >
> > > > Now I just ran into an issue on Apple M1 that may have some relevance
> > > > here. I'm adding support for power domains and the serial port
> > > > requires certain power domains to be on. Since the serial port is
> > > > initialized in the pre-relocation phase this means that the device
> > > > tree nodes for the power domain controllers need to have the
> > > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't
> > > > be able to bind the power domain controller driver in this phase and
> > > > binding the serial port driver itself will fail. Which makes U-Boot
> > > > hang without any visible output on the serial console.
> > >
> > > Very relevant indeed. That's close to what I was afraid of when I said
> > > "if we could figure out were the specific U-Boot config nodes are needed
> > > and *when* are they needed". Obviously this is a clear no go, since more
> > > boards will have similar requirements in the future.
> > >
> > > >
> > > > Within the Asahi Linux group we're currently discussing how to solve
> > > > this. We could just add the "u-boot,dm-pre-reloc" properties in the
> > > > device trees that we're going to distribute as part of m1n1 (the
> > > > "bootloader" than embeds U-Boot). Or we can write some code that adds
> > > > those properties to the device tree nodes that are dependencies for
> > > > the serial port.
> > >
> > > That might make sense for a project like m1n1 were you are dealing with a
> > > handful of devices, but I think it's going to be a pain on a larger scale,
> > > unless of course the bindings are documented in upstream. In that case we
> > > could ask previous bootloaders to add them etc.
> > >
> > > >
> > > > I don't think the suggestion of applying an overlay embedded in U-Boot
> > > > would work here. The code applying the overlay would need to run very
> > > > early on in the pre-relocation phase.
> > >
> > > Yep it wouldn't
> > >
> > > > We'd also have to include
> > > > overlays for all the models that Apple offers and pick the right one.
> > > > And if a new model appears we can no longer just add a new device tree
> > > > to m1n1.
> > > >
> > > > But maybe there is a case where the overlay approach would make sense...
> > >
> > > I think there is, for example I was thinking of TF-A doing all the hardware init
> > > and then handover a DTB into u-boot on a register. In that case U-boot
> > > could fixup the DTB before initialing the rest of the subsystems and make DM
> > > happy. However as you pointed out that's not the case for all boards and
> > > dealing with this in the early pre-relocation stage is close to
> > > impossible, so let's drop that.
> > >
> > >
> > > Thanks!
> > > /Ilias
> > >
>
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 14:30 ` Ilias Apalodimas
@ 2021-12-03 14:35 ` Tom Rini
2021-12-03 15:10 ` Ilias Apalodimas
0 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-03 14:35 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Heinrich Schuchardt, Mark Kettenis, francois.ozog, sjg,
awilliams, albert.u.boot, agraf, anastasiia_lukianenko,
andre.przywara, bmeng.cn, vanbaren, linus.walleij, mbrugger,
michal.simek, oleksandr_andrushchenko, peter.maydell, seanga2,
swarren, swarren, fitzsim, tuomas.tynkkynen, u-boot
[-- Attachment #1: Type: text/plain, Size: 4237 bytes --]
On Fri, Dec 03, 2021 at 04:30:40PM +0200, Ilias Apalodimas wrote:
> Hi Heinrich,
>
> On Fri, Dec 03, 2021 at 02:59:44PM +0100, Heinrich Schuchardt wrote:
> > On 12/3/21 11:27, Mark Kettenis wrote:
> > > > Date: Fri, 3 Dec 2021 09:50:44 +0200
> > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > >
> > > > Hi Mark,
> > > >
> > > > > > > > >
> > > >
> > > > [...]
> > > >
> > > > > > > > > Changes in v6:
> > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > > > > - Expand the commit message based on comments
> > > > > > > > > - Expand the commit message based on comments
> > > > > > > >
> > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > > > > not in favor of this new version either.
> > > > > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > > > > advances in the documentation and other areas that would be better in
> > > > > > > > mainline….
> > > > > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > > > > not using the one provided by the platform and the right way of dealing
> > > > > > > > with DTs for the platform.
> > > > > > >
> > > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > > more.
> > > > > >
> > > > > > So this is a key point for me and the reason I completely disagree
> > > > > > with this approach. This proposal is working in the *exact* opposite
> > > > > > direction and we'll never be able to get rid of device trees from
> > > > > > U-Boot, even if at some point they move out of the kernel to a
> > > > > > 'common' repo'. I'll just repeat what I've been saying since v1.
> > > > > > Personally I'd be way happier if we could figure out were the specific
> > > > > > U-Boot config nodes are needed and when are they needed. Based on
> > > > > > what we figure out we could, pick up the device tree from a previous
> > > > > > state bootloader and fix it up with our special nodes before we start
> > > > > > using it, using internal DTS files (compiled to .dtbos or similar)
> > > > > > that indeed belong in the u-boot tree.
>
> >
> > Applying a devicetree overlay can be implemented in common/board_f.c
> > before the first usage of the devicetree to initialize devices (there
> > are some that are initialized before relocation).
>
> Thanks for digging this up. Tbh I misunderstood the original mail from
> Mark. When I read pre-reloc I assumed no C environment was up yet.
> However this raises a few questions.
> 1. The .dtbos will need to be embedded in the u-boot binary since
> there's no FS access (or in some cases storage access to begin with)
> 2. The RAM we have is going to be limited if we want to apply the overlays
> before consoles etc are up, since it basically has to happen at some point
> near 'fdtdec_setup'
> 3.Are we are going to need some logic on how to apply the .dtbos? E.g think of
> the same hardware with different configuration. You'll be able to use the
> same binary, if you can somehow configure which overlays you want to apply.
This has come up before and the answer has been "doing it this early
will be too large" where large can mean either of .text space (we have
many constrained platforms) or memory usage (this is before DRAM
potentially). It's also on the flip side one of those places where
maybe it's less of a problem on arm64 (where prior stages will have
initialized much already) than arm32 (where we are very early) and other
platforms. And we need solutions that work for both cases.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 14:35 ` Tom Rini
@ 2021-12-03 15:10 ` Ilias Apalodimas
0 siblings, 0 replies; 136+ messages in thread
From: Ilias Apalodimas @ 2021-12-03 15:10 UTC (permalink / raw)
To: Tom Rini
Cc: Heinrich Schuchardt, Mark Kettenis, francois.ozog, sjg,
awilliams, albert.u.boot, agraf, anastasiia_lukianenko,
andre.przywara, bmeng.cn, vanbaren, linus.walleij, mbrugger,
michal.simek, oleksandr_andrushchenko, peter.maydell, seanga2,
swarren, swarren, fitzsim, tuomas.tynkkynen, u-boot
Hi Tom,
> > > > > > > >
> > > > > > > > This is the part that I too am still unhappy about. I do not want
> > > > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding
> > > > > > > > more.
> > > > > > >
> > > > > > > So this is a key point for me and the reason I completely disagree
> > > > > > > with this approach. This proposal is working in the *exact* opposite
> > > > > > > direction and we'll never be able to get rid of device trees from
> > > > > > > U-Boot, even if at some point they move out of the kernel to a
> > > > > > > 'common' repo'. I'll just repeat what I've been saying since v1.
> > > > > > > Personally I'd be way happier if we could figure out were the specific
> > > > > > > U-Boot config nodes are needed and when are they needed. Based on
> > > > > > > what we figure out we could, pick up the device tree from a previous
> > > > > > > state bootloader and fix it up with our special nodes before we start
> > > > > > > using it, using internal DTS files (compiled to .dtbos or similar)
> > > > > > > that indeed belong in the u-boot tree.
> >
> > >
> > > Applying a devicetree overlay can be implemented in common/board_f.c
> > > before the first usage of the devicetree to initialize devices (there
> > > are some that are initialized before relocation).
> >
> > Thanks for digging this up. Tbh I misunderstood the original mail from
> > Mark. When I read pre-reloc I assumed no C environment was up yet.
> > However this raises a few questions.
> > 1. The .dtbos will need to be embedded in the u-boot binary since
> > there's no FS access (or in some cases storage access to begin with)
> > 2. The RAM we have is going to be limited if we want to apply the overlays
> > before consoles etc are up, since it basically has to happen at some point
> > near 'fdtdec_setup'
> > 3.Are we are going to need some logic on how to apply the .dtbos? E.g think of
> > the same hardware with different configuration. You'll be able to use the
> > same binary, if you can somehow configure which overlays you want to apply.
>
> This has come up before and the answer has been "doing it this early
> will be too large" where large can mean either of .text space (we have
> many constrained platforms) or memory usage (this is before DRAM
> potentially). It's also on the flip side one of those places where
> maybe it's less of a problem on arm64 (where prior stages will have
> initialized much already) than arm32 (where we are very early) and other
> platforms. And we need solutions that work for both cases.
So I have an answer on my (3).a We can use the bloblist for that.
We could do something along the lines of
1. Include .dtbos in u-boot source
2. Standardize the bloblist handover discussion we had across bootloaders,
so that the bloblist contains information of what .dtbos to apply. We can
even take it a step further and request specific .dtbos to be applied
before/after DRAM init to save some boards from the DRAM issue.
3. U-Boot applies the .dtbos on the fly.
What's more interesting is that looking around what we currently have, the
renesas RCAR platform is already doing something *very* similar [1].
[1] board/renesas/rcar-common/common.c -> fdtdec_board_setup
Cheers
/Ilias
>
> --
> Tom
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 17:03 ` Ilias Apalodimas
2021-12-02 17:09 ` Simon Glass
2021-12-02 18:15 ` Mark Kettenis
@ 2021-12-03 1:19 ` Andre Przywara
2 siblings, 0 replies; 136+ messages in thread
From: Andre Przywara @ 2021-12-03 1:19 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Tom Rini, François Ozog, Simon Glass, Aaron Williams,
Albert Aribaud, Alexander Graf, Anastasiia Lukianenko, Bin Meng,
Heinrich Schuchardt, Jerry Van Baren, Linus Walleij,
Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
On Thu, 2 Dec 2021 19:03:46 +0200
Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
Hi,
> On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > Hi Simon
> > >
> > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> > >
> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > there are only three ways to obtain a devicetree:
> > > >
> > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > appended to U-Boot
> > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > the ELF file (also used for EFI)
> > > > - OF_BOARD - the board figures it out on its own
> > > >
> > > > The last one is currently set up so that no devicetree is needed at all
> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > don't even provide instructions on how to boot on the board.
> > > >
> > > > The problems with this approach are documented in another patch in this
> > > > series: "doc: Add documentation about devicetree usage"
> > > >
> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > caller may have a better idea about the hardware available in the machine.
> > > > This is the case with a few QEMU boards, for example.
> > > >
> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > >
> > > > This series makes this change, adding various missing devicetree files
> > > > (and placeholders) to make the build work.
> > > >
> > > > Note: If board maintainers are able to add their own patch to add the
> > > > files, some patches in this series can be dropped.
> > > >
> > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > qemu-riscv64_spl problem is fixed.
> > > >
> > > > [1]
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > >
> > > > Changes in v6:
> > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > - Expand the commit message based on comments
> > > > - Expand the commit message based on comments
> > >
> > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > not in favor of this new version either.
> > > If you make a version without « fake DTs » as you name them, there are good
> > > advances in the documentation and other areas that would be better in
> > > mainline….
> > > If I am the only one thinking this way and the patch can be accepted, I
> > > would love there is a warning in capital letters at the top of the DTS fake
> > > files that explains the intent of this fake DT, the possible outcomes of
> > > not using the one provided by the platform and the right way of dealing
> > > with DTs for the platform.
> >
> > This is the part that I too am still unhappy about. I do not want
> > reference or fake or whatever device trees in the U-Boot source tree.
> > We should be able to _remove_ the ones we have, that are not required,
> > with doc/board/...rst explaining how to get / view one. Not adding
> > more.
>
> So this is a key point for me and the reason I completely disagree
> with this approach. This proposal is working in the *exact* opposite
> direction and we'll never be able to get rid of device trees from
> U-Boot, even if at some point they move out of the kernel to a
> 'common' repo'. I'll just repeat what I've been saying since v1.
> Personally I'd be way happier if we could figure out were the specific
> U-Boot config nodes are needed and when are they needed. Based on
> what we figure out we could, pick up the device tree from a previous
> state bootloader and fix it up with our special nodes before we start
> using it, using internal DTS files (compiled to .dtbos or similar)
> that indeed belong in the u-boot tree.
I agree on that, I always felt like U-Boot is abusing the DT here for
its own purposes. If it needs to convey some configuration information,
it should do it separately. It can use the DTB *format* (hierarchically
organised key/value pairs), but this should not really be mingled with
the hardware information. Trusted-Firmware is using this idea: they use
the already included libfdt for parsing, but load the various config
"DTB"s separately. The "hw_config" DTB (as they call the actual DTB) is
treated separately.
Cheers,
Andre
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 16:33 ` [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option François Ozog
2021-12-02 16:38 ` Tom Rini
@ 2021-12-02 16:39 ` Simon Glass
2021-12-02 16:58 ` Peter Maydell
` (2 more replies)
1 sibling, 3 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-02 16:39 UTC (permalink / raw)
To: François Ozog
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons, Tom Rini,
Tuomas Tynkkynen, U-Boot Mailing List
Hi François,
On Thu, 2 Dec 2021 at 09:34, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon
>
> Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
>>
>> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
>> there are only three ways to obtain a devicetree:
>>
>> - OF_SEPARATE - the normal way, where the devicetree is built and
>> appended to U-Boot
>> - OF_EMBED - for development purposes, the devicetree is embedded in
>> the ELF file (also used for EFI)
>> - OF_BOARD - the board figures it out on its own
>>
>> The last one is currently set up so that no devicetree is needed at all
>> in the U-Boot tree. Most boards do provide one, but some don't. Some
>> don't even provide instructions on how to boot on the board.
>>
>> The problems with this approach are documented in another patch in this
>> series: "doc: Add documentation about devicetree usage"
>>
>> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
>> can obtain its devicetree at runtime, even it is has a devicetree built
>> in U-Boot. This is because U-Boot may be a second-stage bootloader and its
>> caller may have a better idea about the hardware available in the machine.
>> This is the case with a few QEMU boards, for example.
>>
>> So it makes no sense to have OF_BOARD as a 'choice'. It should be an
>> option, available with either OF_SEPARATE or OF_EMBED.
>>
>> This series makes this change, adding various missing devicetree files
>> (and placeholders) to make the build work.
>>
>> Note: If board maintainers are able to add their own patch to add the
>> files, some patches in this series can be dropped.
>>
>> It also provides a few qemu clean-ups discovered along the way. The
>> qemu-riscv64_spl problem is fixed.
>>
>> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>>
>> Changes in v6:
>> - Fix description of OF_BOARD so it refers just to the current state
>> - Explain that the 'two devicetrees' refers to two *control* devicetrees
>> - Expand the commit message based on comments
>> - Expand the commit message based on comments
>
> You haven’t addressed any concerns expressed on the mailing list.so I am not in favor of this new version either.
Please see the change log. I have addressed everything except the
fundamental disagreement we have.
> If you make a version without « fake DTs » as you name them, there are good advances in the documentation and other areas that would be better in mainline….
> If I am the only one thinking this way and the patch can be accepted, I would love there is a warning in capital letters at the top of the DTS fake files that explains the intent of this fake DT, the possible outcomes of not using the one provided by the platform and the right way of dealing with DTs for the platform.
The word 'fake' applies to only three of the boards (highbank, bcm7xxx
and octeontx), where I could not even figure out where to get a
devicetree. One might think this would be a significant problem!
Anyway yes I can add a comment to all the files, but please try to ask
for everything at once as there is a cost to continually reworking
this series.
Regards,
Simon
>>
>>
>> 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
>> - Merge RISC-V and ARM patches since they are similar
>> - Add new patches to clean up fdtdec_setup() and surrounds
>>
>> 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?'
>>
>> Simon Glass (25):
>> doc: Add documentation about devicetree usage
>> arm: qemu: Mention -nographic in the docs
>> arm: riscv: qemu: Explain how to extract the generated dt
>> arm: qemu: Add a devicetree file for qemu_arm
>> arm: qemu: Add a devicetree file for qemu_arm64
>> riscv: qemu: Add devicetree files for qemu_riscv32/64
>> arm: rpi: Add a devicetree file for rpi_4
>> arm: vexpress: Add a devicetree file for juno
>> arm: xenguest_arm64: Add a fake devicetree file
>> arm: octeontx: Add a fake devicetree file
>> arm: xilinx_versal_virt: Add a devicetree file
>> arm: bcm7xxx: Add a devicetree file
>> arm: qemu-ppce500: Add a devicetree file
>> arm: highbank: Add a fake devicetree file
>> fdt: Make OF_BOARD a bool option
>> Drop CONFIG_BINMAN_STANDALONE_FDT
>> doc: Update info on devicetree update
>> fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup()
>> fdt: Drop #ifdefs with MULTI_DTB_FIT
>> fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup()
>> fdt: Drop #ifdef around board_fdt_blob_setup()
>> fdt: Use if() for fdtcontroladdr check
>> fdt: Drop OF_CONTROL check in fdtdec_setup()
>> fdt: Drop remaining preprocessor macros in fdtdec_setup()
>> fdt: Don't call board_fdt_blob_setup() without OF_BOARD
>>
>> Makefile | 3 +-
>> arch/arm/dts/Makefile | 20 +-
>> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++
>> arch/arm/dts/bcm7xxx.dts | 15 +
>> arch/arm/dts/highbank.dts | 14 +
>> arch/arm/dts/juno-r2.dts | 1038 +++++++++++++
>> arch/arm/dts/octeontx.dts | 14 +
>> arch/arm/dts/qemu-arm.dts | 402 +++++
>> arch/arm/dts/qemu-arm64.dts | 381 +++++
>> arch/arm/dts/xenguest-arm64.dts | 15 +
>> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++
>> arch/powerpc/dts/Makefile | 1 +
>> arch/powerpc/dts/qemu-ppce500.dts | 264 ++++
>> arch/riscv/dts/Makefile | 2 +-
>> arch/riscv/dts/qemu-virt.dts | 8 -
>> arch/riscv/dts/qemu-virt32.dts | 217 +++
>> arch/riscv/dts/qemu-virt64.dts | 217 +++
>> configs/bcm7260_defconfig | 1 +
>> configs/bcm7445_defconfig | 1 +
>> configs/highbank_defconfig | 2 +-
>> configs/octeontx2_95xx_defconfig | 1 +
>> configs/octeontx2_96xx_defconfig | 1 +
>> configs/octeontx_81xx_defconfig | 1 +
>> configs/octeontx_83xx_defconfig | 1 +
>> configs/qemu-ppce500_defconfig | 2 +
>> configs/qemu-riscv32_defconfig | 1 +
>> configs/qemu-riscv32_smode_defconfig | 1 +
>> configs/qemu-riscv32_spl_defconfig | 4 +-
>> configs/qemu-riscv64_defconfig | 1 +
>> configs/qemu-riscv64_smode_defconfig | 1 +
>> configs/qemu-riscv64_spl_defconfig | 3 +-
>> configs/qemu_arm64_defconfig | 1 +
>> configs/qemu_arm_defconfig | 1 +
>> configs/rpi_4_32b_defconfig | 1 +
>> configs/rpi_4_defconfig | 1 +
>> configs/rpi_arm64_defconfig | 1 +
>> configs/vexpress_aemv8a_juno_defconfig | 1 +
>> configs/xenguest_arm64_defconfig | 2 +-
>> configs/xilinx_versal_virt_defconfig | 1 +
>> doc/board/emulation/qemu-arm.rst | 10 +-
>> doc/board/emulation/qemu-riscv.rst | 3 +
>> doc/develop/devicetree/dt_qemu.rst | 48 +
>> doc/develop/devicetree/dt_update.rst | 497 ++++++
>> doc/develop/devicetree/index.rst | 2 +
>> dts/Kconfig | 30 +-
>> include/asm-generic/global_data.h | 8 +
>> include/fdtdec.h | 21 +-
>> lib/fdtdec.c | 117 +-
>> tools/binman/binman.rst | 20 -
>> 49 files changed, 5538 insertions(+), 124 deletions(-)
>> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
>> create mode 100644 arch/arm/dts/bcm7xxx.dts
>> create mode 100644 arch/arm/dts/highbank.dts
>> create mode 100644 arch/arm/dts/juno-r2.dts
>> create mode 100644 arch/arm/dts/octeontx.dts
>> create mode 100644 arch/arm/dts/qemu-arm.dts
>> create mode 100644 arch/arm/dts/qemu-arm64.dts
>> create mode 100644 arch/arm/dts/xenguest-arm64.dts
>> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
>> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
>> delete mode 100644 arch/riscv/dts/qemu-virt.dts
>> create mode 100644 arch/riscv/dts/qemu-virt32.dts
>> create mode 100644 arch/riscv/dts/qemu-virt64.dts
>> create mode 100644 doc/develop/devicetree/dt_qemu.rst
>> create mode 100644 doc/develop/devicetree/dt_update.rst
>>
>> --
>> 2.34.0.rc2.393.gf8c9666880-goog
>>
> --
> François-Frédéric Ozog | Director Business Development
> T: +33.67221.6485
> francois.ozog@linaro.org | Skype: ffozog
>
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 16:39 ` Simon Glass
@ 2021-12-02 16:58 ` Peter Maydell
2021-12-02 16:59 ` François Ozog
2021-12-03 1:10 ` Andre Przywara
2 siblings, 0 replies; 136+ messages in thread
From: Peter Maydell @ 2021-12-02 16:58 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Sean Anderson, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tom Rini, Tuomas Tynkkynen,
U-Boot Mailing List
On Thu, 2 Dec 2021 at 16:40, Simon Glass <sjg@chromium.org> wrote:
> The word 'fake' applies to only three of the boards (highbank, bcm7xxx
> and octeontx), where I could not even figure out where to get a
> devicetree. One might think this would be a significant problem!
Isn't highbank
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/highbank.dts
?
-- PMM
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 16:39 ` Simon Glass
2021-12-02 16:58 ` Peter Maydell
@ 2021-12-02 16:59 ` François Ozog
2021-12-03 1:10 ` Andre Przywara
2 siblings, 0 replies; 136+ messages in thread
From: François Ozog @ 2021-12-02 16:59 UTC (permalink / raw)
To: Simon Glass
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons, Tom Rini,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Simon
Le jeu. 2 déc. 2021 à 17:40, Simon Glass <sjg@chromium.org> a écrit :
> Hi François,
>
> On Thu, 2 Dec 2021 at 09:34, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> > Hi Simon
> >
> > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> >> there are only three ways to obtain a devicetree:
> >>
> >> - OF_SEPARATE - the normal way, where the devicetree is built and
> >> appended to U-Boot
> >> - OF_EMBED - for development purposes, the devicetree is embedded in
> >> the ELF file (also used for EFI)
> >> - OF_BOARD - the board figures it out on its own
> >>
> >> The last one is currently set up so that no devicetree is needed at all
> >> in the U-Boot tree. Most boards do provide one, but some don't. Some
> >> don't even provide instructions on how to boot on the board.
> >>
> >> The problems with this approach are documented in another patch in this
> >> series: "doc: Add documentation about devicetree usage"
> >>
> >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> >> can obtain its devicetree at runtime, even it is has a devicetree built
> >> in U-Boot. This is because U-Boot may be a second-stage bootloader and
> its
> >> caller may have a better idea about the hardware available in the
> machine.
> >> This is the case with a few QEMU boards, for example.
> >>
> >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> >> option, available with either OF_SEPARATE or OF_EMBED.
> >>
> >> This series makes this change, adding various missing devicetree files
> >> (and placeholders) to make the build work.
> >>
> >> Note: If board maintainers are able to add their own patch to add the
> >> files, some patches in this series can be dropped.
> >>
> >> It also provides a few qemu clean-ups discovered along the way. The
> >> qemu-riscv64_spl problem is fixed.
> >>
> >> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >>
> >> Changes in v6:
> >> - Fix description of OF_BOARD so it refers just to the current state
> >> - Explain that the 'two devicetrees' refers to two *control* devicetrees
> >> - Expand the commit message based on comments
> >> - Expand the commit message based on comments
> >
> > You haven’t addressed any concerns expressed on the mailing list.so I am
> not in favor of this new version either.
>
> Please see the change log. I have addressed everything except the
> fundamental disagreement we have.
>
> > If you make a version without « fake DTs » as you name them, there are
> good advances in the documentation and other areas that would be better in
> mainline….
> > If I am the only one thinking this way and the patch can be accepted, I
> would love there is a warning in capital letters at the top of the DTS fake
> files that explains the intent of this fake DT, the possible outcomes of
> not using the one provided by the platform and the right way of dealing
> with DTs for the platform.
>
> The word 'fake' applies to only three of the boards (highbank, bcm7xxx
> and octeontx),
Qemu is another one, and then you will have all SystemReady compliant
boards.
> where I could not even figure out where to get a
> devicetree. One might think this would be a significant problem!
>
> Anyway yes I can add a comment to all the files, but please try to ask
> for everything at once as there is a cost to continually reworking
> this series.
I proposed this as a last resort if I was the only one with concerns. But
sounds like I am not the only one strongly opinionated here.
Another trick would be to use a “.dts.doc” extension so that it is not
compiled unless someone is knowingly deciding to use the fake DT for debug
purposes (the warning message is still valid). (This is an effort to
advance on the good things of the patch)
>
>
> Regards,
> Simon
>
> >>
> >>
> >> 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
> >> - Merge RISC-V and ARM patches since they are similar
> >> - Add new patches to clean up fdtdec_setup() and surrounds
> >>
> >> 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?'
> >>
> >> Simon Glass (25):
> >> doc: Add documentation about devicetree usage
> >> arm: qemu: Mention -nographic in the docs
> >> arm: riscv: qemu: Explain how to extract the generated dt
> >> arm: qemu: Add a devicetree file for qemu_arm
> >> arm: qemu: Add a devicetree file for qemu_arm64
> >> riscv: qemu: Add devicetree files for qemu_riscv32/64
> >> arm: rpi: Add a devicetree file for rpi_4
> >> arm: vexpress: Add a devicetree file for juno
> >> arm: xenguest_arm64: Add a fake devicetree file
> >> arm: octeontx: Add a fake devicetree file
> >> arm: xilinx_versal_virt: Add a devicetree file
> >> arm: bcm7xxx: Add a devicetree file
> >> arm: qemu-ppce500: Add a devicetree file
> >> arm: highbank: Add a fake devicetree file
> >> fdt: Make OF_BOARD a bool option
> >> Drop CONFIG_BINMAN_STANDALONE_FDT
> >> doc: Update info on devicetree update
> >> fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup()
> >> fdt: Drop #ifdefs with MULTI_DTB_FIT
> >> fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup()
> >> fdt: Drop #ifdef around board_fdt_blob_setup()
> >> fdt: Use if() for fdtcontroladdr check
> >> fdt: Drop OF_CONTROL check in fdtdec_setup()
> >> fdt: Drop remaining preprocessor macros in fdtdec_setup()
> >> fdt: Don't call board_fdt_blob_setup() without OF_BOARD
> >>
> >> Makefile | 3 +-
> >> arch/arm/dts/Makefile | 20 +-
> >> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++
> >> arch/arm/dts/bcm7xxx.dts | 15 +
> >> arch/arm/dts/highbank.dts | 14 +
> >> arch/arm/dts/juno-r2.dts | 1038 +++++++++++++
> >> arch/arm/dts/octeontx.dts | 14 +
> >> arch/arm/dts/qemu-arm.dts | 402 +++++
> >> arch/arm/dts/qemu-arm64.dts | 381 +++++
> >> arch/arm/dts/xenguest-arm64.dts | 15 +
> >> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++
> >> arch/powerpc/dts/Makefile | 1 +
> >> arch/powerpc/dts/qemu-ppce500.dts | 264 ++++
> >> arch/riscv/dts/Makefile | 2 +-
> >> arch/riscv/dts/qemu-virt.dts | 8 -
> >> arch/riscv/dts/qemu-virt32.dts | 217 +++
> >> arch/riscv/dts/qemu-virt64.dts | 217 +++
> >> configs/bcm7260_defconfig | 1 +
> >> configs/bcm7445_defconfig | 1 +
> >> configs/highbank_defconfig | 2 +-
> >> configs/octeontx2_95xx_defconfig | 1 +
> >> configs/octeontx2_96xx_defconfig | 1 +
> >> configs/octeontx_81xx_defconfig | 1 +
> >> configs/octeontx_83xx_defconfig | 1 +
> >> configs/qemu-ppce500_defconfig | 2 +
> >> configs/qemu-riscv32_defconfig | 1 +
> >> configs/qemu-riscv32_smode_defconfig | 1 +
> >> configs/qemu-riscv32_spl_defconfig | 4 +-
> >> configs/qemu-riscv64_defconfig | 1 +
> >> configs/qemu-riscv64_smode_defconfig | 1 +
> >> configs/qemu-riscv64_spl_defconfig | 3 +-
> >> configs/qemu_arm64_defconfig | 1 +
> >> configs/qemu_arm_defconfig | 1 +
> >> configs/rpi_4_32b_defconfig | 1 +
> >> configs/rpi_4_defconfig | 1 +
> >> configs/rpi_arm64_defconfig | 1 +
> >> configs/vexpress_aemv8a_juno_defconfig | 1 +
> >> configs/xenguest_arm64_defconfig | 2 +-
> >> configs/xilinx_versal_virt_defconfig | 1 +
> >> doc/board/emulation/qemu-arm.rst | 10 +-
> >> doc/board/emulation/qemu-riscv.rst | 3 +
> >> doc/develop/devicetree/dt_qemu.rst | 48 +
> >> doc/develop/devicetree/dt_update.rst | 497 ++++++
> >> doc/develop/devicetree/index.rst | 2 +
> >> dts/Kconfig | 30 +-
> >> include/asm-generic/global_data.h | 8 +
> >> include/fdtdec.h | 21 +-
> >> lib/fdtdec.c | 117 +-
> >> tools/binman/binman.rst | 20 -
> >> 49 files changed, 5538 insertions(+), 124 deletions(-)
> >> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> >> create mode 100644 arch/arm/dts/bcm7xxx.dts
> >> create mode 100644 arch/arm/dts/highbank.dts
> >> create mode 100644 arch/arm/dts/juno-r2.dts
> >> create mode 100644 arch/arm/dts/octeontx.dts
> >> create mode 100644 arch/arm/dts/qemu-arm.dts
> >> create mode 100644 arch/arm/dts/qemu-arm64.dts
> >> create mode 100644 arch/arm/dts/xenguest-arm64.dts
> >> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
> >> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
> >> delete mode 100644 arch/riscv/dts/qemu-virt.dts
> >> create mode 100644 arch/riscv/dts/qemu-virt32.dts
> >> create mode 100644 arch/riscv/dts/qemu-virt64.dts
> >> create mode 100644 doc/develop/devicetree/dt_qemu.rst
> >> create mode 100644 doc/develop/devicetree/dt_update.rst
> >>
> >> --
> >> 2.34.0.rc2.393.gf8c9666880-goog
> >>
> > --
> > François-Frédéric Ozog | Director Business Development
> > T: +33.67221.6485
> > francois.ozog@linaro.org | Skype: ffozog
> >
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 16:39 ` Simon Glass
2021-12-02 16:58 ` Peter Maydell
2021-12-02 16:59 ` François Ozog
@ 2021-12-03 1:10 ` Andre Przywara
2 siblings, 0 replies; 136+ messages in thread
From: Andre Przywara @ 2021-12-03 1:10 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons, Tom Rini,
Tuomas Tynkkynen, U-Boot Mailing List
On Thu, 2 Dec 2021 09:39:52 -0700
Simon Glass <sjg@chromium.org> wrote:
Hi,
wow, this thread quickly exploded, jumping in here randomly to add my
thoughts:
> Hi François,
>
> On Thu, 2 Dec 2021 at 09:34, François Ozog <francois.ozog@linaro.org> wrote:
> >
> > Hi Simon
> >
> > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> >> there are only three ways to obtain a devicetree:
> >>
> >> - OF_SEPARATE - the normal way, where the devicetree is built and
> >> appended to U-Boot
> >> - OF_EMBED - for development purposes, the devicetree is embedded in
> >> the ELF file (also used for EFI)
> >> - OF_BOARD - the board figures it out on its own
> >>
> >> The last one is currently set up so that no devicetree is needed at all
> >> in the U-Boot tree. Most boards do provide one, but some don't. Some
> >> don't even provide instructions on how to boot on the board.
> >>
> >> The problems with this approach are documented in another patch in this
> >> series: "doc: Add documentation about devicetree usage"
> >>
> >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> >> can obtain its devicetree at runtime, even it is has a devicetree built
> >> in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> >> caller may have a better idea about the hardware available in the machine.
> >> This is the case with a few QEMU boards, for example.
> >>
> >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> >> option, available with either OF_SEPARATE or OF_EMBED.
> >>
> >> This series makes this change, adding various missing devicetree files
> >> (and placeholders) to make the build work.
> >>
> >> Note: If board maintainers are able to add their own patch to add the
> >> files, some patches in this series can be dropped.
> >>
> >> It also provides a few qemu clean-ups discovered along the way. The
> >> qemu-riscv64_spl problem is fixed.
> >>
> >> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >>
> >> Changes in v6:
> >> - Fix description of OF_BOARD so it refers just to the current state
> >> - Explain that the 'two devicetrees' refers to two *control* devicetrees
> >> - Expand the commit message based on comments
> >> - Expand the commit message based on comments
> >
> > You haven’t addressed any concerns expressed on the mailing list.so I am not in favor of this new version either.
>
> Please see the change log. I have addressed everything except the
> fundamental disagreement we have.
>
> > If you make a version without « fake DTs » as you name them, there are good advances in the documentation and other areas that would be better in mainline….
> > If I am the only one thinking this way and the patch can be accepted, I would love there is a warning in capital letters at the top of the DTS fake files that explains the intent of this fake DT, the possible outcomes of not using the one provided by the platform and the right way of dealing with DTs for the platform.
>
> The word 'fake' applies to only three of the boards (highbank, bcm7xxx
> and octeontx), where I could not even figure out where to get a
> devicetree. One might think this would be a significant problem!
But why? Actually it's the exact opposite, Highbank is somewhat of a
(sadly abandoned) poster book child of DT usage:
Before the Cortex-A cores boot, the DTB gets loaded by the management
processor (ECME) from NOR flash into DRAM. There the memory node gets
populated, based on what the ECME detected (it has a DIMM slot!). Then
this DTB gets used by U-Boot, which adds the command line and initrd
information, based on user choices. And this is eventually consumed by
a kernel.
So the base DTB here is provided by the system, and software just
reacts to it - how it should be. The (arm64) Linux kernel works on this
idea: exactly *one* binary image, and the drivers that are needed by the
hardware get loaded based on DT information. The fact the .dts files
live in the kernel tree is more for practical reasons, because it
started there, we enhance DTs and should have a repo holding them, plus
all the review knowledge is in the kernel community.
Cheers,
Andre
P.S. I started writing some documentation for Highbank, to be
posted soonish.
>
> Anyway yes I can add a comment to all the files, but please try to ask
> for everything at once as there is a cost to continually reworking
> this series.
>
> Regards,
> Simon
>
> >>
> >>
> >> 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
> >> - Merge RISC-V and ARM patches since they are similar
> >> - Add new patches to clean up fdtdec_setup() and surrounds
> >>
> >> 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?'
> >>
> >> Simon Glass (25):
> >> doc: Add documentation about devicetree usage
> >> arm: qemu: Mention -nographic in the docs
> >> arm: riscv: qemu: Explain how to extract the generated dt
> >> arm: qemu: Add a devicetree file for qemu_arm
> >> arm: qemu: Add a devicetree file for qemu_arm64
> >> riscv: qemu: Add devicetree files for qemu_riscv32/64
> >> arm: rpi: Add a devicetree file for rpi_4
> >> arm: vexpress: Add a devicetree file for juno
> >> arm: xenguest_arm64: Add a fake devicetree file
> >> arm: octeontx: Add a fake devicetree file
> >> arm: xilinx_versal_virt: Add a devicetree file
> >> arm: bcm7xxx: Add a devicetree file
> >> arm: qemu-ppce500: Add a devicetree file
> >> arm: highbank: Add a fake devicetree file
> >> fdt: Make OF_BOARD a bool option
> >> Drop CONFIG_BINMAN_STANDALONE_FDT
> >> doc: Update info on devicetree update
> >> fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup()
> >> fdt: Drop #ifdefs with MULTI_DTB_FIT
> >> fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup()
> >> fdt: Drop #ifdef around board_fdt_blob_setup()
> >> fdt: Use if() for fdtcontroladdr check
> >> fdt: Drop OF_CONTROL check in fdtdec_setup()
> >> fdt: Drop remaining preprocessor macros in fdtdec_setup()
> >> fdt: Don't call board_fdt_blob_setup() without OF_BOARD
> >>
> >> Makefile | 3 +-
> >> arch/arm/dts/Makefile | 20 +-
> >> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++
> >> arch/arm/dts/bcm7xxx.dts | 15 +
> >> arch/arm/dts/highbank.dts | 14 +
> >> arch/arm/dts/juno-r2.dts | 1038 +++++++++++++
> >> arch/arm/dts/octeontx.dts | 14 +
> >> arch/arm/dts/qemu-arm.dts | 402 +++++
> >> arch/arm/dts/qemu-arm64.dts | 381 +++++
> >> arch/arm/dts/xenguest-arm64.dts | 15 +
> >> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++
> >> arch/powerpc/dts/Makefile | 1 +
> >> arch/powerpc/dts/qemu-ppce500.dts | 264 ++++
> >> arch/riscv/dts/Makefile | 2 +-
> >> arch/riscv/dts/qemu-virt.dts | 8 -
> >> arch/riscv/dts/qemu-virt32.dts | 217 +++
> >> arch/riscv/dts/qemu-virt64.dts | 217 +++
> >> configs/bcm7260_defconfig | 1 +
> >> configs/bcm7445_defconfig | 1 +
> >> configs/highbank_defconfig | 2 +-
> >> configs/octeontx2_95xx_defconfig | 1 +
> >> configs/octeontx2_96xx_defconfig | 1 +
> >> configs/octeontx_81xx_defconfig | 1 +
> >> configs/octeontx_83xx_defconfig | 1 +
> >> configs/qemu-ppce500_defconfig | 2 +
> >> configs/qemu-riscv32_defconfig | 1 +
> >> configs/qemu-riscv32_smode_defconfig | 1 +
> >> configs/qemu-riscv32_spl_defconfig | 4 +-
> >> configs/qemu-riscv64_defconfig | 1 +
> >> configs/qemu-riscv64_smode_defconfig | 1 +
> >> configs/qemu-riscv64_spl_defconfig | 3 +-
> >> configs/qemu_arm64_defconfig | 1 +
> >> configs/qemu_arm_defconfig | 1 +
> >> configs/rpi_4_32b_defconfig | 1 +
> >> configs/rpi_4_defconfig | 1 +
> >> configs/rpi_arm64_defconfig | 1 +
> >> configs/vexpress_aemv8a_juno_defconfig | 1 +
> >> configs/xenguest_arm64_defconfig | 2 +-
> >> configs/xilinx_versal_virt_defconfig | 1 +
> >> doc/board/emulation/qemu-arm.rst | 10 +-
> >> doc/board/emulation/qemu-riscv.rst | 3 +
> >> doc/develop/devicetree/dt_qemu.rst | 48 +
> >> doc/develop/devicetree/dt_update.rst | 497 ++++++
> >> doc/develop/devicetree/index.rst | 2 +
> >> dts/Kconfig | 30 +-
> >> include/asm-generic/global_data.h | 8 +
> >> include/fdtdec.h | 21 +-
> >> lib/fdtdec.c | 117 +-
> >> tools/binman/binman.rst | 20 -
> >> 49 files changed, 5538 insertions(+), 124 deletions(-)
> >> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> >> create mode 100644 arch/arm/dts/bcm7xxx.dts
> >> create mode 100644 arch/arm/dts/highbank.dts
> >> create mode 100644 arch/arm/dts/juno-r2.dts
> >> create mode 100644 arch/arm/dts/octeontx.dts
> >> create mode 100644 arch/arm/dts/qemu-arm.dts
> >> create mode 100644 arch/arm/dts/qemu-arm64.dts
> >> create mode 100644 arch/arm/dts/xenguest-arm64.dts
> >> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
> >> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
> >> delete mode 100644 arch/riscv/dts/qemu-virt.dts
> >> create mode 100644 arch/riscv/dts/qemu-virt32.dts
> >> create mode 100644 arch/riscv/dts/qemu-virt64.dts
> >> create mode 100644 doc/develop/devicetree/dt_qemu.rst
> >> create mode 100644 doc/develop/devicetree/dt_update.rst
> >>
> >> --
> >> 2.34.0.rc2.393.gf8c9666880-goog
> >>
> > --
> > François-Frédéric Ozog | Director Business Development
> > T: +33.67221.6485
> > francois.ozog@linaro.org | Skype: ffozog
> >
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (23 preceding siblings ...)
2021-12-02 16:33 ` [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option François Ozog
@ 2021-12-02 16:47 ` Heinrich Schuchardt
2021-12-02 16:50 ` Simon Glass
2021-12-03 14:55 ` Tom Rini
[not found] ` <20211202155919.2429190-25-sjg@chromium.org>
26 siblings, 1 reply; 136+ messages in thread
From: Heinrich Schuchardt @ 2021-12-02 16:47 UTC (permalink / raw)
To: Simon Glass
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Jerry Van Baren, Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen,
U-Boot Mailing List, Heinrich Schuchardt
On 12/2/21 16:58, Simon Glass wrote:
> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> there are only three ways to obtain a devicetree:
>
> - OF_SEPARATE - the normal way, where the devicetree is built and
> appended to U-Boot
> - OF_EMBED - for development purposes, the devicetree is embedded in
> the ELF file (also used for EFI)
> - OF_BOARD - the board figures it out on its own
>
> The last one is currently set up so that no devicetree is needed at all
> in the U-Boot tree. Most boards do provide one, but some don't. Some
> don't even provide instructions on how to boot on the board.
>
> The problems with this approach are documented in another patch in this
> series: "doc: Add documentation about devicetree usage"
>
> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> can obtain its devicetree at runtime, even it is has a devicetree built
> in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> caller may have a better idea about the hardware available in the machine.
> This is the case with a few QEMU boards, for example.
>
> So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> option, available with either OF_SEPARATE or OF_EMBED.
>
> This series makes this change, adding various missing devicetree files
> (and placeholders) to make the build work.
>
> Note: If board maintainers are able to add their own patch to add the
> files, some patches in this series can be dropped.
>
> It also provides a few qemu clean-ups discovered along the way. The
> qemu-riscv64_spl problem is fixed.
Distros like Ubuntu are provided as preinstalled images using U-Boot to
launch Linux for usage with QEMU. A single image must be able to be
usable in the future irrespective of the QEMU command line device
configuration.
This means that the devicetree coming from QEMU must be accurately
parsed in U-Boot to setup the UEFI memory map. The number and type of
CPUs and the NUMA configuration must be accurate. All devices enabled
via the QEMU command line must be visible in the device-tree of Linux.
Please, observe that information like number of CPU cores, number and
type of block devices, namespace IDs used for NVMe drives, etc. cannot
be available at build time.
It this all guaranteed with this series? If not, this would
unfortunately imply a NAK.
Best regards
Heinrich
>
> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>
> Changes in v6:
> - Fix description of OF_BOARD so it refers just to the current state
> - Explain that the 'two devicetrees' refers to two *control* devicetrees
> - Expand the commit message based on comments
> - Expand the commit message based on comments
>
> 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
> - Merge RISC-V and ARM patches since they are similar
> - Add new patches to clean up fdtdec_setup() and surrounds
>
> 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?'
>
> Simon Glass (25):
> doc: Add documentation about devicetree usage
> arm: qemu: Mention -nographic in the docs
> arm: riscv: qemu: Explain how to extract the generated dt
> arm: qemu: Add a devicetree file for qemu_arm
> arm: qemu: Add a devicetree file for qemu_arm64
> riscv: qemu: Add devicetree files for qemu_riscv32/64
> arm: rpi: Add a devicetree file for rpi_4
> arm: vexpress: Add a devicetree file for juno
> arm: xenguest_arm64: Add a fake devicetree file
> arm: octeontx: Add a fake devicetree file
> arm: xilinx_versal_virt: Add a devicetree file
> arm: bcm7xxx: Add a devicetree file
> arm: qemu-ppce500: Add a devicetree file
> arm: highbank: Add a fake devicetree file
> fdt: Make OF_BOARD a bool option
> Drop CONFIG_BINMAN_STANDALONE_FDT
> doc: Update info on devicetree update
> fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup()
> fdt: Drop #ifdefs with MULTI_DTB_FIT
> fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup()
> fdt: Drop #ifdef around board_fdt_blob_setup()
> fdt: Use if() for fdtcontroladdr check
> fdt: Drop OF_CONTROL check in fdtdec_setup()
> fdt: Drop remaining preprocessor macros in fdtdec_setup()
> fdt: Don't call board_fdt_blob_setup() without OF_BOARD
>
> Makefile | 3 +-
> arch/arm/dts/Makefile | 20 +-
> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++
> arch/arm/dts/bcm7xxx.dts | 15 +
> arch/arm/dts/highbank.dts | 14 +
> arch/arm/dts/juno-r2.dts | 1038 +++++++++++++
> arch/arm/dts/octeontx.dts | 14 +
> arch/arm/dts/qemu-arm.dts | 402 +++++
> arch/arm/dts/qemu-arm64.dts | 381 +++++
> arch/arm/dts/xenguest-arm64.dts | 15 +
> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++
> arch/powerpc/dts/Makefile | 1 +
> arch/powerpc/dts/qemu-ppce500.dts | 264 ++++
> arch/riscv/dts/Makefile | 2 +-
> arch/riscv/dts/qemu-virt.dts | 8 -
> arch/riscv/dts/qemu-virt32.dts | 217 +++
> arch/riscv/dts/qemu-virt64.dts | 217 +++
> configs/bcm7260_defconfig | 1 +
> configs/bcm7445_defconfig | 1 +
> configs/highbank_defconfig | 2 +-
> configs/octeontx2_95xx_defconfig | 1 +
> configs/octeontx2_96xx_defconfig | 1 +
> configs/octeontx_81xx_defconfig | 1 +
> configs/octeontx_83xx_defconfig | 1 +
> configs/qemu-ppce500_defconfig | 2 +
> configs/qemu-riscv32_defconfig | 1 +
> configs/qemu-riscv32_smode_defconfig | 1 +
> configs/qemu-riscv32_spl_defconfig | 4 +-
> configs/qemu-riscv64_defconfig | 1 +
> configs/qemu-riscv64_smode_defconfig | 1 +
> configs/qemu-riscv64_spl_defconfig | 3 +-
> configs/qemu_arm64_defconfig | 1 +
> configs/qemu_arm_defconfig | 1 +
> configs/rpi_4_32b_defconfig | 1 +
> configs/rpi_4_defconfig | 1 +
> configs/rpi_arm64_defconfig | 1 +
> configs/vexpress_aemv8a_juno_defconfig | 1 +
> configs/xenguest_arm64_defconfig | 2 +-
> configs/xilinx_versal_virt_defconfig | 1 +
> doc/board/emulation/qemu-arm.rst | 10 +-
> doc/board/emulation/qemu-riscv.rst | 3 +
> doc/develop/devicetree/dt_qemu.rst | 48 +
> doc/develop/devicetree/dt_update.rst | 497 ++++++
> doc/develop/devicetree/index.rst | 2 +
> dts/Kconfig | 30 +-
> include/asm-generic/global_data.h | 8 +
> include/fdtdec.h | 21 +-
> lib/fdtdec.c | 117 +-
> tools/binman/binman.rst | 20 -
> 49 files changed, 5538 insertions(+), 124 deletions(-)
> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> create mode 100644 arch/arm/dts/bcm7xxx.dts
> create mode 100644 arch/arm/dts/highbank.dts
> create mode 100644 arch/arm/dts/juno-r2.dts
> create mode 100644 arch/arm/dts/octeontx.dts
> create mode 100644 arch/arm/dts/qemu-arm.dts
> create mode 100644 arch/arm/dts/qemu-arm64.dts
> create mode 100644 arch/arm/dts/xenguest-arm64.dts
> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
> delete mode 100644 arch/riscv/dts/qemu-virt.dts
> create mode 100644 arch/riscv/dts/qemu-virt32.dts
> create mode 100644 arch/riscv/dts/qemu-virt64.dts
> create mode 100644 doc/develop/devicetree/dt_qemu.rst
> create mode 100644 doc/develop/devicetree/dt_update.rst
>
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 16:47 ` Heinrich Schuchardt
@ 2021-12-02 16:50 ` Simon Glass
2021-12-03 10:03 ` Heinrich Schuchardt
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-02 16:50 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Jerry Van Baren, Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen,
U-Boot Mailing List, Heinrich Schuchardt
Hi Heinrich,
On Thu, 2 Dec 2021 at 09:47, Heinrich Schuchardt
<heinrich.schuchardt@canonical.com> wrote:
>
> On 12/2/21 16:58, Simon Glass wrote:
> > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > there are only three ways to obtain a devicetree:
> >
> > - OF_SEPARATE - the normal way, where the devicetree is built and
> > appended to U-Boot
> > - OF_EMBED - for development purposes, the devicetree is embedded in
> > the ELF file (also used for EFI)
> > - OF_BOARD - the board figures it out on its own
> >
> > The last one is currently set up so that no devicetree is needed at all
> > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > don't even provide instructions on how to boot on the board.
> >
> > The problems with this approach are documented in another patch in this
> > series: "doc: Add documentation about devicetree usage"
> >
> > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > can obtain its devicetree at runtime, even it is has a devicetree built
> > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > caller may have a better idea about the hardware available in the machine.
> > This is the case with a few QEMU boards, for example.
> >
> > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > option, available with either OF_SEPARATE or OF_EMBED.
> >
> > This series makes this change, adding various missing devicetree files
> > (and placeholders) to make the build work.
> >
> > Note: If board maintainers are able to add their own patch to add the
> > files, some patches in this series can be dropped.
> >
> > It also provides a few qemu clean-ups discovered along the way. The
> > qemu-riscv64_spl problem is fixed.
>
> Distros like Ubuntu are provided as preinstalled images using U-Boot to
> launch Linux for usage with QEMU. A single image must be able to be
> usable in the future irrespective of the QEMU command line device
> configuration.
>
> This means that the devicetree coming from QEMU must be accurately
> parsed in U-Boot to setup the UEFI memory map. The number and type of
> CPUs and the NUMA configuration must be accurate. All devices enabled
> via the QEMU command line must be visible in the device-tree of Linux.
>
> Please, observe that information like number of CPU cores, number and
> type of block devices, namespace IDs used for NVMe drives, etc. cannot
> be available at build time.
>
> It this all guaranteed with this series? If not, this would
> unfortunately imply a NAK.
Yes, it is guaranteed and there is no change there.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 16:50 ` Simon Glass
@ 2021-12-03 10:03 ` Heinrich Schuchardt
2021-12-06 15:22 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Heinrich Schuchardt @ 2021-12-03 10:03 UTC (permalink / raw)
To: Simon Glass
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Jerry Van Baren, Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen,
U-Boot Mailing List, Heinrich Schuchardt
On 12/2/21 17:50, Simon Glass wrote:
> Hi Heinrich,
>
> On Thu, 2 Dec 2021 at 09:47, Heinrich Schuchardt
> <heinrich.schuchardt@canonical.com> wrote:
>>
>> On 12/2/21 16:58, Simon Glass wrote:
>>> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
>>> there are only three ways to obtain a devicetree:
>>>
>>> - OF_SEPARATE - the normal way, where the devicetree is built and
>>> appended to U-Boot
>>> - OF_EMBED - for development purposes, the devicetree is embedded in
>>> the ELF file (also used for EFI)
>>> - OF_BOARD - the board figures it out on its own
>>>
>>> The last one is currently set up so that no devicetree is needed at all
>>> in the U-Boot tree. Most boards do provide one, but some don't. Some
>>> don't even provide instructions on how to boot on the board.
>>>
>>> The problems with this approach are documented in another patch in this
>>> series: "doc: Add documentation about devicetree usage"
>>>
>>> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
>>> can obtain its devicetree at runtime, even it is has a devicetree built
>>> in U-Boot. This is because U-Boot may be a second-stage bootloader and its
>>> caller may have a better idea about the hardware available in the machine.
>>> This is the case with a few QEMU boards, for example.
>>>
>>> So it makes no sense to have OF_BOARD as a 'choice'. It should be an
>>> option, available with either OF_SEPARATE or OF_EMBED.
>>>
>>> This series makes this change, adding various missing devicetree files
>>> (and placeholders) to make the build work.
>>>
>>> Note: If board maintainers are able to add their own patch to add the
>>> files, some patches in this series can be dropped.
>>>
>>> It also provides a few qemu clean-ups discovered along the way. The
>>> qemu-riscv64_spl problem is fixed.
>>
>> Distros like Ubuntu are provided as preinstalled images using U-Boot to
>> launch Linux for usage with QEMU. A single image must be able to be
>> usable in the future irrespective of the QEMU command line device
>> configuration.
>>
>> This means that the devicetree coming from QEMU must be accurately
>> parsed in U-Boot to setup the UEFI memory map. The number and type of
>> CPUs and the NUMA configuration must be accurate. All devices enabled
>> via the QEMU command line must be visible in the device-tree of Linux.
>>
>> Please, observe that information like number of CPU cores, number and
>> type of block devices, namespace IDs used for NVMe drives, etc. cannot
>> be available at build time.
>>
>> It this all guaranteed with this series? If not, this would
>> unfortunately imply a NAK.
>
> Yes, it is guaranteed and there is no change there.
Compiling qemu_arm64_defconfig yields dtbdump.efi. I used this to dump
the devicetree exposed to UEFI binaries. The number of CPUs and the
memory size matches the call parameters of QEMU. Emulated devices like
SCSI and NVMe drives and TPMv2 work inside U-Boot.
I also tested:
* qemu-riscv64_smode_defconfig as fw_jump payload for OpenSBI
* qemu-riscv64_spl_defconfig
and found no issues.
Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canaonical.com>
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 10:03 ` Heinrich Schuchardt
@ 2021-12-06 15:22 ` Simon Glass
0 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-06 15:22 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Mark Kettenis, Sean Anderson, Ilias Apalodimas, Tom Rini,
François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Jerry Van Baren, Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen,
U-Boot Mailing List, Heinrich Schuchardt
Hi Heinrich,
On Fri, 3 Dec 2021 at 03:04, Heinrich Schuchardt
<heinrich.schuchardt@canonical.com> wrote:
>
> On 12/2/21 17:50, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Thu, 2 Dec 2021 at 09:47, Heinrich Schuchardt
> > <heinrich.schuchardt@canonical.com> wrote:
> >>
> >> On 12/2/21 16:58, Simon Glass wrote:
> >>> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> >>> there are only three ways to obtain a devicetree:
> >>>
> >>> - OF_SEPARATE - the normal way, where the devicetree is built and
> >>> appended to U-Boot
> >>> - OF_EMBED - for development purposes, the devicetree is embedded in
> >>> the ELF file (also used for EFI)
> >>> - OF_BOARD - the board figures it out on its own
> >>>
> >>> The last one is currently set up so that no devicetree is needed at all
> >>> in the U-Boot tree. Most boards do provide one, but some don't. Some
> >>> don't even provide instructions on how to boot on the board.
> >>>
> >>> The problems with this approach are documented in another patch in this
> >>> series: "doc: Add documentation about devicetree usage"
> >>>
> >>> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> >>> can obtain its devicetree at runtime, even it is has a devicetree built
> >>> in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> >>> caller may have a better idea about the hardware available in the machine.
> >>> This is the case with a few QEMU boards, for example.
> >>>
> >>> So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> >>> option, available with either OF_SEPARATE or OF_EMBED.
> >>>
> >>> This series makes this change, adding various missing devicetree files
> >>> (and placeholders) to make the build work.
> >>>
> >>> Note: If board maintainers are able to add their own patch to add the
> >>> files, some patches in this series can be dropped.
> >>>
> >>> It also provides a few qemu clean-ups discovered along the way. The
> >>> qemu-riscv64_spl problem is fixed.
> >>
> >> Distros like Ubuntu are provided as preinstalled images using U-Boot to
> >> launch Linux for usage with QEMU. A single image must be able to be
> >> usable in the future irrespective of the QEMU command line device
> >> configuration.
> >>
> >> This means that the devicetree coming from QEMU must be accurately
> >> parsed in U-Boot to setup the UEFI memory map. The number and type of
> >> CPUs and the NUMA configuration must be accurate. All devices enabled
> >> via the QEMU command line must be visible in the device-tree of Linux.
> >>
> >> Please, observe that information like number of CPU cores, number and
> >> type of block devices, namespace IDs used for NVMe drives, etc. cannot
> >> be available at build time.
> >>
> >> It this all guaranteed with this series? If not, this would
> >> unfortunately imply a NAK.
> >
> > Yes, it is guaranteed and there is no change there.
>
> Compiling qemu_arm64_defconfig yields dtbdump.efi. I used this to dump
> the devicetree exposed to UEFI binaries. The number of CPUs and the
> memory size matches the call parameters of QEMU. Emulated devices like
> SCSI and NVMe drives and TPMv2 work inside U-Boot.
>
> I also tested:
>
> * qemu-riscv64_smode_defconfig as fw_jump payload for OpenSBI
> * qemu-riscv64_spl_defconfig
>
> and found no issues.
>
> Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canaonical.com>
Thank you for testing it. I have added your tag to the three patches
for QEMU devicetree (arm/riscv) since I don't have a way to add to the
whole series and I'm not sure it applies in any case.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-02 15:58 [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Simon Glass
` (24 preceding siblings ...)
2021-12-02 16:47 ` Heinrich Schuchardt
@ 2021-12-03 14:55 ` Tom Rini
2021-12-03 15:39 ` Simon Glass
[not found] ` <20211202155919.2429190-25-sjg@chromium.org>
26 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-03 14:55 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng, Jerry Van Baren,
Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen
[-- Attachment #1: Type: text/plain, Size: 2272 bytes --]
On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> there are only three ways to obtain a devicetree:
>
> - OF_SEPARATE - the normal way, where the devicetree is built and
> appended to U-Boot
> - OF_EMBED - for development purposes, the devicetree is embedded in
> the ELF file (also used for EFI)
> - OF_BOARD - the board figures it out on its own
>
> The last one is currently set up so that no devicetree is needed at all
> in the U-Boot tree. Most boards do provide one, but some don't. Some
> don't even provide instructions on how to boot on the board.
>
> The problems with this approach are documented in another patch in this
> series: "doc: Add documentation about devicetree usage"
>
> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> can obtain its devicetree at runtime, even it is has a devicetree built
> in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> caller may have a better idea about the hardware available in the machine.
> This is the case with a few QEMU boards, for example.
>
> So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> option, available with either OF_SEPARATE or OF_EMBED.
>
> This series makes this change, adding various missing devicetree files
> (and placeholders) to make the build work.
>
> Note: If board maintainers are able to add their own patch to add the
> files, some patches in this series can be dropped.
>
> It also provides a few qemu clean-ups discovered along the way. The
> qemu-riscv64_spl problem is fixed.
Note that I can't run-time test this as the last patch fails to apply
and is dependent on non-trivial missing changes ("/* The devicetree is
typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
and that's part of the unchanging context where things fail to apply).
So, here's my first bit of confusion. Today, I build for rpi_arm64 and
no dtb files are built. I run this on my Pi 3 and everything works.
With your series, I see all the dtbs have been built, and dts/dt.dtb and
u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 14:55 ` Tom Rini
@ 2021-12-03 15:39 ` Simon Glass
2021-12-03 15:57 ` Tom Rini
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-03 15:39 UTC (permalink / raw)
To: Tom Rini
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng, Jerry Van Baren,
Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen
Hi Tom,
On Fri, 3 Dec 2021 at 07:55, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
>
> > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > there are only three ways to obtain a devicetree:
> >
> > - OF_SEPARATE - the normal way, where the devicetree is built and
> > appended to U-Boot
> > - OF_EMBED - for development purposes, the devicetree is embedded in
> > the ELF file (also used for EFI)
> > - OF_BOARD - the board figures it out on its own
> >
> > The last one is currently set up so that no devicetree is needed at all
> > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > don't even provide instructions on how to boot on the board.
> >
> > The problems with this approach are documented in another patch in this
> > series: "doc: Add documentation about devicetree usage"
> >
> > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > can obtain its devicetree at runtime, even it is has a devicetree built
> > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > caller may have a better idea about the hardware available in the machine.
> > This is the case with a few QEMU boards, for example.
> >
> > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > option, available with either OF_SEPARATE or OF_EMBED.
> >
> > This series makes this change, adding various missing devicetree files
> > (and placeholders) to make the build work.
> >
> > Note: If board maintainers are able to add their own patch to add the
> > files, some patches in this series can be dropped.
> >
> > It also provides a few qemu clean-ups discovered along the way. The
> > qemu-riscv64_spl problem is fixed.
>
> Note that I can't run-time test this as the last patch fails to apply
> and is dependent on non-trivial missing changes ("/* The devicetree is
> typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> and that's part of the unchanging context where things fail to apply).
That code is the penultimate patch ("fdt: Drop remaining preprocessor
macros in fdtdec_setup()"). Did that patch apply OK? It is based on
-next and is at dm/ofb-working if you want to compare.
>
> So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> no dtb files are built. I run this on my Pi 3 and everything works.
> With your series, I see all the dtbs have been built, and dts/dt.dtb and
> u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
Yes, so long as OF_BOARD is enabled, which it is in this series. This
is basically the same as the situation with rpi3, except it uses
OF_EMBED (need to fix...)
If we get as far as the std passage stuff then it will print out the
source of the DT when it starts. If you like I could move three
patches into this series:
f88bd6a431a (HEAD -> ofb6) dm: core: Allow getting some basic stats
8121102a004 passage: Report the devicetree source
c9c791ddedf passage: Record where the devicetree came from
5a0b7505498 (dm/ofb-working, dm-public/ofb-working) fdt: Don't call
board_fdt_blob_setup() without OF_BOARD
Booting with rpi3 and rpi4 I get (see the "devicetree:" bit):
U-Boot 2022.01-rc3-00154-gf88bd6a431a (Dec 03 2021 - 08:32:41 -0700)
DRAM: 992 MiB
RPI 3 Model B (0xa02082)
Core: 61 devices, 11 uclasses, devicetree: embed
MMC: mmc@7e202000: 0, sdhci@7e300000: 1
Loading Environment from FAT... Unable to read "uboot.env" from
mmc0:1... In: serial
Out: vidconsole
Err: vidconsole
U-Boot 2022.01-rc3-00154-gf88bd6a431a (Dec 03 2021 - 08:33:43 -0700)
DRAM: 3.9 GiB
RPI 4 Model B (0xc03111)
Core: 197 devices, 13 uclasses, devicetree: board
MMC: mmcnr@7e300000: 1, mmc@7e340000: 0
Loading Environment from FAT... Unable to read "uboot.env" from
mmc0:1... In: serial
Out: vidconsole
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 15:39 ` Simon Glass
@ 2021-12-03 15:57 ` Tom Rini
2021-12-03 16:18 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-03 15:57 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng, Jerry Van Baren,
Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen
[-- Attachment #1: Type: text/plain, Size: 3286 bytes --]
On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 3 Dec 2021 at 07:55, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
> >
> > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > there are only three ways to obtain a devicetree:
> > >
> > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > appended to U-Boot
> > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > the ELF file (also used for EFI)
> > > - OF_BOARD - the board figures it out on its own
> > >
> > > The last one is currently set up so that no devicetree is needed at all
> > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > don't even provide instructions on how to boot on the board.
> > >
> > > The problems with this approach are documented in another patch in this
> > > series: "doc: Add documentation about devicetree usage"
> > >
> > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > caller may have a better idea about the hardware available in the machine.
> > > This is the case with a few QEMU boards, for example.
> > >
> > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > option, available with either OF_SEPARATE or OF_EMBED.
> > >
> > > This series makes this change, adding various missing devicetree files
> > > (and placeholders) to make the build work.
> > >
> > > Note: If board maintainers are able to add their own patch to add the
> > > files, some patches in this series can be dropped.
> > >
> > > It also provides a few qemu clean-ups discovered along the way. The
> > > qemu-riscv64_spl problem is fixed.
> >
> > Note that I can't run-time test this as the last patch fails to apply
> > and is dependent on non-trivial missing changes ("/* The devicetree is
> > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> > and that's part of the unchanging context where things fail to apply).
>
> That code is the penultimate patch ("fdt: Drop remaining preprocessor
> macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> -next and is at dm/ofb-working if you want to compare.
I just fetch'd and built that instead, thanks.
> > So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> > no dtb files are built. I run this on my Pi 3 and everything works.
> > With your series, I see all the dtbs have been built, and dts/dt.dtb and
> > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
>
> Yes, so long as OF_BOARD is enabled, which it is in this series. This
> is basically the same as the situation with rpi3, except it uses
> OF_EMBED (need to fix...)
OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
.config, so I'm telling it to use the run-time device tree. It will
never ever use this dtb, under any circumstance, right?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 15:57 ` Tom Rini
@ 2021-12-03 16:18 ` Simon Glass
2021-12-03 16:30 ` Tom Rini
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-03 16:18 UTC (permalink / raw)
To: Tom Rini
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng, Jerry Van Baren,
Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen
Hi Tom,
On Fri, 3 Dec 2021 at 08:57, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 3 Dec 2021 at 07:55, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
> > >
> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > there are only three ways to obtain a devicetree:
> > > >
> > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > appended to U-Boot
> > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > the ELF file (also used for EFI)
> > > > - OF_BOARD - the board figures it out on its own
> > > >
> > > > The last one is currently set up so that no devicetree is needed at all
> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > don't even provide instructions on how to boot on the board.
> > > >
> > > > The problems with this approach are documented in another patch in this
> > > > series: "doc: Add documentation about devicetree usage"
> > > >
> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > caller may have a better idea about the hardware available in the machine.
> > > > This is the case with a few QEMU boards, for example.
> > > >
> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > >
> > > > This series makes this change, adding various missing devicetree files
> > > > (and placeholders) to make the build work.
> > > >
> > > > Note: If board maintainers are able to add their own patch to add the
> > > > files, some patches in this series can be dropped.
> > > >
> > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > qemu-riscv64_spl problem is fixed.
> > >
> > > Note that I can't run-time test this as the last patch fails to apply
> > > and is dependent on non-trivial missing changes ("/* The devicetree is
> > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> > > and that's part of the unchanging context where things fail to apply).
> >
> > That code is the penultimate patch ("fdt: Drop remaining preprocessor
> > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > -next and is at dm/ofb-working if you want to compare.
>
> I just fetch'd and built that instead, thanks.
>
> > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> > > no dtb files are built. I run this on my Pi 3 and everything works.
> > > With your series, I see all the dtbs have been built, and dts/dt.dtb and
> > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
> >
> > Yes, so long as OF_BOARD is enabled, which it is in this series. This
> > is basically the same as the situation with rpi3, except it uses
> > OF_EMBED (need to fix...)
>
> OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
> rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
> .config, so I'm telling it to use the run-time device tree. It will
> never ever use this dtb, under any circumstance, right?
That's right, unless you disable OF_BOARD and build U-Boot again.
Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided.
I didn't even know that...yet another example of the confusion of the
current state.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 16:18 ` Simon Glass
@ 2021-12-03 16:30 ` Tom Rini
2021-12-03 16:45 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-03 16:30 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng, Jerry Van Baren,
Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen
[-- Attachment #1: Type: text/plain, Size: 4859 bytes --]
On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 3 Dec 2021 at 08:57, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 3 Dec 2021 at 07:55, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
> > > >
> > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > there are only three ways to obtain a devicetree:
> > > > >
> > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > appended to U-Boot
> > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > the ELF file (also used for EFI)
> > > > > - OF_BOARD - the board figures it out on its own
> > > > >
> > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > don't even provide instructions on how to boot on the board.
> > > > >
> > > > > The problems with this approach are documented in another patch in this
> > > > > series: "doc: Add documentation about devicetree usage"
> > > > >
> > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > caller may have a better idea about the hardware available in the machine.
> > > > > This is the case with a few QEMU boards, for example.
> > > > >
> > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > >
> > > > > This series makes this change, adding various missing devicetree files
> > > > > (and placeholders) to make the build work.
> > > > >
> > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > files, some patches in this series can be dropped.
> > > > >
> > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > qemu-riscv64_spl problem is fixed.
> > > >
> > > > Note that I can't run-time test this as the last patch fails to apply
> > > > and is dependent on non-trivial missing changes ("/* The devicetree is
> > > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> > > > and that's part of the unchanging context where things fail to apply).
> > >
> > > That code is the penultimate patch ("fdt: Drop remaining preprocessor
> > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > > -next and is at dm/ofb-working if you want to compare.
> >
> > I just fetch'd and built that instead, thanks.
> >
> > > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> > > > no dtb files are built. I run this on my Pi 3 and everything works.
> > > > With your series, I see all the dtbs have been built, and dts/dt.dtb and
> > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
> > >
> > > Yes, so long as OF_BOARD is enabled, which it is in this series. This
> > > is basically the same as the situation with rpi3, except it uses
> > > OF_EMBED (need to fix...)
> >
> > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
> > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
> > .config, so I'm telling it to use the run-time device tree. It will
> > never ever use this dtb, under any circumstance, right?
>
> That's right, unless you disable OF_BOARD and build U-Boot again.
And then it would fail to boot, because I'm on a 3, not a 4.
> Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided.
> I didn't even know that...yet another example of the confusion of the
> current state.
So, I'm trying to use this example here to lead to what I think is a
reasonable compromise. As you note, with CONFIG_OF_BOARD=y all of those
built trees, and the embedded tree, will not ever be used. But it makes
the make logic a tiny bit easier to have some tree, not no tree. Why
can't we:
- When CONFIG_OF_BOARD=y not build those trees as part of "all"
(individual rules should still work).
- For linking, use an empty minimal valid dts.
Because when CONFIG_OF_BOARD=y you will HAVE TO change the configuration
to know what device tree you want it to even use if you disable
CONFIG_OF_BOARD. You cannot assume that CONFIG_DEFAULT_DEVICE_TREE is
correct, which is why it's unset currently.
Does this make sense? If not, why not? And I have thoughts about other
platforms too, but I want to stick with a fairly concrete example first.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 16:30 ` Tom Rini
@ 2021-12-03 16:45 ` Simon Glass
2021-12-03 19:25 ` Tom Rini
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-03 16:45 UTC (permalink / raw)
To: Tom Rini
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng, Jerry Van Baren,
Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen
is generallyHi Tom,
On Fri, 3 Dec 2021 at 09:31, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 3 Dec 2021 at 08:57, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 3 Dec 2021 at 07:55, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
> > > > >
> > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > there are only three ways to obtain a devicetree:
> > > > > >
> > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > appended to U-Boot
> > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > the ELF file (also used for EFI)
> > > > > > - OF_BOARD - the board figures it out on its own
> > > > > >
> > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > don't even provide instructions on how to boot on the board.
> > > > > >
> > > > > > The problems with this approach are documented in another patch in this
> > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > >
> > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > This is the case with a few QEMU boards, for example.
> > > > > >
> > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > >
> > > > > > This series makes this change, adding various missing devicetree files
> > > > > > (and placeholders) to make the build work.
> > > > > >
> > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > files, some patches in this series can be dropped.
> > > > > >
> > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > qemu-riscv64_spl problem is fixed.
> > > > >
> > > > > Note that I can't run-time test this as the last patch fails to apply
> > > > > and is dependent on non-trivial missing changes ("/* The devicetree is
> > > > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> > > > > and that's part of the unchanging context where things fail to apply).
> > > >
> > > > That code is the penultimate patch ("fdt: Drop remaining preprocessor
> > > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > > > -next and is at dm/ofb-working if you want to compare.
> > >
> > > I just fetch'd and built that instead, thanks.
> > >
> > > > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> > > > > no dtb files are built. I run this on my Pi 3 and everything works.
> > > > > With your series, I see all the dtbs have been built, and dts/dt.dtb and
> > > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
> > > >
> > > > Yes, so long as OF_BOARD is enabled, which it is in this series. This
> > > > is basically the same as the situation with rpi3, except it uses
> > > > OF_EMBED (need to fix...)
> > >
> > > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
> > > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
> > > .config, so I'm telling it to use the run-time device tree. It will
> > > never ever use this dtb, under any circumstance, right?
> >
> > That's right, unless you disable OF_BOARD and build U-Boot again.
>
> And then it would fail to boot, because I'm on a 3, not a 4.
Yes, but that's because the DT is wrong, right? The build builds all
the different DTs but just selects one (the default) to put into
u-boot.dtb and u-boot.bin
We could make it generate images for all of them. I have thought about
that as it stops us needing different boards just to handle having
multiple DT options. But I haven't really looked at it.
>
> > Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided.
> > I didn't even know that...yet another example of the confusion of the
> > current state.
>
> So, I'm trying to use this example here to lead to what I think is a
> reasonable compromise. As you note, with CONFIG_OF_BOARD=y all of those
> built trees, and the embedded tree, will not ever be used. But it makes
(except during development and for build testing)
> the make logic a tiny bit easier to have some tree, not no tree. Why
> can't we:
> - When CONFIG_OF_BOARD=y not build those trees as part of "all"
> (individual rules should still work).
> - For linking, use an empty minimal valid dts.
>
> Because when CONFIG_OF_BOARD=y you will HAVE TO change the configuration
> to know what device tree you want it to even use if you disable
> CONFIG_OF_BOARD. You cannot assume that CONFIG_DEFAULT_DEVICE_TREE is
> correct, which is why it's unset currently.
>
> Does this make sense? If not, why not? And I have thoughts about other
> platforms too, but I want to stick with a fairly concrete example first.
Well CONFIG_DEFAULT_DEVICE_TREE is generally correct. As above we
could support generating multiple outputs, perhaps. I think Binman
would be the best way to handle that, e.g. from a list of DTs.
It makes some sense.
I don't agree with not even building the trees. We should continue to
build all the related DTs so we know that switching off OF_BOARD will
work. If it isn't built, people won't even add it, right?
Also you are going back to OF_BOARD having build-time effects, which I
want to get away from. It should be a run-time option. That is my
bottom line, really. In the future I hope that standard passage will
provide a DT and we will be able to display where it came from,
including what program provided it, for example. But disabling
OF_BOARD should simply make the built-in one kick in. If it isn't
there, how can it?
Don't you find the current situation really confusing? It just makes
no sense to me.
Are you looking to have an empty DT in u-boot.bin? Perhaps we should
provide a way to do that? But what is driving that desire?
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 16:45 ` Simon Glass
@ 2021-12-03 19:25 ` Tom Rini
2021-12-04 1:01 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-03 19:25 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng, Jerry Van Baren,
Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen
[-- Attachment #1: Type: text/plain, Size: 9479 bytes --]
On Fri, Dec 03, 2021 at 09:45:12AM -0700, Simon Glass wrote:
> is generallyHi Tom,
>
> On Fri, 3 Dec 2021 at 09:31, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 3 Dec 2021 at 08:57, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Fri, 3 Dec 2021 at 07:55, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
> > > > > >
> > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > there are only three ways to obtain a devicetree:
> > > > > > >
> > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > appended to U-Boot
> > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > the ELF file (also used for EFI)
> > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > >
> > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > >
> > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > >
> > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > >
> > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > >
> > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > (and placeholders) to make the build work.
> > > > > > >
> > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > files, some patches in this series can be dropped.
> > > > > > >
> > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > >
> > > > > > Note that I can't run-time test this as the last patch fails to apply
> > > > > > and is dependent on non-trivial missing changes ("/* The devicetree is
> > > > > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> > > > > > and that's part of the unchanging context where things fail to apply).
> > > > >
> > > > > That code is the penultimate patch ("fdt: Drop remaining preprocessor
> > > > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > > > > -next and is at dm/ofb-working if you want to compare.
> > > >
> > > > I just fetch'd and built that instead, thanks.
> > > >
> > > > > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> > > > > > no dtb files are built. I run this on my Pi 3 and everything works.
> > > > > > With your series, I see all the dtbs have been built, and dts/dt.dtb and
> > > > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
> > > > >
> > > > > Yes, so long as OF_BOARD is enabled, which it is in this series. This
> > > > > is basically the same as the situation with rpi3, except it uses
> > > > > OF_EMBED (need to fix...)
> > > >
> > > > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
> > > > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
> > > > .config, so I'm telling it to use the run-time device tree. It will
> > > > never ever use this dtb, under any circumstance, right?
> > >
> > > That's right, unless you disable OF_BOARD and build U-Boot again.
> >
> > And then it would fail to boot, because I'm on a 3, not a 4.
>
> Yes, but that's because the DT is wrong, right? The build builds all
> the different DTs but just selects one (the default) to put into
> u-boot.dtb and u-boot.bin
>
> We could make it generate images for all of them. I have thought about
> that as it stops us needing different boards just to handle having
> multiple DT options. But I haven't really looked at it.
It would be wrong because it's the wrong device tree for the hardware,
yes. And we don't want to build N different binaries, the point of the
target is that everything works like a good data-driven platform should.
One binary, N platforms work because we get the configuration at
run-time.
> > > Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided.
> > > I didn't even know that...yet another example of the confusion of the
> > > current state.
> >
> > So, I'm trying to use this example here to lead to what I think is a
> > reasonable compromise. As you note, with CONFIG_OF_BOARD=y all of those
> > built trees, and the embedded tree, will not ever be used. But it makes
>
> (except during development and for build testing)
But that's not relevant. For development you're changing the config.
And for build testing zero device trees should be built, if zero device
trees are included.
> > the make logic a tiny bit easier to have some tree, not no tree. Why
> > can't we:
> > - When CONFIG_OF_BOARD=y not build those trees as part of "all"
> > (individual rules should still work).
> > - For linking, use an empty minimal valid dts.
> >
> > Because when CONFIG_OF_BOARD=y you will HAVE TO change the configuration
> > to know what device tree you want it to even use if you disable
> > CONFIG_OF_BOARD. You cannot assume that CONFIG_DEFAULT_DEVICE_TREE is
> > correct, which is why it's unset currently.
> >
> > Does this make sense? If not, why not? And I have thoughts about other
> > platforms too, but I want to stick with a fairly concrete example first.
>
> Well CONFIG_DEFAULT_DEVICE_TREE is generally correct. As above we
> could support generating multiple outputs, perhaps. I think Binman
> would be the best way to handle that, e.g. from a list of DTs.
It's correct when we set it to non-zero, yes. But otherwise it's empty
on purpose. And we already have a mechanism for when there's a single
dtb that's common enough for N platforms, and we select the right one at
run time. Nothing new needed here.
> It makes some sense.
>
> I don't agree with not even building the trees. We should continue to
> build all the related DTs so we know that switching off OF_BOARD will
> work. If it isn't built, people won't even add it, right?
We don't know that it will work just because we built some device trees.
There's not even for certain device trees to add to the source trees.
> Also you are going back to OF_BOARD having build-time effects, which I
> want to get away from. It should be a run-time option. That is my
> bottom line, really. In the future I hope that standard passage will
> provide a DT and we will be able to display where it came from,
> including what program provided it, for example. But disabling
> OF_BOARD should simply make the built-in one kick in. If it isn't
> there, how can it?
I don't see how run-time option makes any sense when we know that there
are cases where it's never the correct choice. You keep aiming to
optimize a corner of the U-Boot internal developer workflow. That I
think is maybe the big center of the disagreement.
> Don't you find the current situation really confusing? It just makes
> no sense to me.
There's things that need to be cleaned up because we have some small
number of platforms that went off and did their own thing. But largely
yes, things make sense to me. We have:
- We embedded the device tree that will configure U-Boot, because there
is no way for the hardware to have provided us one.
- We do not embed the device tree that will configure U-Boot, because
there is already one present in memory for us to use.
Then we have the developer option of:
- We embedded the device tree that will configure U-Boot, because we're
developing something.
> Are you looking to have an empty DT in u-boot.bin? Perhaps we should
> provide a way to do that? But what is driving that desire?
I'm looking for ways to convince you that we do not need to include a
device tree in the binary. There's a growing set of devices where the
device tree exists with the device. If it's missing, that's a huge
fatal error we can't do all that much about. If we need to do something
to that device tree for U-Boot, yes, fine, we should make it straight
forward for the developer to do that. But that's not the common case!
I guess another part of the problem is that historically almost all
platforms were in the first case I list above, no run time provided
device tree, so we took the kernel one and added our bindings to it.
Now we're being bit by the growing number of platforms that are the
second case, and how do we get our properties in there, and which ones
even make sense to do that for.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-03 19:25 ` Tom Rini
@ 2021-12-04 1:01 ` Simon Glass
2021-12-04 13:52 ` Tom Rini
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-04 1:01 UTC (permalink / raw)
To: Tom Rini
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng, Jerry Van Baren,
Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen
Hi Tom,
On Fri, 3 Dec 2021 at 12:25, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Dec 03, 2021 at 09:45:12AM -0700, Simon Glass wrote:
> > is generallyHi Tom,
> >
> > On Fri, 3 Dec 2021 at 09:31, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 3 Dec 2021 at 08:57, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Fri, 3 Dec 2021 at 07:55, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
> > > > > > >
> > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > > > > there are only three ways to obtain a devicetree:
> > > > > > > >
> > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > > > > appended to U-Boot
> > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > > > > the ELF file (also used for EFI)
> > > > > > > > - OF_BOARD - the board figures it out on its own
> > > > > > > >
> > > > > > > > The last one is currently set up so that no devicetree is needed at all
> > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > > > > don't even provide instructions on how to boot on the board.
> > > > > > > >
> > > > > > > > The problems with this approach are documented in another patch in this
> > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > >
> > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > > > > caller may have a better idea about the hardware available in the machine.
> > > > > > > > This is the case with a few QEMU boards, for example.
> > > > > > > >
> > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > >
> > > > > > > > This series makes this change, adding various missing devicetree files
> > > > > > > > (and placeholders) to make the build work.
> > > > > > > >
> > > > > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > > > > files, some patches in this series can be dropped.
> > > > > > > >
> > > > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > >
> > > > > > > Note that I can't run-time test this as the last patch fails to apply
> > > > > > > and is dependent on non-trivial missing changes ("/* The devicetree is
> > > > > > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> > > > > > > and that's part of the unchanging context where things fail to apply).
> > > > > >
> > > > > > That code is the penultimate patch ("fdt: Drop remaining preprocessor
> > > > > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > > > > > -next and is at dm/ofb-working if you want to compare.
> > > > >
> > > > > I just fetch'd and built that instead, thanks.
> > > > >
> > > > > > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> > > > > > > no dtb files are built. I run this on my Pi 3 and everything works.
> > > > > > > With your series, I see all the dtbs have been built, and dts/dt.dtb and
> > > > > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
> > > > > >
> > > > > > Yes, so long as OF_BOARD is enabled, which it is in this series. This
> > > > > > is basically the same as the situation with rpi3, except it uses
> > > > > > OF_EMBED (need to fix...)
> > > > >
> > > > > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
> > > > > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
> > > > > .config, so I'm telling it to use the run-time device tree. It will
> > > > > never ever use this dtb, under any circumstance, right?
> > > >
> > > > That's right, unless you disable OF_BOARD and build U-Boot again.
> > >
> > > And then it would fail to boot, because I'm on a 3, not a 4.
> >
> > Yes, but that's because the DT is wrong, right? The build builds all
> > the different DTs but just selects one (the default) to put into
> > u-boot.dtb and u-boot.bin
> >
> > We could make it generate images for all of them. I have thought about
> > that as it stops us needing different boards just to handle having
> > multiple DT options. But I haven't really looked at it.
>
> It would be wrong because it's the wrong device tree for the hardware,
> yes. And we don't want to build N different binaries, the point of the
> target is that everything works like a good data-driven platform should.
> One binary, N platforms work because we get the configuration at
> run-time.
That sounds fine then. I don't think we have a run-time problem.
>
> > > > Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided.
> > > > I didn't even know that...yet another example of the confusion of the
> > > > current state.
> > >
> > > So, I'm trying to use this example here to lead to what I think is a
> > > reasonable compromise. As you note, with CONFIG_OF_BOARD=y all of those
> > > built trees, and the embedded tree, will not ever be used. But it makes
> >
> > (except during development and for build testing)
>
> But that's not relevant. For development you're changing the config.
> And for build testing zero device trees should be built, if zero device
> trees are included.
There is where we don't agree.
>
> > > the make logic a tiny bit easier to have some tree, not no tree. Why
> > > can't we:
> > > - When CONFIG_OF_BOARD=y not build those trees as part of "all"
> > > (individual rules should still work).
> > > - For linking, use an empty minimal valid dts.
> > >
> > > Because when CONFIG_OF_BOARD=y you will HAVE TO change the configuration
> > > to know what device tree you want it to even use if you disable
> > > CONFIG_OF_BOARD. You cannot assume that CONFIG_DEFAULT_DEVICE_TREE is
> > > correct, which is why it's unset currently.
> > >
> > > Does this make sense? If not, why not? And I have thoughts about other
> > > platforms too, but I want to stick with a fairly concrete example first.
> >
> > Well CONFIG_DEFAULT_DEVICE_TREE is generally correct. As above we
> > could support generating multiple outputs, perhaps. I think Binman
> > would be the best way to handle that, e.g. from a list of DTs.
>
> It's correct when we set it to non-zero, yes. But otherwise it's empty
> on purpose. And we already have a mechanism for when there's a single
> dtb that's common enough for N platforms, and we select the right one at
> run time. Nothing new needed here.
OK good.
>
> > It makes some sense.
> >
> > I don't agree with not even building the trees. We should continue to
> > build all the related DTs so we know that switching off OF_BOARD will
> > work. If it isn't built, people won't even add it, right?
>
> We don't know that it will work just because we built some device trees.
> There's not even for certain device trees to add to the source trees.
It needs to work, at least to a basic level. That's my point. We need
to make this discoverable.
>
> > Also you are going back to OF_BOARD having build-time effects, which I
> > want to get away from. It should be a run-time option. That is my
> > bottom line, really. In the future I hope that standard passage will
> > provide a DT and we will be able to display where it came from,
> > including what program provided it, for example. But disabling
> > OF_BOARD should simply make the built-in one kick in. If it isn't
> > there, how can it?
>
> I don't see how run-time option makes any sense when we know that there
> are cases where it's never the correct choice. You keep aiming to
> optimize a corner of the U-Boot internal developer workflow. That I
> think is maybe the big center of the disagreement.
Yes, indeed.
>
> > Don't you find the current situation really confusing? It just makes
> > no sense to me.
>
> There's things that need to be cleaned up because we have some small
> number of platforms that went off and did their own thing. But largely
> yes, things make sense to me. We have:
> - We embedded the device tree that will configure U-Boot, because there
> is no way for the hardware to have provided us one.
> - We do not embed the device tree that will configure U-Boot, because
> there is already one present in memory for us to use.
>
> Then we have the developer option of:
> - We embedded the device tree that will configure U-Boot, because we're
> developing something.
Yes, agreed those are the cases. To me this needs to be a run-time choice.
>
> > Are you looking to have an empty DT in u-boot.bin? Perhaps we should
> > provide a way to do that? But what is driving that desire?
>
> I'm looking for ways to convince you that we do not need to include a
> device tree in the binary. There's a growing set of devices where the
> device tree exists with the device. If it's missing, that's a huge
> fatal error we can't do all that much about. If we need to do something
> to that device tree for U-Boot, yes, fine, we should make it straight
> forward for the developer to do that. But that's not the common case!
Well we could add another Kconfig which tells U-Boot not to include a
devicetree in u-boot.bin, if that would resolve this?
I just want to make sure that we always build the devicetrees and that
it is easy for a knowledgeable dev to switch over to use them, without
spelunking through dozens of other projects to discover the secret DT
that no one will tell us about.
>
> I guess another part of the problem is that historically almost all
> platforms were in the first case I list above, no run time provided
> device tree, so we took the kernel one and added our bindings to it.
> Now we're being bit by the growing number of platforms that are the
> second case, and how do we get our properties in there, and which ones
> even make sense to do that for.
I think upstreaming the bindings is the solution there. I've made a
start, but we need to make progress with this series and all the other
things in flight. I think a lot of people want U-Boot to not have a
devicetree source files in it for ARMv8 platforms. I am strongly
opposed to that. I've laid out my reasons very clearly in the past. I
think this is a good summary:
https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
I believe I have been consistent in this although with all the
discussion I'm really not sure anymore.
The problem is that various people have various views about how U-Boot
should work with devicetree. I strongly believe that until we have
bindings upstream, a central repo for DTs with easy downloading for
builds, automated validation, among other things, we must maintain the
devicetree in U-Boot. Just from the POV of energy expended, I do not
want to be arguing with the Linaro folks about what U-Boot is allowed
to do every month for the next two years. I'd rather set out the stall
now and then deal with the problems it causes from that perspective.
As you know, I also think many of the issues raised with my proposal
here are not terminal and in fact are not even going to matter in
practice. I believe they can be dealt with collaboratively over time
as they come up. But what cannot be done, is rewriting U-Boot to fit
with 6 other projects with their own idea of what U-Boot should be.
Slightly sideways, looking into the future, everyone is going to
become heartily sick of the complexity of building these images.
Having something like Binman which can stitch things together can
help. I think the meson RFC shows how this could be done to the
benefit of all. At that point the DT is available and can be poked
into various places in the image, or made available as needed. See
next email.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-04 1:01 ` Simon Glass
@ 2021-12-04 13:52 ` Tom Rini
2021-12-04 15:20 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-04 13:52 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng, Jerry Van Baren,
Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen
[-- Attachment #1: Type: text/plain, Size: 5668 bytes --]
On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
[huge snip]
> > There's things that need to be cleaned up because we have some small
> > number of platforms that went off and did their own thing. But largely
> > yes, things make sense to me. We have:
> > - We embedded the device tree that will configure U-Boot, because there
> > is no way for the hardware to have provided us one.
> > - We do not embed the device tree that will configure U-Boot, because
> > there is already one present in memory for us to use.
> >
> > Then we have the developer option of:
> > - We embedded the device tree that will configure U-Boot, because we're
> > developing something.
>
> Yes, agreed those are the cases. To me this needs to be a run-time choice.
But it's not possible. That's the problem we keep going around and
around about. People keep raising real life examples where you cannot
make a run time choice between "device tree we're passed at run time"
and "device tree we're compiled with".
And it's not helpful. It is ALWAYS the case that we know that we want
to override the run time device tree with our own, because it's a
developer developing things or it's a user / production case where we
must use the provided tree. NOT doing that is what leads to madness
like we see for example on Pi where if we don't use the passed tree we
still need to copy X/Y/Z out of it.
> > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should
> > > provide a way to do that? But what is driving that desire?
> >
> > I'm looking for ways to convince you that we do not need to include a
> > device tree in the binary. There's a growing set of devices where the
> > device tree exists with the device. If it's missing, that's a huge
> > fatal error we can't do all that much about. If we need to do something
> > to that device tree for U-Boot, yes, fine, we should make it straight
> > forward for the developer to do that. But that's not the common case!
>
> Well we could add another Kconfig which tells U-Boot not to include a
> devicetree in u-boot.bin, if that would resolve this?
>
> I just want to make sure that we always build the devicetrees and that
> it is easy for a knowledgeable dev to switch over to use them, without
> spelunking through dozens of other projects to discover the secret DT
> that no one will tell us about.
Should we demand better documentation for boards? Yes. But it's still
a valid case to have zero device trees for a given platform in-tree.
Xen is an example of this. QEMU is an example of this. Platforms need
to work without adding special tweaks for us. Maybe that means some
features can't be tested in QEMU-as-virtual-platform and only in
QEMU-faithfully-emulating-specific-physical-platforms.
> > I guess another part of the problem is that historically almost all
> > platforms were in the first case I list above, no run time provided
> > device tree, so we took the kernel one and added our bindings to it.
> > Now we're being bit by the growing number of platforms that are the
> > second case, and how do we get our properties in there, and which ones
> > even make sense to do that for.
>
> I think upstreaming the bindings is the solution there. I've made a
> start, but we need to make progress with this series and all the other
> things in flight. I think a lot of people want U-Boot to not have a
> devicetree source files in it for ARMv8 platforms. I am strongly
> opposed to that. I've laid out my reasons very clearly in the past. I
> think this is a good summary:
>
> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
Yes, there are some ARMv8 platforms we will have to have the source
files to, in tree, because they won't come to us at run time. But
others we won't for practical reasons, namely that we can't statically
provide something that exists dynamically without massive duplication of
code or just taking things from that passed to us tree.
> I believe I have been consistent in this although with all the
> discussion I'm really not sure anymore.
Yes, everyone has been consistent in these discussions.
> The problem is that various people have various views about how U-Boot
> should work with devicetree. I strongly believe that until we have
> bindings upstream, a central repo for DTs with easy downloading for
> builds, automated validation, among other things, we must maintain the
> devicetree in U-Boot. Just from the POV of energy expended, I do not
> want to be arguing with the Linaro folks about what U-Boot is allowed
> to do every month for the next two years. I'd rather set out the stall
> now and then deal with the problems it causes from that perspective.
The problems of the last going on 12 years won't be solved instantly.
The conflict as I see it is that you're insisting that all platforms
must have statically usable device trees, and I (and I believe others)
are saying that's unreasonable in cases where the trees are dynamic at
heart, lets just ensure we have good enough documentation for them,
which we don't today.
To be clear and pick an example, I don't want Pi dts files in U-Boot,
but, OK, it's an easy enough case to sync them up and so long as we
aren't yet at the "now we pick at run time between compiled in or passed
to us dtb", I can accept them in tree, but not in the resulting binary
for OF_CONTROL=y. But as the Xen folks have also noted, there's no
reasonable tree to include there. It does need to be better documented
how to fire it up however, in our sources.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-04 13:52 ` Tom Rini
@ 2021-12-04 15:20 ` Simon Glass
2021-12-04 15:58 ` Ilias Apalodimas
` (3 more replies)
0 siblings, 4 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-04 15:20 UTC (permalink / raw)
To: Tom Rini
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng, Jerry Van Baren,
Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen
Hi Tom,
On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
>
> [huge snip]
> > > There's things that need to be cleaned up because we have some small
> > > number of platforms that went off and did their own thing. But largely
> > > yes, things make sense to me. We have:
> > > - We embedded the device tree that will configure U-Boot, because there
> > > is no way for the hardware to have provided us one.
> > > - We do not embed the device tree that will configure U-Boot, because
> > > there is already one present in memory for us to use.
> > >
> > > Then we have the developer option of:
> > > - We embedded the device tree that will configure U-Boot, because we're
> > > developing something.
> >
> > Yes, agreed those are the cases. To me this needs to be a run-time choice.
>
> But it's not possible. That's the problem we keep going around and
> around about. People keep raising real life examples where you cannot
> make a run time choice between "device tree we're passed at run time"
> and "device tree we're compiled with".
I haven't seen one. The most extreme case is QEMU and it works fine. I
even added a test with it. What am I missing?
>
> And it's not helpful. It is ALWAYS the case that we know that we want
> to override the run time device tree with our own, because it's a
> developer developing things or it's a user / production case where we
> must use the provided tree. NOT doing that is what leads to madness
> like we see for example on Pi where if we don't use the passed tree we
> still need to copy X/Y/Z out of it.
Aren't you talking about the distro DT there, rather than the the one
on the boot disk? That is my reading of that patch. If we need to do
that sort of thing, it doesn't matter where the the cointrol DT comes
from. You are still going to have to do that sort of thing.
It is not ALWAYS the case. I've shown you how easy it is to disable
OF_BOARD and still boot / iterate.
>
> > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should
> > > > provide a way to do that? But what is driving that desire?
> > >
> > > I'm looking for ways to convince you that we do not need to include a
> > > device tree in the binary. There's a growing set of devices where the
> > > device tree exists with the device. If it's missing, that's a huge
> > > fatal error we can't do all that much about. If we need to do something
> > > to that device tree for U-Boot, yes, fine, we should make it straight
> > > forward for the developer to do that. But that's not the common case!
> >
> > Well we could add another Kconfig which tells U-Boot not to include a
> > devicetree in u-boot.bin, if that would resolve this?
> >
> > I just want to make sure that we always build the devicetrees and that
> > it is easy for a knowledgeable dev to switch over to use them, without
> > spelunking through dozens of other projects to discover the secret DT
> > that no one will tell us about.
>
> Should we demand better documentation for boards? Yes. But it's still
> a valid case to have zero device trees for a given platform in-tree.
> Xen is an example of this. QEMU is an example of this. Platforms need
> to work without adding special tweaks for us. Maybe that means some
> features can't be tested in QEMU-as-virtual-platform and only in
> QEMU-faithfully-emulating-specific-physical-platforms.
You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
case, I think. How about we create a special Kconfig for that case? We
need to make some progress here.
>
> > > I guess another part of the problem is that historically almost all
> > > platforms were in the first case I list above, no run time provided
> > > device tree, so we took the kernel one and added our bindings to it.
> > > Now we're being bit by the growing number of platforms that are the
> > > second case, and how do we get our properties in there, and which ones
> > > even make sense to do that for.
> >
> > I think upstreaming the bindings is the solution there. I've made a
> > start, but we need to make progress with this series and all the other
> > things in flight. I think a lot of people want U-Boot to not have a
> > devicetree source files in it for ARMv8 platforms. I am strongly
> > opposed to that. I've laid out my reasons very clearly in the past. I
> > think this is a good summary:
> >
> > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
>
> Yes, there are some ARMv8 platforms we will have to have the source
> files to, in tree, because they won't come to us at run time. But
> others we won't for practical reasons, namely that we can't statically
> provide something that exists dynamically without massive duplication of
> code or just taking things from that passed to us tree.
So let's require that the static ones have the Linux DT in our tree
for now. The dynamic ones are just QEMU for ARM and Xen, I think. If
that's it then I can agree a special case for them, so long as we sort
out the docs for Xen.
>
> > I believe I have been consistent in this although with all the
> > discussion I'm really not sure anymore.
>
> Yes, everyone has been consistent in these discussions.
I'd like to think more people accept that U-Boot is allowed its own
properties than did at the start.
>
> > The problem is that various people have various views about how U-Boot
> > should work with devicetree. I strongly believe that until we have
> > bindings upstream, a central repo for DTs with easy downloading for
> > builds, automated validation, among other things, we must maintain the
> > devicetree in U-Boot. Just from the POV of energy expended, I do not
> > want to be arguing with the Linaro folks about what U-Boot is allowed
> > to do every month for the next two years. I'd rather set out the stall
> > now and then deal with the problems it causes from that perspective.
>
> The problems of the last going on 12 years won't be solved instantly.
> The conflict as I see it is that you're insisting that all platforms
> must have statically usable device trees, and I (and I believe others)
> are saying that's unreasonable in cases where the trees are dynamic at
> heart, lets just ensure we have good enough documentation for them,
> which we don't today.
>
> To be clear and pick an example, I don't want Pi dts files in U-Boot,
> but, OK, it's an easy enough case to sync them up and so long as we
> aren't yet at the "now we pick at run time between compiled in or passed
> to us dtb", I can accept them in tree, but not in the resulting binary
> for OF_CONTROL=y. But as the Xen folks have also noted, there's no
> reasonable tree to include there. It does need to be better documented
> how to fire it up however, in our sources.
I'm OK with us copying in the Linux devicetree and using that. But
OF_BOARD must be a run-time option and able to be disabled. The
devicetree must be built, so it is actually real. We can have a
separate OF_OMIT or something like that to omit the devicetree from
the output image, perhaps.
All of the other things need to wait until we make progress with
devicetree bindings, validation,
How can we make progress on this? We have different goals, as I have
explained, so we are not going to agree on everything.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-04 15:20 ` Simon Glass
@ 2021-12-04 15:58 ` Ilias Apalodimas
2021-12-04 17:25 ` Simon Glass
2021-12-04 16:02 ` Mark Kettenis
` (2 subsequent siblings)
3 siblings, 1 reply; 136+ messages in thread
From: Ilias Apalodimas @ 2021-12-04 15:58 UTC (permalink / raw)
To: Simon Glass
Cc: Tom Rini, U-Boot Mailing List, Mark Kettenis, Sean Anderson,
François Ozog, Heinrich Schuchardt, Aaron Williams,
Albert Aribaud, Alexander Graf, Anastasiia Lukianenko,
Andre Przywara, Bin Meng, Jerry Van Baren, Linus Walleij,
Matthias Brugger, Michal Simek, Oleksandr Andrushchenko,
Peter Maydell, Stephen Warren, Stephen Warren,
Thomas Fitzsimmons, Tuomas Tynkkynen
Hi Simon,
[...]
> > [huge snip]
> > > > There's things that need to be cleaned up because we have some small
> > > > number of platforms that went off and did their own thing. But largely
> > > > yes, things make sense to me. We have:
> > > > - We embedded the device tree that will configure U-Boot, because there
> > > > is no way for the hardware to have provided us one.
> > > > - We do not embed the device tree that will configure U-Boot, because
> > > > there is already one present in memory for us to use.
> > > >
> > > > Then we have the developer option of:
> > > > - We embedded the device tree that will configure U-Boot, because we're
> > > > developing something.
> > >
> > > Yes, agreed those are the cases. To me this needs to be a run-time choice.
> >
I am not convinced the case is "we are developing something". The
arguments for this are something along the lines of:
1. U-Boot will fail to compile if OF_SEPARATE is selected and you provide
no DT so we need to include it. With which I disagree. The config option
says "You must provide an external device tree" for a reason.
2. The DT's are hard to find. The 'hard to find' RPI DTs are in fact
committed in the kernel. I am not sure about the rest, but honestly this
isn't a convincing argument for me.
What else are we gaining with it being a run time choice? One of the
things this approach does address, but we keep conveniently ignoring, is
that it tries to preserve the current status quo. You can go and add the
special missing U-Boot nodes in those DT's. So that would bypass problems
if the bindings get NAK'ed. But this is going to work against the
fragmentation we are trying to resolve.
> > But it's not possible. That's the problem we keep going around and
> > around about. People keep raising real life examples where you cannot
> > make a run time choice between "device tree we're passed at run time"
> > and "device tree we're compiled with".
>
> I haven't seen one. The most extreme case is QEMU and it works fine. I
> even added a test with it. What am I missing?
IMHO 3b595da441cf is the commit that started the problem and tangled those
2 options. Note that this support has been removed from the dragonboard
later in 0204d1b56b2f ....
>
> >
> > And it's not helpful. It is ALWAYS the case that we know that we want
> > to override the run time device tree with our own, because it's a
> > developer developing things or it's a user / production case where we
> > must use the provided tree. NOT doing that is what leads to madness
> > like we see for example on Pi where if we don't use the passed tree we
> > still need to copy X/Y/Z out of it.
>
> Aren't you talking about the distro DT there, rather than the the one
> on the boot disk? That is my reading of that patch. If we need to do
> that sort of thing, it doesn't matter where the the cointrol DT comes
> from. You are still going to have to do that sort of thing.
>
> It is not ALWAYS the case. I've shown you how easy it is to disable
> OF_BOARD and still boot / iterate.
>
> >
> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should
> > > > > provide a way to do that? But what is driving that desire?
> > > >
> > > > I'm looking for ways to convince you that we do not need to include a
> > > > device tree in the binary. There's a growing set of devices where the
> > > > device tree exists with the device. If it's missing, that's a huge
> > > > fatal error we can't do all that much about. If we need to do something
> > > > to that device tree for U-Boot, yes, fine, we should make it straight
> > > > forward for the developer to do that. But that's not the common case!
> > >
> > > Well we could add another Kconfig which tells U-Boot not to include a
> > > devicetree in u-boot.bin, if that would resolve this?
> > >
> > > I just want to make sure that we always build the devicetrees and that
> > > it is easy for a knowledgeable dev to switch over to use them, without
> > > spelunking through dozens of other projects to discover the secret DT
> > > that no one will tell us about.
So the translation of this for me is:
We have 2 discrete options (that can be cleaned up further) which choose
either to embed or receive the DTB. Let's tangle them and introduce a
*new* third option to separate them if someone needs to. Which makes no
sense to me.
> >
> > Should we demand better documentation for boards? Yes. But it's still
> > a valid case to have zero device trees for a given platform in-tree.
> > Xen is an example of this. QEMU is an example of this. Platforms need
> > to work without adding special tweaks for us. Maybe that means some
> > features can't be tested in QEMU-as-virtual-platform and only in
> > QEMU-faithfully-emulating-specific-physical-platforms.
>
> You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
> case, I think. How about we create a special Kconfig for that case? We
> need to make some progress here.
>
> >
> > > > I guess another part of the problem is that historically almost all
> > > > platforms were in the first case I list above, no run time provided
> > > > device tree, so we took the kernel one and added our bindings to it.
> > > > Now we're being bit by the growing number of platforms that are the
> > > > second case, and how do we get our properties in there, and which ones
> > > > even make sense to do that for.
> > >
> > > I think upstreaming the bindings is the solution there. I've made a
> > > start, but we need to make progress with this series and all the other
> > > things in flight. I think a lot of people want U-Boot to not have a
> > > devicetree source files in it for ARMv8 platforms. I am strongly
> > > opposed to that. I've laid out my reasons very clearly in the past. I
> > > think this is a good summary:
> > >
> > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
> >
> > Yes, there are some ARMv8 platforms we will have to have the source
> > files to, in tree, because they won't come to us at run time. But
> > others we won't for practical reasons, namely that we can't statically
> > provide something that exists dynamically without massive duplication of
> > code or just taking things from that passed to us tree.
>
> So let's require that the static ones have the Linux DT in our tree
> for now. The dynamic ones are just QEMU for ARM and Xen, I think. If
> that's it then I can agree a special case for them, so long as we sort
> out the docs for Xen.
>
> >
> > > I believe I have been consistent in this although with all the
> > > discussion I'm really not sure anymore.
> >
> > Yes, everyone has been consistent in these discussions.
>
> I'd like to think more people accept that U-Boot is allowed its own
> properties than did at the start.
>
> >
> > > The problem is that various people have various views about how U-Boot
> > > should work with devicetree. I strongly believe that until we have
> > > bindings upstream, a central repo for DTs with easy downloading for
> > > builds, automated validation, among other things, we must maintain the
> > > devicetree in U-Boot. Just from the POV of energy expended, I do not
> > > want to be arguing with the Linaro folks about what U-Boot is allowed
> > > to do every month for the next two years. I'd rather set out the stall
> > > now and then deal with the problems it causes from that perspective.
> >
> > The problems of the last going on 12 years won't be solved instantly.
> > The conflict as I see it is that you're insisting that all platforms
> > must have statically usable device trees, and I (and I believe others)
> > are saying that's unreasonable in cases where the trees are dynamic at
> > heart, lets just ensure we have good enough documentation for them,
> > which we don't today.
> >
> > To be clear and pick an example, I don't want Pi dts files in U-Boot,
> > but, OK, it's an easy enough case to sync them up and so long as we
> > aren't yet at the "now we pick at run time between compiled in or passed
> > to us dtb", I can accept them in tree, but not in the resulting binary
> > for OF_CONTROL=y. But as the Xen folks have also noted, there's no
> > reasonable tree to include there. It does need to be better documented
> > how to fire it up however, in our sources.
>
> I'm OK with us copying in the Linux devicetree and using that. But
> OF_BOARD must be a run-time option and able to be disabled. The
> devicetree must be built, so it is actually real. We can have a
> separate OF_OMIT or something like that to omit the devicetree from
> the output image, perhaps.
>
> All of the other things need to wait until we make progress with
> devicetree bindings, validation,
>
> How can we make progress on this? We have different goals, as I have
> explained, so we are not going to agree on everything.
>
> Regards,
> Simon
Regards
/Ilias
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-04 15:58 ` Ilias Apalodimas
@ 2021-12-04 17:25 ` Simon Glass
2021-12-04 18:46 ` Ilias Apalodimas
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-04 17:25 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Tom Rini, U-Boot Mailing List, Mark Kettenis, Sean Anderson,
François Ozog, Heinrich Schuchardt, Aaron Williams,
Albert Aribaud, Alexander Graf, Anastasiia Lukianenko,
Andre Przywara, Bin Meng, Jerry Van Baren, Linus Walleij,
Matthias Brugger, Michal Simek, Oleksandr Andrushchenko,
Peter Maydell, Stephen Warren, Stephen Warren,
Thomas Fitzsimmons, Tuomas Tynkkynen
Hi Ilias,
On Sat, 4 Dec 2021 at 08:58, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Simon,
>
> [...]
> > > [huge snip]
> > > > > There's things that need to be cleaned up because we have some small
> > > > > number of platforms that went off and did their own thing. But largely
> > > > > yes, things make sense to me. We have:
> > > > > - We embedded the device tree that will configure U-Boot, because there
> > > > > is no way for the hardware to have provided us one.
> > > > > - We do not embed the device tree that will configure U-Boot, because
> > > > > there is already one present in memory for us to use.
> > > > >
> > > > > Then we have the developer option of:
> > > > > - We embedded the device tree that will configure U-Boot, because we're
> > > > > developing something.
> > > >
> > > > Yes, agreed those are the cases. To me this needs to be a run-time choice.
> > >
>
> I am not convinced the case is "we are developing something". The
> arguments for this are something along the lines of:
> 1. U-Boot will fail to compile if OF_SEPARATE is selected and you provide
> no DT so we need to include it. With which I disagree. The config option
> says "You must provide an external device tree" for a reason.
Where are you reading that? I'm lost.
OF_SEPARATE means it is not embedded in U-Boot but is attached to the end of it.
> 2. The DT's are hard to find. The 'hard to find' RPI DTs are in fact
> committed in the kernel. I am not sure about the rest, but honestly this
> isn't a convincing argument for me.
Great, so you've solved that one but even that was confusing for me,
as my patch should make clear. Every single board would be its own
special snowflake if we went that way.
So if they are in the kernel, we just need to put them in U-Boot too,
so problem solved. The auto-sync thing that I believe Rob is working
on will make things easy.
>
> What else are we gaining with it being a run time choice? One of the
We are requiring a DT to be present in the U-Boot tree for
development, documentation and discoverability purposes. Devs can turn
OF_BOARD on and off as it suits them when iterating on a platform.
> things this approach does address, but we keep conveniently ignoring, is
> that it tries to preserve the current status quo. You can go and add the
> special missing U-Boot nodes in those DT's. So that would bypass problems
> if the bindings get NAK'ed. But this is going to work against the
> fragmentation we are trying to resolve.
Well that's another reason why we need in-tree DTs at the moment. That
reason goes away once we have our bindings upstream and are able to do
what we need with DT there.
>
> > > But it's not possible. That's the problem we keep going around and
> > > around about. People keep raising real life examples where you cannot
> > > make a run time choice between "device tree we're passed at run time"
> > > and "device tree we're compiled with".
> >
> > I haven't seen one. The most extreme case is QEMU and it works fine. I
> > even added a test with it. What am I missing?
(I think my point there is made)
>
> IMHO 3b595da441cf is the commit that started the problem and tangled those
> 2 options. Note that this support has been removed from the dragonboard
> later in 0204d1b56b2f ....
Yes it is one of them. There may be cases where we want to patch up
the DT that U-Boot builds. In fact OF_BOARD does not mean it came from
a prior stage. All sorts of things could be going on. We should not
conflate building a DT with OF_BOARD.
>
> >
> > >
> > > And it's not helpful. It is ALWAYS the case that we know that we want
> > > to override the run time device tree with our own, because it's a
> > > developer developing things or it's a user / production case where we
> > > must use the provided tree. NOT doing that is what leads to madness
> > > like we see for example on Pi where if we don't use the passed tree we
> > > still need to copy X/Y/Z out of it.
> >
> > Aren't you talking about the distro DT there, rather than the the one
> > on the boot disk? That is my reading of that patch. If we need to do
> > that sort of thing, it doesn't matter where the the cointrol DT comes
> > from. You are still going to have to do that sort of thing.
> >
> > It is not ALWAYS the case. I've shown you how easy it is to disable
> > OF_BOARD and still boot / iterate.
> >
> > >
> > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should
> > > > > > provide a way to do that? But what is driving that desire?
> > > > >
> > > > > I'm looking for ways to convince you that we do not need to include a
> > > > > device tree in the binary. There's a growing set of devices where the
> > > > > device tree exists with the device. If it's missing, that's a huge
> > > > > fatal error we can't do all that much about. If we need to do something
> > > > > to that device tree for U-Boot, yes, fine, we should make it straight
> > > > > forward for the developer to do that. But that's not the common case!
> > > >
> > > > Well we could add another Kconfig which tells U-Boot not to include a
> > > > devicetree in u-boot.bin, if that would resolve this?
> > > >
> > > > I just want to make sure that we always build the devicetrees and that
> > > > it is easy for a knowledgeable dev to switch over to use them, without
> > > > spelunking through dozens of other projects to discover the secret DT
> > > > that no one will tell us about.
>
> So the translation of this for me is:
> We have 2 discrete options (that can be cleaned up further) which choose
> either to embed or receive the DTB. Let's tangle them and introduce a
> *new* third option to separate them if someone needs to. Which makes no
> sense to me.
Embed is confusing because OF_EMBED means to link it into U-Boot (just
used for debugging)
I think this is the core of the problem. There are just lots of ideas
about how all of this should work. Please try out the series and see
if you find any problems. Then we can talk about actual issues rather
than things that might happen.
The two options you refer to are OF_SEPARATE and OF_BOARD. We will
perhaps have OF_PASSAGE at some point. We already have OF_EMBED.
To me, OF_BOARD and OF_PASSAGE are run-time things because they
indicate what we expect to happen at runtime. If something goes wrong,
we might still be able to print an error message, if we have a backup
DT.
But OF_BOARD and OF_PASSAGE are not related to the build itself. IMO
OF_BOARD is underspecified. One day I would like to move towards
defining these cases better, e.g.
- DT is passed in a register (rpi and apple_m1, stm32mp, RISC-V, qemu
RISC-V, bcmstb, Octeon, Xen)
- DT is at a fixed address (qemu, highbank, socrates, qemu ppc)
- DT is in a file (sandbox)
IMO many of these could all be handled with standard passage, i.e. in
a standard way.
>
> > >
> > > Should we demand better documentation for boards? Yes. But it's still
> > > a valid case to have zero device trees for a given platform in-tree.
> > > Xen is an example of this. QEMU is an example of this. Platforms need
> > > to work without adding special tweaks for us. Maybe that means some
> > > features can't be tested in QEMU-as-virtual-platform and only in
> > > QEMU-faithfully-emulating-specific-physical-platforms.
> >
> > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
> > case, I think. How about we create a special Kconfig for that case? We
> > need to make some progress here.
> >
> > >
> > > > > I guess another part of the problem is that historically almost all
> > > > > platforms were in the first case I list above, no run time provided
> > > > > device tree, so we took the kernel one and added our bindings to it.
> > > > > Now we're being bit by the growing number of platforms that are the
> > > > > second case, and how do we get our properties in there, and which ones
> > > > > even make sense to do that for.
> > > >
> > > > I think upstreaming the bindings is the solution there. I've made a
> > > > start, but we need to make progress with this series and all the other
> > > > things in flight. I think a lot of people want U-Boot to not have a
> > > > devicetree source files in it for ARMv8 platforms. I am strongly
> > > > opposed to that. I've laid out my reasons very clearly in the past. I
> > > > think this is a good summary:
> > > >
> > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
> > >
> > > Yes, there are some ARMv8 platforms we will have to have the source
> > > files to, in tree, because they won't come to us at run time. But
> > > others we won't for practical reasons, namely that we can't statically
> > > provide something that exists dynamically without massive duplication of
> > > code or just taking things from that passed to us tree.
> >
> > So let's require that the static ones have the Linux DT in our tree
> > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If
> > that's it then I can agree a special case for them, so long as we sort
> > out the docs for Xen.
> >
> > >
> > > > I believe I have been consistent in this although with all the
> > > > discussion I'm really not sure anymore.
> > >
> > > Yes, everyone has been consistent in these discussions.
> >
> > I'd like to think more people accept that U-Boot is allowed its own
> > properties than did at the start.
> >
> > >
> > > > The problem is that various people have various views about how U-Boot
> > > > should work with devicetree. I strongly believe that until we have
> > > > bindings upstream, a central repo for DTs with easy downloading for
> > > > builds, automated validation, among other things, we must maintain the
> > > > devicetree in U-Boot. Just from the POV of energy expended, I do not
> > > > want to be arguing with the Linaro folks about what U-Boot is allowed
> > > > to do every month for the next two years. I'd rather set out the stall
> > > > now and then deal with the problems it causes from that perspective.
> > >
> > > The problems of the last going on 12 years won't be solved instantly.
> > > The conflict as I see it is that you're insisting that all platforms
> > > must have statically usable device trees, and I (and I believe others)
> > > are saying that's unreasonable in cases where the trees are dynamic at
> > > heart, lets just ensure we have good enough documentation for them,
> > > which we don't today.
> > >
> > > To be clear and pick an example, I don't want Pi dts files in U-Boot,
> > > but, OK, it's an easy enough case to sync them up and so long as we
> > > aren't yet at the "now we pick at run time between compiled in or passed
> > > to us dtb", I can accept them in tree, but not in the resulting binary
> > > for OF_CONTROL=y. But as the Xen folks have also noted, there's no
> > > reasonable tree to include there. It does need to be better documented
> > > how to fire it up however, in our sources.
> >
> > I'm OK with us copying in the Linux devicetree and using that. But
> > OF_BOARD must be a run-time option and able to be disabled. The
> > devicetree must be built, so it is actually real. We can have a
> > separate OF_OMIT or something like that to omit the devicetree from
> > the output image, perhaps.
> >
> > All of the other things need to wait until we make progress with
> > devicetree bindings, validation,
> >
> > How can we make progress on this? We have different goals, as I have
> > explained, so we are not going to agree on everything.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-04 17:25 ` Simon Glass
@ 2021-12-04 18:46 ` Ilias Apalodimas
0 siblings, 0 replies; 136+ messages in thread
From: Ilias Apalodimas @ 2021-12-04 18:46 UTC (permalink / raw)
To: Simon Glass
Cc: Tom Rini, U-Boot Mailing List, Mark Kettenis, Sean Anderson,
François Ozog, Heinrich Schuchardt, Aaron Williams,
Albert Aribaud, Alexander Graf, Anastasiia Lukianenko,
Andre Przywara, Bin Meng, Jerry Van Baren, Linus Walleij,
Matthias Brugger, Michal Simek, Oleksandr Andrushchenko,
Peter Maydell, Stephen Warren, Stephen Warren,
Thomas Fitzsimmons, Tuomas Tynkkynen
Hi Simon,
On Sat, Dec 04, 2021 at 10:25:29AM -0700, Simon Glass wrote:
> Hi Ilias,
>
> On Sat, 4 Dec 2021 at 08:58, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > [...]
> > > > [huge snip]
> > > > > > There's things that need to be cleaned up because we have some small
> > > > > > number of platforms that went off and did their own thing. But largely
> > > > > > yes, things make sense to me. We have:
> > > > > > - We embedded the device tree that will configure U-Boot, because there
> > > > > > is no way for the hardware to have provided us one.
> > > > > > - We do not embed the device tree that will configure U-Boot, because
> > > > > > there is already one present in memory for us to use.
> > > > > >
> > > > > > Then we have the developer option of:
> > > > > > - We embedded the device tree that will configure U-Boot, because we're
> > > > > > developing something.
> > > > >
> > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice.
> > > >
> >
> > I am not convinced the case is "we are developing something". The
> > arguments for this are something along the lines of:
> > 1. U-Boot will fail to compile if OF_SEPARATE is selected and you provide
> > no DT so we need to include it. With which I disagree. The config option
> > says "You must provide an external device tree" for a reason.
>
> Where are you reading that? I'm lost.
In the XEN patch commit message [1]
>
> OF_SEPARATE means it is not embedded in U-Boot but is attached to the end of it.
>
> > 2. The DT's are hard to find. The 'hard to find' RPI DTs are in fact
> > committed in the kernel. I am not sure about the rest, but honestly this
> > isn't a convincing argument for me.
>
> Great, so you've solved that one but even that was confusing for me,
> as my patch should make clear. Every single board would be its own
> special snowflake if we went that way.
>
> So if they are in the kernel, we just need to put them in U-Boot too,
> so problem solved. The auto-sync thing that I believe Rob is working
> on will make things easy.
My problem is not usable DTs like the PRI4. My problem is the OF_BOARD
being a runtime option and always building that DT, while at the same time
introduce a third option to not include it in the binary. Another problem
is 'empty' DTs.
>
> >
> > What else are we gaining with it being a run time choice? One of the
>
> We are requiring a DT to be present in the U-Boot tree for
> development, documentation and discoverability purposes. Devs can turn
> OF_BOARD on and off as it suits them when iterating on a platform.
They can also do the same thing without tangling the 2 options. The *real*
problem is that in a month from now we'll get a patch saying "I need to
change X on RPI4 DTB because I have this special reason and I want a
specific u-boot binding" and then we are back at the start. We also have
OF_EMBED for the 'developer' option which is also mentioned explicitly in
the Kconfig.
>
> > things this approach does address, but we keep conveniently ignoring, is
> > that it tries to preserve the current status quo. You can go and add the
> > special missing U-Boot nodes in those DT's. So that would bypass problems
> > if the bindings get NAK'ed. But this is going to work against the
> > fragmentation we are trying to resolve.
>
> Well that's another reason why we need in-tree DTs at the moment. That
> reason goes away once we have our bindings upstream and are able to do
> what we need with DT there.
>
Again, that's a huge if. I am honestly not saying this in bad faith, but I
have my concerns on if and what gets upstreamed. So what this really does
in my head is preserve the current functionality. So what I am trying to
avoid here is, in case the bindings get NAK'ed, we go back and say "that's
fine we got this covered, look it's in docs and commit messages!"
> >
> > > > But it's not possible. That's the problem we keep going around and
> > > > around about. People keep raising real life examples where you cannot
> > > > make a run time choice between "device tree we're passed at run time"
> > > > and "device tree we're compiled with".
> > >
> > > I haven't seen one. The most extreme case is QEMU and it works fine. I
> > > even added a test with it. What am I missing?
>
> (I think my point there is made)
>
> >
> > IMHO 3b595da441cf is the commit that started the problem and tangled those
> > 2 options. Note that this support has been removed from the dragonboard
> > later in 0204d1b56b2f ....
>
> Yes it is one of them. There may be cases where we want to patch up
> the DT that U-Boot builds. In fact OF_BOARD does not mean it came from
> a prior stage. All sorts of things could be going on. We should not
> conflate building a DT with OF_BOARD.
It says 'board specific way'. To means that means we either create it on
the fly or inherit it. In the case you want to fixup the DTB provided by
OF_SEPARATE, there are _weak platform functions to patch that up.
You don't really need OF_BOARD for that, you can do that fine with OF_SEPARATE
and check fdtdec_board_setup().
>
> >
> > >
> > > >
> > > > And it's not helpful. It is ALWAYS the case that we know that we want
> > > > to override the run time device tree with our own, because it's a
> > > > developer developing things or it's a user / production case where we
> > > > must use the provided tree. NOT doing that is what leads to madness
> > > > like we see for example on Pi where if we don't use the passed tree we
> > > > still need to copy X/Y/Z out of it.
> > >
> > > Aren't you talking about the distro DT there, rather than the the one
> > > on the boot disk? That is my reading of that patch. If we need to do
> > > that sort of thing, it doesn't matter where the the cointrol DT comes
> > > from. You are still going to have to do that sort of thing.
> > >
> > > It is not ALWAYS the case. I've shown you how easy it is to disable
> > > OF_BOARD and still boot / iterate.
> > >
> > > >
> > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should
> > > > > > > provide a way to do that? But what is driving that desire?
> > > > > >
> > > > > > I'm looking for ways to convince you that we do not need to include a
> > > > > > device tree in the binary. There's a growing set of devices where the
> > > > > > device tree exists with the device. If it's missing, that's a huge
> > > > > > fatal error we can't do all that much about. If we need to do something
> > > > > > to that device tree for U-Boot, yes, fine, we should make it straight
> > > > > > forward for the developer to do that. But that's not the common case!
> > > > >
> > > > > Well we could add another Kconfig which tells U-Boot not to include a
> > > > > devicetree in u-boot.bin, if that would resolve this?
> > > > >
> > > > > I just want to make sure that we always build the devicetrees and that
> > > > > it is easy for a knowledgeable dev to switch over to use them, without
> > > > > spelunking through dozens of other projects to discover the secret DT
> > > > > that no one will tell us about.
> >
> > So the translation of this for me is:
> > We have 2 discrete options (that can be cleaned up further) which choose
> > either to embed or receive the DTB. Let's tangle them and introduce a
> > *new* third option to separate them if someone needs to. Which makes no
> > sense to me.
>
> Embed is confusing because OF_EMBED means to link it into U-Boot (just
> used for debugging)
>
Which as I said, it's what development should use?
> I think this is the core of the problem. There are just lots of ideas
> about how all of this should work. Please try out the series and see
> if you find any problems. Then we can talk about actual issues rather
> than things that might happen.
I am pretty sure the patches work. I never doubted that. What I don't love
is the architecture and the way it entangles the existing options.
>
> The two options you refer to are OF_SEPARATE and OF_BOARD. We will
> perhaps have OF_PASSAGE at some point. We already have OF_EMBED.
>
> To me, OF_BOARD and OF_PASSAGE are run-time things because they
> indicate what we expect to happen at runtime. If something goes wrong,
> we might still be able to print an error message, if we have a backup
> DT.
I don't see a point saving a developer from a mistake. I'd much rather
crash as loudly as possible to indicate "HEY YOU MESSED UP", instead of
hiding a problem he might miss under the mat.
Maybe I am missing something, but OF_PASSAGE seems superfluous to me.
OF_SEPARATE and OF_BOARD cover all the cases I can think of.
>
> But OF_BOARD and OF_PASSAGE are not related to the build itself. IMO
> OF_BOARD is underspecified. One day I would like to move towards
> defining these cases better, e.g.
>
> - DT is passed in a register (rpi and apple_m1, stm32mp, RISC-V, qemu
> RISC-V, bcmstb, Octeon, Xen)
> - DT is at a fixed address (qemu, highbank, socrates, qemu ppc)
> - DT is in a file (sandbox)
Again I might be missing something but to me:
1. OF_SEPARATE = provided by u-boot. If someone wants to fix that up we
got a number of ways already.
2. OF_BOARD providing with magic somehow at runtime (prior loader,
constructed at runtime, read from a flash, whatever).
3. OF_EMBED whatever special developer case we want to use it for.
>
> IMO many of these could all be handled with standard passage, i.e. in
> a standard way.
>
[...]
>
> Regards,
> Simon
[1] https://lore.kernel.org/u-boot/20211204180318.GV1220664@bill-the-cat/T/#m543a10a4b558ccd540fa425d61106ea515393105
Regards
/Ilias
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-04 15:20 ` Simon Glass
2021-12-04 15:58 ` Ilias Apalodimas
@ 2021-12-04 16:02 ` Mark Kettenis
2021-12-04 17:25 ` Simon Glass
2021-12-04 16:55 ` François Ozog
2021-12-04 18:03 ` Tom Rini
3 siblings, 1 reply; 136+ messages in thread
From: Mark Kettenis @ 2021-12-04 16:02 UTC (permalink / raw)
To: Simon Glass
Cc: trini, u-boot, seanga2, ilias.apalodimas, francois.ozog,
xypron.glpk, awilliams, albert.u.boot, agraf,
Anastasiia_Lukianenko, andre.przywara, bmeng.cn, vanbaren,
linus.walleij, mbrugger, michal.simek, Oleksandr_Andrushchenko,
peter.maydell, swarren, swarren, fitzsim, tuomas.tynkkynen
> From: Simon Glass <sjg@chromium.org>
> Date: Sat, 4 Dec 2021 08:20:55 -0700
>
> Hi Tom,
>
> On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> >
> > [huge snip]
> > > > There's things that need to be cleaned up because we have some small
> > > > number of platforms that went off and did their own thing. But largely
> > > > yes, things make sense to me. We have:
> > > > - We embedded the device tree that will configure U-Boot, because there
> > > > is no way for the hardware to have provided us one.
> > > > - We do not embed the device tree that will configure U-Boot, because
> > > > there is already one present in memory for us to use.
> > > >
> > > > Then we have the developer option of:
> > > > - We embedded the device tree that will configure U-Boot, because we're
> > > > developing something.
> > >
> > > Yes, agreed those are the cases. To me this needs to be a run-time choice.
> >
> > But it's not possible. That's the problem we keep going around and
> > around about. People keep raising real life examples where you cannot
> > make a run time choice between "device tree we're passed at run time"
> > and "device tree we're compiled with".
>
> I haven't seen one. The most extreme case is QEMU and it works fine. I
> even added a test with it. What am I missing?
Try it on your M1 Mac.
> > And it's not helpful. It is ALWAYS the case that we know that we want
> > to override the run time device tree with our own, because it's a
> > developer developing things or it's a user / production case where we
> > must use the provided tree. NOT doing that is what leads to madness
> > like we see for example on Pi where if we don't use the passed tree we
> > still need to copy X/Y/Z out of it.
>
> Aren't you talking about the distro DT there, rather than the the one
> on the boot disk? That is my reading of that patch. If we need to do
> that sort of thing, it doesn't matter where the the cointrol DT comes
> from. You are still going to have to do that sort of thing.
>
> It is not ALWAYS the case. I've shown you how easy it is to disable
> OF_BOARD and still boot / iterate.
You are cheating. If you dump the device tree passed to U-Boot (or
the OS) and don't change anything in the configuration of whatever is
passing U-Boot that device tree this is likely to work fine. But it
won't work in general.
> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should
> > > > > provide a way to do that? But what is driving that desire?
> > > >
> > > > I'm looking for ways to convince you that we do not need to include a
> > > > device tree in the binary. There's a growing set of devices where the
> > > > device tree exists with the device. If it's missing, that's a huge
> > > > fatal error we can't do all that much about. If we need to do something
> > > > to that device tree for U-Boot, yes, fine, we should make it straight
> > > > forward for the developer to do that. But that's not the common case!
> > >
> > > Well we could add another Kconfig which tells U-Boot not to include a
> > > devicetree in u-boot.bin, if that would resolve this?
> > >
> > > I just want to make sure that we always build the devicetrees and that
> > > it is easy for a knowledgeable dev to switch over to use them, without
> > > spelunking through dozens of other projects to discover the secret DT
> > > that no one will tell us about.
> >
> > Should we demand better documentation for boards? Yes. But it's still
> > a valid case to have zero device trees for a given platform in-tree.
> > Xen is an example of this. QEMU is an example of this. Platforms need
> > to work without adding special tweaks for us. Maybe that means some
> > features can't be tested in QEMU-as-virtual-platform and only in
> > QEMU-faithfully-emulating-specific-physical-platforms.
>
> You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
> case, I think. How about we create a special Kconfig for that case? We
> need to make some progress here.
No, Apple M1 and Raspberry Pi 4 also fall into that case. And I
suspect at least some of the other boards that currently defined
OF_BOARD fall into this category. So rather than changing the meaning
of OF_BOARD, how about introducing another Kconfig option that
indicates that switching to a device tree built into U-Boot is ok?
You could use that to implement the runtime switching that you desire.
This would prevent confusing users with options that result in making
their systems unusable.
> > > > I guess another part of the problem is that historically almost all
> > > > platforms were in the first case I list above, no run time provided
> > > > device tree, so we took the kernel one and added our bindings to it.
> > > > Now we're being bit by the growing number of platforms that are the
> > > > second case, and how do we get our properties in there, and which ones
> > > > even make sense to do that for.
> > >
> > > I think upstreaming the bindings is the solution there. I've made a
> > > start, but we need to make progress with this series and all the other
> > > things in flight. I think a lot of people want U-Boot to not have a
> > > devicetree source files in it for ARMv8 platforms. I am strongly
> > > opposed to that. I've laid out my reasons very clearly in the past. I
> > > think this is a good summary:
> > >
> > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
> >
> > Yes, there are some ARMv8 platforms we will have to have the source
> > files to, in tree, because they won't come to us at run time. But
> > others we won't for practical reasons, namely that we can't statically
> > provide something that exists dynamically without massive duplication of
> > code or just taking things from that passed to us tree.
>
> So let's require that the static ones have the Linux DT in our tree
> for now. The dynamic ones are just QEMU for ARM and Xen, I think. If
> that's it then I can agree a special case for them, so long as we sort
> out the docs for Xen.
No Raspberry Pi (all models) and Apple M1 are also dynamic. And there
are probably a few more that I'm not familliar with. We've explain
how these are dynamic in this thread and earlier discussions many
times already, but I can do it again if you need me to.
> > > I believe I have been consistent in this although with all the
> > > discussion I'm really not sure anymore.
> >
> > Yes, everyone has been consistent in these discussions.
>
> I'd like to think more people accept that U-Boot is allowed its own
> properties than did at the start.
>
> >
> > > The problem is that various people have various views about how U-Boot
> > > should work with devicetree. I strongly believe that until we have
> > > bindings upstream, a central repo for DTs with easy downloading for
> > > builds, automated validation, among other things, we must maintain the
> > > devicetree in U-Boot. Just from the POV of energy expended, I do not
> > > want to be arguing with the Linaro folks about what U-Boot is allowed
> > > to do every month for the next two years. I'd rather set out the stall
> > > now and then deal with the problems it causes from that perspective.
> >
> > The problems of the last going on 12 years won't be solved instantly.
> > The conflict as I see it is that you're insisting that all platforms
> > must have statically usable device trees, and I (and I believe others)
> > are saying that's unreasonable in cases where the trees are dynamic at
> > heart, lets just ensure we have good enough documentation for them,
> > which we don't today.
> >
> > To be clear and pick an example, I don't want Pi dts files in U-Boot,
> > but, OK, it's an easy enough case to sync them up and so long as we
> > aren't yet at the "now we pick at run time between compiled in or passed
> > to us dtb", I can accept them in tree, but not in the resulting binary
> > for OF_CONTROL=y. But as the Xen folks have also noted, there's no
> > reasonable tree to include there. It does need to be better documented
> > how to fire it up however, in our sources.
>
> I'm OK with us copying in the Linux devicetree and using that. But
> OF_BOARD must be a run-time option and able to be disabled. The
> devicetree must be built, so it is actually real. We can have a
> separate OF_OMIT or something like that to omit the devicetree from
> the output image, perhaps.
>
> All of the other things need to wait until we make progress with
> devicetree bindings, validation,
>
> How can we make progress on this? We have different goals, as I have
> explained, so we are not going to agree on everything.
>
> Regards,
> Simon
>
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-04 16:02 ` Mark Kettenis
@ 2021-12-04 17:25 ` Simon Glass
0 siblings, 0 replies; 136+ messages in thread
From: Simon Glass @ 2021-12-04 17:25 UTC (permalink / raw)
To: Mark Kettenis
Cc: trini, u-boot, seanga2, ilias.apalodimas, francois.ozog,
xypron.glpk, awilliams, albert.u.boot, agraf,
Anastasiia_Lukianenko, andre.przywara, bmeng.cn, vanbaren,
linus.walleij, mbrugger, michal.simek, Oleksandr_Andrushchenko,
peter.maydell, swarren, swarren, fitzsim, tuomas.tynkkynen
Hi Mark,
On Sat, 4 Dec 2021 at 09:09, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Simon Glass <sjg@chromium.org>
> > Date: Sat, 4 Dec 2021 08:20:55 -0700
> >
> > Hi Tom,
> >
> > On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> > >
> > > [huge snip]
> > > > > There's things that need to be cleaned up because we have some small
> > > > > number of platforms that went off and did their own thing. But largely
> > > > > yes, things make sense to me. We have:
> > > > > - We embedded the device tree that will configure U-Boot, because there
> > > > > is no way for the hardware to have provided us one.
> > > > > - We do not embed the device tree that will configure U-Boot, because
> > > > > there is already one present in memory for us to use.
> > > > >
> > > > > Then we have the developer option of:
> > > > > - We embedded the device tree that will configure U-Boot, because we're
> > > > > developing something.
> > > >
> > > > Yes, agreed those are the cases. To me this needs to be a run-time choice.
> > >
> > > But it's not possible. That's the problem we keep going around and
> > > around about. People keep raising real life examples where you cannot
> > > make a run time choice between "device tree we're passed at run time"
> > > and "device tree we're compiled with".
> >
> > I haven't seen one. The most extreme case is QEMU and it works fine. I
> > even added a test with it. What am I missing?
>
> Try it on your M1 Mac.
I have tested this series on a Mac Mini and it works fine.
You cannot run U-Boot by itself, of course, since it needs m1n1. Also
m1n1 fixes up the DT. I'm not sure exactly what changes it makes, as I
don't even have a serial console on the machine at present. But in any
case, I can easily iterate on U-Boot on this platform with U-Boot
building the DTs. It certainly meets my requirements at present.
>
> > > And it's not helpful. It is ALWAYS the case that we know that we want
> > > to override the run time device tree with our own, because it's a
> > > developer developing things or it's a user / production case where we
> > > must use the provided tree. NOT doing that is what leads to madness
> > > like we see for example on Pi where if we don't use the passed tree we
> > > still need to copy X/Y/Z out of it.
> >
> > Aren't you talking about the distro DT there, rather than the the one
> > on the boot disk? That is my reading of that patch. If we need to do
> > that sort of thing, it doesn't matter where the the cointrol DT comes
> > from. You are still going to have to do that sort of thing.
> >
> > It is not ALWAYS the case. I've shown you how easy it is to disable
> > OF_BOARD and still boot / iterate.
>
> You are cheating. If you dump the device tree passed to U-Boot (or
> the OS) and don't change anything in the configuration of whatever is
> passing U-Boot that device tree this is likely to work fine. But it
> won't work in general.
I didn't say it would. What are you getting at?
Can you please try to test my series so you get the hang of what it is
actually doing?
>
> > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should
> > > > > > provide a way to do that? But what is driving that desire?
> > > > >
> > > > > I'm looking for ways to convince you that we do not need to include a
> > > > > device tree in the binary. There's a growing set of devices where the
> > > > > device tree exists with the device. If it's missing, that's a huge
> > > > > fatal error we can't do all that much about. If we need to do something
> > > > > to that device tree for U-Boot, yes, fine, we should make it straight
> > > > > forward for the developer to do that. But that's not the common case!
> > > >
> > > > Well we could add another Kconfig which tells U-Boot not to include a
> > > > devicetree in u-boot.bin, if that would resolve this?
> > > >
> > > > I just want to make sure that we always build the devicetrees and that
> > > > it is easy for a knowledgeable dev to switch over to use them, without
> > > > spelunking through dozens of other projects to discover the secret DT
> > > > that no one will tell us about.
> > >
> > > Should we demand better documentation for boards? Yes. But it's still
> > > a valid case to have zero device trees for a given platform in-tree.
> > > Xen is an example of this. QEMU is an example of this. Platforms need
> > > to work without adding special tweaks for us. Maybe that means some
> > > features can't be tested in QEMU-as-virtual-platform and only in
> > > QEMU-faithfully-emulating-specific-physical-platforms.
> >
> > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
> > case, I think. How about we create a special Kconfig for that case? We
> > need to make some progress here.
>
> No, Apple M1 and Raspberry Pi 4 also fall into that case. And I
> suspect at least some of the other boards that currently defined
> OF_BOARD fall into this category. So rather than changing the meaning
> of OF_BOARD, how about introducing another Kconfig option that
> indicates that switching to a device tree built into U-Boot is ok?
> You could use that to implement the runtime switching that you desire.
> This would prevent confusing users with options that result in making
> their systems unusable.
Yes Tom and I have already discussed doing that, along with various
other measures to avoid people doing the wrong thing.
>
> > > > > I guess another part of the problem is that historically almost all
> > > > > platforms were in the first case I list above, no run time provided
> > > > > device tree, so we took the kernel one and added our bindings to it.
> > > > > Now we're being bit by the growing number of platforms that are the
> > > > > second case, and how do we get our properties in there, and which ones
> > > > > even make sense to do that for.
> > > >
> > > > I think upstreaming the bindings is the solution there. I've made a
> > > > start, but we need to make progress with this series and all the other
> > > > things in flight. I think a lot of people want U-Boot to not have a
> > > > devicetree source files in it for ARMv8 platforms. I am strongly
> > > > opposed to that. I've laid out my reasons very clearly in the past. I
> > > > think this is a good summary:
> > > >
> > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
> > >
> > > Yes, there are some ARMv8 platforms we will have to have the source
> > > files to, in tree, because they won't come to us at run time. But
> > > others we won't for practical reasons, namely that we can't statically
> > > provide something that exists dynamically without massive duplication of
> > > code or just taking things from that passed to us tree.
> >
> > So let's require that the static ones have the Linux DT in our tree
> > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If
> > that's it then I can agree a special case for them, so long as we sort
> > out the docs for Xen.
>
> No Raspberry Pi (all models) and Apple M1 are also dynamic. And there
> are probably a few more that I'm not familliar with. We've explain
> how these are dynamic in this thread and earlier discussions many
> times already, but I can do it again if you need me to.
So long as the DT is available in U-Boot and we can do development
there, I am happy. It is when it comes from somewhere else and we need
to do investigation just to be able to figure it out, I am not happy.
[..]
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-04 15:20 ` Simon Glass
2021-12-04 15:58 ` Ilias Apalodimas
2021-12-04 16:02 ` Mark Kettenis
@ 2021-12-04 16:55 ` François Ozog
2021-12-04 17:35 ` Simon Glass
2021-12-04 18:03 ` Tom Rini
3 siblings, 1 reply; 136+ messages in thread
From: François Ozog @ 2021-12-04 16:55 UTC (permalink / raw)
To: Simon Glass
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons, Tom Rini,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Simon
Le sam. 4 déc. 2021 à 16:21, Simon Glass <sjg@chromium.org> a écrit :
> Hi Tom,
>
> On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> >
> > [huge snip]
> > > > There's things that need to be cleaned up because we have some small
> > > > number of platforms that went off and did their own thing. But
> largely
> > > > yes, things make sense to me. We have:
> > > > - We embedded the device tree that will configure U-Boot, because
> there
> > > > is no way for the hardware to have provided us one.
> > > > - We do not embed the device tree that will configure U-Boot, because
> > > > there is already one present in memory for us to use.
> > > >
> > > > Then we have the developer option of:
> > > > - We embedded the device tree that will configure U-Boot, because
> we're
> > > > developing something.
> > >
> > > Yes, agreed those are the cases. To me this needs to be a run-time
> choice.
> >
> > But it's not possible. That's the problem we keep going around and
> > around about. People keep raising real life examples where you cannot
> > make a run time choice between "device tree we're passed at run time"
> > and "device tree we're compiled with".
>
> I haven't seen one. The most extreme case is QEMU and it works fine. I
> even added a test with it. What am I missing?
>
> >
> > And it's not helpful. It is ALWAYS the case that we know that we want
> > to override the run time device tree with our own, because it's a
> > developer developing things or it's a user / production case where we
> > must use the provided tree. NOT doing that is what leads to madness
> > like we see for example on Pi where if we don't use the passed tree we
> > still need to copy X/Y/Z out of it.
>
> Aren't you talking about the distro DT there, rather than the the one
> on the boot disk? That is my reading of that patch. If we need to do
> that sort of thing, it doesn't matter where the the cointrol DT comes
> from. You are still going to have to do that sort of thing.
>
> It is not ALWAYS the case. I've shown you how easy it is to disable
> OF_BOARD and still boot / iterate.
>
> >
> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we
> should
> > > > > provide a way to do that? But what is driving that desire?
> > > >
> > > > I'm looking for ways to convince you that we do not need to include a
> > > > device tree in the binary. There's a growing set of devices where
> the
> > > > device tree exists with the device. If it's missing, that's a huge
> > > > fatal error we can't do all that much about. If we need to do
> something
> > > > to that device tree for U-Boot, yes, fine, we should make it straight
> > > > forward for the developer to do that. But that's not the common
> case!
> > >
> > > Well we could add another Kconfig which tells U-Boot not to include a
> > > devicetree in u-boot.bin, if that would resolve this?
> > >
> > > I just want to make sure that we always build the devicetrees and that
> > > it is easy for a knowledgeable dev to switch over to use them, without
> > > spelunking through dozens of other projects to discover the secret DT
> > > that no one will tell us about.
> >
> > Should we demand better documentation for boards? Yes. But it's still
> > a valid case to have zero device trees for a given platform in-tree.
> > Xen is an example of this. QEMU is an example of this. Platforms need
> > to work without adding special tweaks for us. Maybe that means some
> > features can't be tested in QEMU-as-virtual-platform and only in
> > QEMU-faithfully-emulating-specific-physical-platforms.
>
> You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
> case, I think. How about we create a special Kconfig for that case? We
> need to make some progress here.
>
> >
> > > > I guess another part of the problem is that historically almost all
> > > > platforms were in the first case I list above, no run time provided
> > > > device tree, so we took the kernel one and added our bindings to it.
> > > > Now we're being bit by the growing number of platforms that are the
> > > > second case, and how do we get our properties in there, and which
> ones
> > > > even make sense to do that for.
> > >
> > > I think upstreaming the bindings is the solution there. I've made a
> > > start, but we need to make progress with this series and all the other
> > > things in flight. I think a lot of people want U-Boot to not have a
> > > devicetree source files in it for ARMv8 platforms. I am strongly
> > > opposed to that. I've laid out my reasons very clearly in the past. I
> > > think this is a good summary:
> > >
> > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
> >
> > Yes, there are some ARMv8 platforms we will have to have the source
> > files to, in tree, because they won't come to us at run time. But
> > others we won't for practical reasons, namely that we can't statically
> > provide something that exists dynamically without massive duplication of
> > code or just taking things from that passed to us tree.
>
> So let's require that the static ones have the Linux DT in our tree
> for now. The dynamic ones are just QEMU for ARM and Xen, I think. If
> that's it then I can agree a special case for them, so long as we sort
> out the docs for Xen.
>
> >
> > > I believe I have been consistent in this although with all the
> > > discussion I'm really not sure anymore.
> >
> > Yes, everyone has been consistent in these discussions.
>
> I'd like to think more people accept that U-Boot is allowed its own
> properties than did at the start.
there is no question that U-Boot can have its properties specified in
Device Tree.
What we may not agree in is how those properties make it to U-Boot.
>
>
> >
> > > The problem is that various people have various views about how U-Boot
> > > should work with devicetree. I strongly believe that until we have
> > > bindings upstream, a central repo for DTs with easy downloading for
> > > builds, automated validation, among other things, we must maintain the
> > > devicetree in U-Boot. Just from the POV of energy expended, I do not
> > > want to be arguing with the Linaro folks about what U-Boot is allowed
> > > to do every month for the next two years. I'd rather set out the stall
> > > now and then deal with the problems it causes from that perspective.
> >
> > The problems of the last going on 12 years won't be solved instantly.
> > The conflict as I see it is that you're insisting that all platforms
> > must have statically usable device trees, and I (and I believe others)
> > are saying that's unreasonable in cases where the trees are dynamic at
> > heart, lets just ensure we have good enough documentation for them,
> > which we don't today.
> >
> > To be clear and pick an example, I don't want Pi dts files in U-Boot,
> > but, OK, it's an easy enough case to sync them up and so long as we
> > aren't yet at the "now we pick at run time between compiled in or passed
> > to us dtb", I can accept them in tree, but not in the resulting binary
> > for OF_CONTROL=y. But as the Xen folks have also noted, there's no
> > reasonable tree to include there. It does need to be better documented
> > how to fire it up however, in our sources.
>
> I'm OK with us copying in the Linux devicetree and using that. But
> OF_BOARD must be a run-time option and able to be disabled. The
> devicetree must be built, so it is actually real. We can have a
> separate OF_OMIT or something like that to omit the devicetree from
> the output image, perhaps.
>
> All of the other things need to wait until we make progress with
> devicetree bindings, validation,
>
> How can we make progress on this? We have different goals, as I have
> explained, so we are not going to agree on everything.
>
A V7 with empty device trees (except with comments to explain why they are
empty and how to force one for dev purposes) for platforms that provide
U-Boot with DT (RPI, Qemu, xen…) seem a good base unless someone can
propose a better way forward. If we build consensus on the feature aspect
of the patch set I will be able to dedicate some time on the documentation
part as I thought it was useless to check those until we agree on the
functional part.
>
> Regards,
> Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-04 16:55 ` François Ozog
@ 2021-12-04 17:35 ` Simon Glass
2021-12-04 18:52 ` François Ozog
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-04 17:35 UTC (permalink / raw)
To: François Ozog
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons, Tom Rini,
Tuomas Tynkkynen, U-Boot Mailing List
Hi François,
On Sat, 4 Dec 2021 at 09:55, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon
>
> Le sam. 4 déc. 2021 à 16:21, Simon Glass <sjg@chromium.org> a écrit :
>>
>> Hi Tom,
>>
>> On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote:
>> >
>> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
>> >
>> > [huge snip]
>> > > > There's things that need to be cleaned up because we have some small
>> > > > number of platforms that went off and did their own thing. But largely
>> > > > yes, things make sense to me. We have:
>> > > > - We embedded the device tree that will configure U-Boot, because there
>> > > > is no way for the hardware to have provided us one.
>> > > > - We do not embed the device tree that will configure U-Boot, because
>> > > > there is already one present in memory for us to use.
>> > > >
>> > > > Then we have the developer option of:
>> > > > - We embedded the device tree that will configure U-Boot, because we're
>> > > > developing something.
>> > >
>> > > Yes, agreed those are the cases. To me this needs to be a run-time choice.
>> >
>> > But it's not possible. That's the problem we keep going around and
>> > around about. People keep raising real life examples where you cannot
>> > make a run time choice between "device tree we're passed at run time"
>> > and "device tree we're compiled with".
>>
>> I haven't seen one. The most extreme case is QEMU and it works fine. I
>> even added a test with it. What am I missing?
>>
>> >
>> > And it's not helpful. It is ALWAYS the case that we know that we want
>> > to override the run time device tree with our own, because it's a
>> > developer developing things or it's a user / production case where we
>> > must use the provided tree. NOT doing that is what leads to madness
>> > like we see for example on Pi where if we don't use the passed tree we
>> > still need to copy X/Y/Z out of it.
>>
>> Aren't you talking about the distro DT there, rather than the the one
>> on the boot disk? That is my reading of that patch. If we need to do
>> that sort of thing, it doesn't matter where the the cointrol DT comes
>> from. You are still going to have to do that sort of thing.
>>
>> It is not ALWAYS the case. I've shown you how easy it is to disable
>> OF_BOARD and still boot / iterate.
>>
>> >
>> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should
>> > > > > provide a way to do that? But what is driving that desire?
>> > > >
>> > > > I'm looking for ways to convince you that we do not need to include a
>> > > > device tree in the binary. There's a growing set of devices where the
>> > > > device tree exists with the device. If it's missing, that's a huge
>> > > > fatal error we can't do all that much about. If we need to do something
>> > > > to that device tree for U-Boot, yes, fine, we should make it straight
>> > > > forward for the developer to do that. But that's not the common case!
>> > >
>> > > Well we could add another Kconfig which tells U-Boot not to include a
>> > > devicetree in u-boot.bin, if that would resolve this?
>> > >
>> > > I just want to make sure that we always build the devicetrees and that
>> > > it is easy for a knowledgeable dev to switch over to use them, without
>> > > spelunking through dozens of other projects to discover the secret DT
>> > > that no one will tell us about.
>> >
>> > Should we demand better documentation for boards? Yes. But it's still
>> > a valid case to have zero device trees for a given platform in-tree.
>> > Xen is an example of this. QEMU is an example of this. Platforms need
>> > to work without adding special tweaks for us. Maybe that means some
>> > features can't be tested in QEMU-as-virtual-platform and only in
>> > QEMU-faithfully-emulating-specific-physical-platforms.
>>
>> You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
>> case, I think. How about we create a special Kconfig for that case? We
>> need to make some progress here.
>>
>> >
>> > > > I guess another part of the problem is that historically almost all
>> > > > platforms were in the first case I list above, no run time provided
>> > > > device tree, so we took the kernel one and added our bindings to it.
>> > > > Now we're being bit by the growing number of platforms that are the
>> > > > second case, and how do we get our properties in there, and which ones
>> > > > even make sense to do that for.
>> > >
>> > > I think upstreaming the bindings is the solution there. I've made a
>> > > start, but we need to make progress with this series and all the other
>> > > things in flight. I think a lot of people want U-Boot to not have a
>> > > devicetree source files in it for ARMv8 platforms. I am strongly
>> > > opposed to that. I've laid out my reasons very clearly in the past. I
>> > > think this is a good summary:
>> > >
>> > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
>> >
>> > Yes, there are some ARMv8 platforms we will have to have the source
>> > files to, in tree, because they won't come to us at run time. But
>> > others we won't for practical reasons, namely that we can't statically
>> > provide something that exists dynamically without massive duplication of
>> > code or just taking things from that passed to us tree.
>>
>> So let's require that the static ones have the Linux DT in our tree
>> for now. The dynamic ones are just QEMU for ARM and Xen, I think. If
>> that's it then I can agree a special case for them, so long as we sort
>> out the docs for Xen.
>>
>> >
>> > > I believe I have been consistent in this although with all the
>> > > discussion I'm really not sure anymore.
>> >
>> > Yes, everyone has been consistent in these discussions.
>>
>> I'd like to think more people accept that U-Boot is allowed its own
>> properties than did at the start.
>
> there is no question that U-Boot can have its properties specified in Device Tree.
I am pretty sure you were on the other side of that fence at some
point. I know quite a few others that still are.
> What we may not agree in is how those properties make it to U-Boot.
Yes but that is just the next step along in my progression in that
email ('why can't we just...' to 'this is how U-Boot works'). From
memory there are 3 more steps.
>>
>>
>>
>> >
>> > > The problem is that various people have various views about how U-Boot
>> > > should work with devicetree. I strongly believe that until we have
>> > > bindings upstream, a central repo for DTs with easy downloading for
>> > > builds, automated validation, among other things, we must maintain the
>> > > devicetree in U-Boot. Just from the POV of energy expended, I do not
>> > > want to be arguing with the Linaro folks about what U-Boot is allowed
>> > > to do every month for the next two years. I'd rather set out the stall
>> > > now and then deal with the problems it causes from that perspective.
>> >
>> > The problems of the last going on 12 years won't be solved instantly.
>> > The conflict as I see it is that you're insisting that all platforms
>> > must have statically usable device trees, and I (and I believe others)
>> > are saying that's unreasonable in cases where the trees are dynamic at
>> > heart, lets just ensure we have good enough documentation for them,
>> > which we don't today.
>> >
>> > To be clear and pick an example, I don't want Pi dts files in U-Boot,
>> > but, OK, it's an easy enough case to sync them up and so long as we
>> > aren't yet at the "now we pick at run time between compiled in or passed
>> > to us dtb", I can accept them in tree, but not in the resulting binary
>> > for OF_CONTROL=y. But as the Xen folks have also noted, there's no
>> > reasonable tree to include there. It does need to be better documented
>> > how to fire it up however, in our sources.
>>
>> I'm OK with us copying in the Linux devicetree and using that. But
>> OF_BOARD must be a run-time option and able to be disabled. The
>> devicetree must be built, so it is actually real. We can have a
>> separate OF_OMIT or something like that to omit the devicetree from
>> the output image, perhaps.
>>
>> All of the other things need to wait until we make progress with
>> devicetree bindings, validation,
>>
>> How can we make progress on this? We have different goals, as I have
>> explained, so we are not going to agree on everything.
>
> A V7 with empty device trees (except with comments to explain why they are empty and how to force one for dev purposes) for platforms that provide U-Boot with DT (RPI, Qemu, xen…) seem a good base unless someone can propose a better way forward. If we build consensus on the feature aspect of the patch set I will be able to dedicate some time on the documentation part as I thought it was useless to check those until we agree on the functional part.
That's the status quo, so it doesn't resolve any of my concerns,
sorry. I suggest:
- Check in all the DTs we can get (e.g. from Linux), and build them
- Use an empty one if we cannot find it, and ask the maintainer to add
docs and deal with it
- For QEMU arm and QEMU RISC-V (i.e. the 'virt' case), use a base one
that works with the base QEMU config
We then have the follow-ons that Tom and I have discussed, e.g. the
Kconfig option that Mark mentioned.
That will clear up all the confusion and provide a baseline for how DT
is dealt with in U-Boot.
We should then continue on the path towards upstreaming bindings,
syncing DT with Linux, validation, removing them from U-Boot if we can
automatically download them all from somewhere, etc.
The thing is, I think people are more aligned on the eventual goal
than on this series. My concern is that without this series, it will
continue to be crazy-town and no one will be able to find anything
without manual effort. For those of us who deal with more than one
platform, this is an important point.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-04 17:35 ` Simon Glass
@ 2021-12-04 18:52 ` François Ozog
2021-12-05 13:32 ` Tom Rini
0 siblings, 1 reply; 136+ messages in thread
From: François Ozog @ 2021-12-04 18:52 UTC (permalink / raw)
To: Simon Glass
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons, Tom Rini,
Tuomas Tynkkynen, U-Boot Mailing List
Hi Simon
Le sam. 4 déc. 2021 à 18:35, Simon Glass <sjg@chromium.org> a écrit :
> Hi François,
>
> On Sat, 4 Dec 2021 at 09:55, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> > Hi Simon
> >
> > Le sam. 4 déc. 2021 à 16:21, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> Hi Tom,
> >>
> >> On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote:
> >> >
> >> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> >> >
> >> > [huge snip]
> >> > > > There's things that need to be cleaned up because we have some
> small
> >> > > > number of platforms that went off and did their own thing. But
> largely
> >> > > > yes, things make sense to me. We have:
> >> > > > - We embedded the device tree that will configure U-Boot, because
> there
> >> > > > is no way for the hardware to have provided us one.
> >> > > > - We do not embed the device tree that will configure U-Boot,
> because
> >> > > > there is already one present in memory for us to use.
> >> > > >
> >> > > > Then we have the developer option of:
> >> > > > - We embedded the device tree that will configure U-Boot, because
> we're
> >> > > > developing something.
> >> > >
> >> > > Yes, agreed those are the cases. To me this needs to be a run-time
> choice.
> >> >
> >> > But it's not possible. That's the problem we keep going around and
> >> > around about. People keep raising real life examples where you cannot
> >> > make a run time choice between "device tree we're passed at run time"
> >> > and "device tree we're compiled with".
> >>
> >> I haven't seen one. The most extreme case is QEMU and it works fine. I
> >> even added a test with it. What am I missing?
> >>
> >> >
> >> > And it's not helpful. It is ALWAYS the case that we know that we want
> >> > to override the run time device tree with our own, because it's a
> >> > developer developing things or it's a user / production case where we
> >> > must use the provided tree. NOT doing that is what leads to madness
> >> > like we see for example on Pi where if we don't use the passed tree we
> >> > still need to copy X/Y/Z out of it.
> >>
> >> Aren't you talking about the distro DT there, rather than the the one
> >> on the boot disk? That is my reading of that patch. If we need to do
> >> that sort of thing, it doesn't matter where the the cointrol DT comes
> >> from. You are still going to have to do that sort of thing.
> >>
> >> It is not ALWAYS the case. I've shown you how easy it is to disable
> >> OF_BOARD and still boot / iterate.
> >>
> >> >
> >> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we
> should
> >> > > > > provide a way to do that? But what is driving that desire?
> >> > > >
> >> > > > I'm looking for ways to convince you that we do not need to
> include a
> >> > > > device tree in the binary. There's a growing set of devices
> where the
> >> > > > device tree exists with the device. If it's missing, that's a
> huge
> >> > > > fatal error we can't do all that much about. If we need to do
> something
> >> > > > to that device tree for U-Boot, yes, fine, we should make it
> straight
> >> > > > forward for the developer to do that. But that's not the common
> case!
> >> > >
> >> > > Well we could add another Kconfig which tells U-Boot not to include
> a
> >> > > devicetree in u-boot.bin, if that would resolve this?
> >> > >
> >> > > I just want to make sure that we always build the devicetrees and
> that
> >> > > it is easy for a knowledgeable dev to switch over to use them,
> without
> >> > > spelunking through dozens of other projects to discover the secret
> DT
> >> > > that no one will tell us about.
> >> >
> >> > Should we demand better documentation for boards? Yes. But it's
> still
> >> > a valid case to have zero device trees for a given platform in-tree.
> >> > Xen is an example of this. QEMU is an example of this. Platforms
> need
> >> > to work without adding special tweaks for us. Maybe that means some
> >> > features can't be tested in QEMU-as-virtual-platform and only in
> >> > QEMU-faithfully-emulating-specific-physical-platforms.
> >>
> >> You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
> >> case, I think. How about we create a special Kconfig for that case? We
> >> need to make some progress here.
> >>
> >> >
> >> > > > I guess another part of the problem is that historically almost
> all
> >> > > > platforms were in the first case I list above, no run time
> provided
> >> > > > device tree, so we took the kernel one and added our bindings to
> it.
> >> > > > Now we're being bit by the growing number of platforms that are
> the
> >> > > > second case, and how do we get our properties in there, and which
> ones
> >> > > > even make sense to do that for.
> >> > >
> >> > > I think upstreaming the bindings is the solution there. I've made a
> >> > > start, but we need to make progress with this series and all the
> other
> >> > > things in flight. I think a lot of people want U-Boot to not have a
> >> > > devicetree source files in it for ARMv8 platforms. I am strongly
> >> > > opposed to that. I've laid out my reasons very clearly in the past.
> I
> >> > > think this is a good summary:
> >> > >
> >> > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
> >> >
> >> > Yes, there are some ARMv8 platforms we will have to have the source
> >> > files to, in tree, because they won't come to us at run time. But
> >> > others we won't for practical reasons, namely that we can't statically
> >> > provide something that exists dynamically without massive duplication
> of
> >> > code or just taking things from that passed to us tree.
> >>
> >> So let's require that the static ones have the Linux DT in our tree
> >> for now. The dynamic ones are just QEMU for ARM and Xen, I think. If
> >> that's it then I can agree a special case for them, so long as we sort
> >> out the docs for Xen.
> >>
> >> >
> >> > > I believe I have been consistent in this although with all the
> >> > > discussion I'm really not sure anymore.
> >> >
> >> > Yes, everyone has been consistent in these discussions.
> >>
> >> I'd like to think more people accept that U-Boot is allowed its own
> >> properties than did at the start.
> >
> > there is no question that U-Boot can have its properties specified in
> Device Tree.
>
> I am pretty sure you were on the other side of that fence at some
> point. I know quite a few others that still are.
>
> > What we may not agree in is how those properties make it to U-Boot.
>
> Yes but that is just the next step along in my progression in that
> email ('why can't we just...' to 'this is how U-Boot works'). From
> memory there are 3 more steps.
>
> >>
> >>
> >>
> >> >
> >> > > The problem is that various people have various views about how
> U-Boot
> >> > > should work with devicetree. I strongly believe that until we have
> >> > > bindings upstream, a central repo for DTs with easy downloading for
> >> > > builds, automated validation, among other things, we must maintain
> the
> >> > > devicetree in U-Boot. Just from the POV of energy expended, I do not
> >> > > want to be arguing with the Linaro folks about what U-Boot is
> allowed
> >> > > to do every month for the next two years. I'd rather set out the
> stall
> >> > > now and then deal with the problems it causes from that perspective.
> >> >
> >> > The problems of the last going on 12 years won't be solved instantly.
> >> > The conflict as I see it is that you're insisting that all platforms
> >> > must have statically usable device trees, and I (and I believe others)
> >> > are saying that's unreasonable in cases where the trees are dynamic at
> >> > heart, lets just ensure we have good enough documentation for them,
> >> > which we don't today.
> >> >
> >> > To be clear and pick an example, I don't want Pi dts files in U-Boot,
> >> > but, OK, it's an easy enough case to sync them up and so long as we
> >> > aren't yet at the "now we pick at run time between compiled in or
> passed
> >> > to us dtb", I can accept them in tree, but not in the resulting binary
> >> > for OF_CONTROL=y. But as the Xen folks have also noted, there's no
> >> > reasonable tree to include there. It does need to be better
> documented
> >> > how to fire it up however, in our sources.
> >>
> >> I'm OK with us copying in the Linux devicetree and using that. But
> >> OF_BOARD must be a run-time option and able to be disabled. The
> >> devicetree must be built, so it is actually real. We can have a
> >> separate OF_OMIT or something like that to omit the devicetree from
> >> the output image, perhaps.
> >>
> >> All of the other things need to wait until we make progress with
> >> devicetree bindings, validation,
> >>
> >> How can we make progress on this? We have different goals, as I have
> >> explained, so we are not going to agree on everything.
> >
> > A V7 with empty device trees (except with comments to explain why they
> are empty and how to force one for dev purposes) for platforms that provide
> U-Boot with DT (RPI, Qemu, xen…) seem a good base unless someone can
> propose a better way forward. If we build consensus on the feature aspect
> of the patch set I will be able to dedicate some time on the documentation
> part as I thought it was useless to check those until we agree on the
> functional part.
>
> That's the status quo, so it doesn't resolve any of my concerns,
> sorry. I suggest:
>
You make progress on various front that can get consensus in a number of
your patches, so it it not status quo.
>
> - Check in all the DTs we can get (e.g. from Linux), and build them
doesn’t change anytime. RPI4 DT in the kernel is not be used anyways.
>
> - Use an empty one if we cannot find it, and ask the maintainer to add
> docs and deal with it
> - For QEMU arm and QEMU RISC-V (i.e. the 'virt' case), use a base one
> that works with the base QEMU config
>
> We then have the follow-ons that Tom and I have discussed, e.g. the
> Kconfig option that Mark mentioned.
>
> That will clear up all the confusion and provide a baseline for how DT
> is dealt with in U-Boot.
>
> We should then continue on the path towards upstreaming bindings,
> syncing DT with Linux, validation, removing them from U-Boot if we can
> automatically download them all from somewhere, etc.
>
> The thing is, I think people are more aligned on the eventual goal
> than on this series.
I’d interested to know that. Should we ask +1, -1, -2 for the patches?
> My concern is that without this series, it will
> continue to be crazy-town and no one will be able to find anything
> without manual effort. For those of us who deal with more than one
> platform, this is an important point.
>
> Regards,
> Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-04 18:52 ` François Ozog
@ 2021-12-05 13:32 ` Tom Rini
0 siblings, 0 replies; 136+ messages in thread
From: Tom Rini @ 2021-12-05 13:32 UTC (permalink / raw)
To: François Ozog
Cc: Simon Glass, Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 10681 bytes --]
On Sat, Dec 04, 2021 at 07:52:46PM +0100, François Ozog wrote:
> Hi Simon
>
> Le sam. 4 déc. 2021 à 18:35, Simon Glass <sjg@chromium.org> a écrit :
>
> > Hi François,
> >
> > On Sat, 4 Dec 2021 at 09:55, François Ozog <francois.ozog@linaro.org>
> > wrote:
> > >
> > > Hi Simon
> > >
> > > Le sam. 4 déc. 2021 à 16:21, Simon Glass <sjg@chromium.org> a écrit :
> > >>
> > >> Hi Tom,
> > >>
> > >> On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote:
> > >> >
> > >> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> > >> >
> > >> > [huge snip]
> > >> > > > There's things that need to be cleaned up because we have some
> > small
> > >> > > > number of platforms that went off and did their own thing. But
> > largely
> > >> > > > yes, things make sense to me. We have:
> > >> > > > - We embedded the device tree that will configure U-Boot, because
> > there
> > >> > > > is no way for the hardware to have provided us one.
> > >> > > > - We do not embed the device tree that will configure U-Boot,
> > because
> > >> > > > there is already one present in memory for us to use.
> > >> > > >
> > >> > > > Then we have the developer option of:
> > >> > > > - We embedded the device tree that will configure U-Boot, because
> > we're
> > >> > > > developing something.
> > >> > >
> > >> > > Yes, agreed those are the cases. To me this needs to be a run-time
> > choice.
> > >> >
> > >> > But it's not possible. That's the problem we keep going around and
> > >> > around about. People keep raising real life examples where you cannot
> > >> > make a run time choice between "device tree we're passed at run time"
> > >> > and "device tree we're compiled with".
> > >>
> > >> I haven't seen one. The most extreme case is QEMU and it works fine. I
> > >> even added a test with it. What am I missing?
> > >>
> > >> >
> > >> > And it's not helpful. It is ALWAYS the case that we know that we want
> > >> > to override the run time device tree with our own, because it's a
> > >> > developer developing things or it's a user / production case where we
> > >> > must use the provided tree. NOT doing that is what leads to madness
> > >> > like we see for example on Pi where if we don't use the passed tree we
> > >> > still need to copy X/Y/Z out of it.
> > >>
> > >> Aren't you talking about the distro DT there, rather than the the one
> > >> on the boot disk? That is my reading of that patch. If we need to do
> > >> that sort of thing, it doesn't matter where the the cointrol DT comes
> > >> from. You are still going to have to do that sort of thing.
> > >>
> > >> It is not ALWAYS the case. I've shown you how easy it is to disable
> > >> OF_BOARD and still boot / iterate.
> > >>
> > >> >
> > >> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we
> > should
> > >> > > > > provide a way to do that? But what is driving that desire?
> > >> > > >
> > >> > > > I'm looking for ways to convince you that we do not need to
> > include a
> > >> > > > device tree in the binary. There's a growing set of devices
> > where the
> > >> > > > device tree exists with the device. If it's missing, that's a
> > huge
> > >> > > > fatal error we can't do all that much about. If we need to do
> > something
> > >> > > > to that device tree for U-Boot, yes, fine, we should make it
> > straight
> > >> > > > forward for the developer to do that. But that's not the common
> > case!
> > >> > >
> > >> > > Well we could add another Kconfig which tells U-Boot not to include
> > a
> > >> > > devicetree in u-boot.bin, if that would resolve this?
> > >> > >
> > >> > > I just want to make sure that we always build the devicetrees and
> > that
> > >> > > it is easy for a knowledgeable dev to switch over to use them,
> > without
> > >> > > spelunking through dozens of other projects to discover the secret
> > DT
> > >> > > that no one will tell us about.
> > >> >
> > >> > Should we demand better documentation for boards? Yes. But it's
> > still
> > >> > a valid case to have zero device trees for a given platform in-tree.
> > >> > Xen is an example of this. QEMU is an example of this. Platforms
> > need
> > >> > to work without adding special tweaks for us. Maybe that means some
> > >> > features can't be tested in QEMU-as-virtual-platform and only in
> > >> > QEMU-faithfully-emulating-specific-physical-platforms.
> > >>
> > >> You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
> > >> case, I think. How about we create a special Kconfig for that case? We
> > >> need to make some progress here.
> > >>
> > >> >
> > >> > > > I guess another part of the problem is that historically almost
> > all
> > >> > > > platforms were in the first case I list above, no run time
> > provided
> > >> > > > device tree, so we took the kernel one and added our bindings to
> > it.
> > >> > > > Now we're being bit by the growing number of platforms that are
> > the
> > >> > > > second case, and how do we get our properties in there, and which
> > ones
> > >> > > > even make sense to do that for.
> > >> > >
> > >> > > I think upstreaming the bindings is the solution there. I've made a
> > >> > > start, but we need to make progress with this series and all the
> > other
> > >> > > things in flight. I think a lot of people want U-Boot to not have a
> > >> > > devicetree source files in it for ARMv8 platforms. I am strongly
> > >> > > opposed to that. I've laid out my reasons very clearly in the past.
> > I
> > >> > > think this is a good summary:
> > >> > >
> > >> > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
> > >> >
> > >> > Yes, there are some ARMv8 platforms we will have to have the source
> > >> > files to, in tree, because they won't come to us at run time. But
> > >> > others we won't for practical reasons, namely that we can't statically
> > >> > provide something that exists dynamically without massive duplication
> > of
> > >> > code or just taking things from that passed to us tree.
> > >>
> > >> So let's require that the static ones have the Linux DT in our tree
> > >> for now. The dynamic ones are just QEMU for ARM and Xen, I think. If
> > >> that's it then I can agree a special case for them, so long as we sort
> > >> out the docs for Xen.
> > >>
> > >> >
> > >> > > I believe I have been consistent in this although with all the
> > >> > > discussion I'm really not sure anymore.
> > >> >
> > >> > Yes, everyone has been consistent in these discussions.
> > >>
> > >> I'd like to think more people accept that U-Boot is allowed its own
> > >> properties than did at the start.
> > >
> > > there is no question that U-Boot can have its properties specified in
> > Device Tree.
> >
> > I am pretty sure you were on the other side of that fence at some
> > point. I know quite a few others that still are.
> >
> > > What we may not agree in is how those properties make it to U-Boot.
> >
> > Yes but that is just the next step along in my progression in that
> > email ('why can't we just...' to 'this is how U-Boot works'). From
> > memory there are 3 more steps.
> >
> > >>
> > >>
> > >>
> > >> >
> > >> > > The problem is that various people have various views about how
> > U-Boot
> > >> > > should work with devicetree. I strongly believe that until we have
> > >> > > bindings upstream, a central repo for DTs with easy downloading for
> > >> > > builds, automated validation, among other things, we must maintain
> > the
> > >> > > devicetree in U-Boot. Just from the POV of energy expended, I do not
> > >> > > want to be arguing with the Linaro folks about what U-Boot is
> > allowed
> > >> > > to do every month for the next two years. I'd rather set out the
> > stall
> > >> > > now and then deal with the problems it causes from that perspective.
> > >> >
> > >> > The problems of the last going on 12 years won't be solved instantly.
> > >> > The conflict as I see it is that you're insisting that all platforms
> > >> > must have statically usable device trees, and I (and I believe others)
> > >> > are saying that's unreasonable in cases where the trees are dynamic at
> > >> > heart, lets just ensure we have good enough documentation for them,
> > >> > which we don't today.
> > >> >
> > >> > To be clear and pick an example, I don't want Pi dts files in U-Boot,
> > >> > but, OK, it's an easy enough case to sync them up and so long as we
> > >> > aren't yet at the "now we pick at run time between compiled in or
> > passed
> > >> > to us dtb", I can accept them in tree, but not in the resulting binary
> > >> > for OF_CONTROL=y. But as the Xen folks have also noted, there's no
> > >> > reasonable tree to include there. It does need to be better
> > documented
> > >> > how to fire it up however, in our sources.
> > >>
> > >> I'm OK with us copying in the Linux devicetree and using that. But
> > >> OF_BOARD must be a run-time option and able to be disabled. The
> > >> devicetree must be built, so it is actually real. We can have a
> > >> separate OF_OMIT or something like that to omit the devicetree from
> > >> the output image, perhaps.
> > >>
> > >> All of the other things need to wait until we make progress with
> > >> devicetree bindings, validation,
> > >>
> > >> How can we make progress on this? We have different goals, as I have
> > >> explained, so we are not going to agree on everything.
> > >
> > > A V7 with empty device trees (except with comments to explain why they
> > are empty and how to force one for dev purposes) for platforms that provide
> > U-Boot with DT (RPI, Qemu, xen…) seem a good base unless someone can
> > propose a better way forward. If we build consensus on the feature aspect
> > of the patch set I will be able to dedicate some time on the documentation
> > part as I thought it was useless to check those until we agree on the
> > functional part.
> >
> > That's the status quo, so it doesn't resolve any of my concerns,
> > sorry. I suggest:
> >
> You make progress on various front that can get consensus in a number of
> your patches, so it it not status quo.
>
> >
> > - Check in all the DTs we can get (e.g. from Linux), and build them
>
> doesn’t change anytime. RPI4 DT in the kernel is not be used anyways.
Well, the kernel DTS files for Pi are, and aren't exactly used, yes?
The dtbs are built from the kernel, then passed to the Pi firmware and
updated based on config.txt and other relevant things, yes?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-04 15:20 ` Simon Glass
` (2 preceding siblings ...)
2021-12-04 16:55 ` François Ozog
@ 2021-12-04 18:03 ` Tom Rini
2021-12-04 22:09 ` Simon Glass
3 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-04 18:03 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng, Jerry Van Baren,
Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen
[-- Attachment #1: Type: text/plain, Size: 10312 bytes --]
On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> >
> > [huge snip]
> > > > There's things that need to be cleaned up because we have some small
> > > > number of platforms that went off and did their own thing. But largely
> > > > yes, things make sense to me. We have:
> > > > - We embedded the device tree that will configure U-Boot, because there
> > > > is no way for the hardware to have provided us one.
> > > > - We do not embed the device tree that will configure U-Boot, because
> > > > there is already one present in memory for us to use.
> > > >
> > > > Then we have the developer option of:
> > > > - We embedded the device tree that will configure U-Boot, because we're
> > > > developing something.
> > >
> > > Yes, agreed those are the cases. To me this needs to be a run-time choice.
> >
> > But it's not possible. That's the problem we keep going around and
> > around about. People keep raising real life examples where you cannot
> > make a run time choice between "device tree we're passed at run time"
> > and "device tree we're compiled with".
>
> I haven't seen one. The most extreme case is QEMU and it works fine. I
> even added a test with it. What am I missing?
QEMU and Xen should both never have an in-source-tree dts as they are
dynamic. I think you missed the explanation about how U-Boot + Xen
works? You're running the same U-Boot under Xen on any arbitrary ARMv8
(with required features...) system. For QEMU virtual machines you're
not supposed to do what you're doing, for production.
> > And it's not helpful. It is ALWAYS the case that we know that we want
> > to override the run time device tree with our own, because it's a
> > developer developing things or it's a user / production case where we
> > must use the provided tree. NOT doing that is what leads to madness
> > like we see for example on Pi where if we don't use the passed tree we
> > still need to copy X/Y/Z out of it.
>
> Aren't you talking about the distro DT there, rather than the the one
> on the boot disk? That is my reading of that patch. If we need to do
> that sort of thing, it doesn't matter where the the cointrol DT comes
> from. You are still going to have to do that sort of thing.
>
> It is not ALWAYS the case. I've shown you how easy it is to disable
> OF_BOARD and still boot / iterate.
The DT we're passed in is the DT to pass to the OS. That's the hook for
putting a DTB on the device as it ships, the OS will just work. The
production case of needing to update that stored DTB is handled. It's
always what should be used, again outside of developer doing
development.
Maybe that's part of the confusion here too. The DTB U-Boot is using is
the DTB the OS will consume too, in the passed at run time case. Unless
we're instead going to save that DTB aside? Which leaves me with a
different set of design questions...
> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should
> > > > > provide a way to do that? But what is driving that desire?
> > > >
> > > > I'm looking for ways to convince you that we do not need to include a
> > > > device tree in the binary. There's a growing set of devices where the
> > > > device tree exists with the device. If it's missing, that's a huge
> > > > fatal error we can't do all that much about. If we need to do something
> > > > to that device tree for U-Boot, yes, fine, we should make it straight
> > > > forward for the developer to do that. But that's not the common case!
> > >
> > > Well we could add another Kconfig which tells U-Boot not to include a
> > > devicetree in u-boot.bin, if that would resolve this?
> > >
> > > I just want to make sure that we always build the devicetrees and that
> > > it is easy for a knowledgeable dev to switch over to use them, without
> > > spelunking through dozens of other projects to discover the secret DT
> > > that no one will tell us about.
> >
> > Should we demand better documentation for boards? Yes. But it's still
> > a valid case to have zero device trees for a given platform in-tree.
> > Xen is an example of this. QEMU is an example of this. Platforms need
> > to work without adding special tweaks for us. Maybe that means some
> > features can't be tested in QEMU-as-virtual-platform and only in
> > QEMU-faithfully-emulating-specific-physical-platforms.
>
> You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
> case, I think. How about we create a special Kconfig for that case? We
> need to make some progress here.
Yes, because there's a small number of OF_BOARD=y configs in tree right
now, most of which are QEMU virtual machines, others of which are Pi
(which we've talked to death), highbank (which Andre has explained), and
then the octeontx stuff I don't know how works. I keep pushing to say
that OF_BOARD=y is the special case we need to not overrule the device
tree provided to us on. Unless we start saving off that passed-to-us DTB
and then something-something for our own run-time DTB, and letting the
OS consume that passed-to-us one with only normal fixups applied.
> > > > I guess another part of the problem is that historically almost all
> > > > platforms were in the first case I list above, no run time provided
> > > > device tree, so we took the kernel one and added our bindings to it.
> > > > Now we're being bit by the growing number of platforms that are the
> > > > second case, and how do we get our properties in there, and which ones
> > > > even make sense to do that for.
> > >
> > > I think upstreaming the bindings is the solution there. I've made a
> > > start, but we need to make progress with this series and all the other
> > > things in flight. I think a lot of people want U-Boot to not have a
> > > devicetree source files in it for ARMv8 platforms. I am strongly
> > > opposed to that. I've laid out my reasons very clearly in the past. I
> > > think this is a good summary:
> > >
> > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
> >
> > Yes, there are some ARMv8 platforms we will have to have the source
> > files to, in tree, because they won't come to us at run time. But
> > others we won't for practical reasons, namely that we can't statically
> > provide something that exists dynamically without massive duplication of
> > code or just taking things from that passed to us tree.
>
> So let's require that the static ones have the Linux DT in our tree
> for now. The dynamic ones are just QEMU for ARM and Xen, I think. If
> that's it then I can agree a special case for them, so long as we sort
> out the docs for Xen.
I'm agreeable to saying that if the dts files exist in Linux (or other
official source locations) we should have those in-tree, and the board
maintainer doesn't object, yes. But I think that might be a slightly
different list than what you say here. And that punts the run-time
decision down the road. And I'm assuming you're OK with also not
including a dtb in the image.
> > > I believe I have been consistent in this although with all the
> > > discussion I'm really not sure anymore.
> >
> > Yes, everyone has been consistent in these discussions.
>
> I'd like to think more people accept that U-Boot is allowed its own
> properties than did at the start.
>
> >
> > > The problem is that various people have various views about how U-Boot
> > > should work with devicetree. I strongly believe that until we have
> > > bindings upstream, a central repo for DTs with easy downloading for
> > > builds, automated validation, among other things, we must maintain the
> > > devicetree in U-Boot. Just from the POV of energy expended, I do not
> > > want to be arguing with the Linaro folks about what U-Boot is allowed
> > > to do every month for the next two years. I'd rather set out the stall
> > > now and then deal with the problems it causes from that perspective.
> >
> > The problems of the last going on 12 years won't be solved instantly.
> > The conflict as I see it is that you're insisting that all platforms
> > must have statically usable device trees, and I (and I believe others)
> > are saying that's unreasonable in cases where the trees are dynamic at
> > heart, lets just ensure we have good enough documentation for them,
> > which we don't today.
> >
> > To be clear and pick an example, I don't want Pi dts files in U-Boot,
> > but, OK, it's an easy enough case to sync them up and so long as we
> > aren't yet at the "now we pick at run time between compiled in or passed
> > to us dtb", I can accept them in tree, but not in the resulting binary
> > for OF_CONTROL=y. But as the Xen folks have also noted, there's no
> > reasonable tree to include there. It does need to be better documented
> > how to fire it up however, in our sources.
>
> I'm OK with us copying in the Linux devicetree and using that. But
> OF_BOARD must be a run-time option and able to be disabled. The
> devicetree must be built, so it is actually real. We can have a
> separate OF_OMIT or something like that to omit the devicetree from
> the output image, perhaps.
You're changing the meaning of CONFIG options. I like the idea Mark
suggested (probably after you wrote this..) of introducing something new
for what you're talking about. But no, it's unreasonable to say that
every U-Boot binary will bundle one or more dtb and make a run time
decision about what to use as the normal way the world works.
> All of the other things need to wait until we make progress with
> devicetree bindings, validation,
>
> How can we make progress on this? We have different goals, as I have
> explained, so we are not going to agree on everything.
Replace patches 4 to 14 with syncing platforms dts files from current
Linux release, and when OF_BOARD=y don't include a device tree in the
resulting image? That might also need adding some documentation for
some platforms on where the device tree is and how to extract it.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-04 18:03 ` Tom Rini
@ 2021-12-04 22:09 ` Simon Glass
2021-12-05 13:32 ` Tom Rini
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-04 22:09 UTC (permalink / raw)
To: Tom Rini
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng, Jerry Van Baren,
Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen
Hi Tom,
On Sat, 4 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
>
> On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> > >
> > > [huge snip]
> > > > > There's things that need to be cleaned up because we have some small
> > > > > number of platforms that went off and did their own thing. But largely
> > > > > yes, things make sense to me. We have:
> > > > > - We embedded the device tree that will configure U-Boot, because there
> > > > > is no way for the hardware to have provided us one.
> > > > > - We do not embed the device tree that will configure U-Boot, because
> > > > > there is already one present in memory for us to use.
> > > > >
> > > > > Then we have the developer option of:
> > > > > - We embedded the device tree that will configure U-Boot, because we're
> > > > > developing something.
> > > >
> > > > Yes, agreed those are the cases. To me this needs to be a run-time choice.
> > >
> > > But it's not possible. That's the problem we keep going around and
> > > around about. People keep raising real life examples where you cannot
> > > make a run time choice between "device tree we're passed at run time"
> > > and "device tree we're compiled with".
> >
> > I haven't seen one. The most extreme case is QEMU and it works fine. I
> > even added a test with it. What am I missing?
>
> QEMU and Xen should both never have an in-source-tree dts as they are
> dynamic. I think you missed the explanation about how U-Boot + Xen
> works? You're running the same U-Boot under Xen on any arbitrary ARMv8
> (with required features...) system. For QEMU virtual machines you're
> not supposed to do what you're doing, for production.
>
> > > And it's not helpful. It is ALWAYS the case that we know that we want
> > > to override the run time device tree with our own, because it's a
> > > developer developing things or it's a user / production case where we
> > > must use the provided tree. NOT doing that is what leads to madness
> > > like we see for example on Pi where if we don't use the passed tree we
> > > still need to copy X/Y/Z out of it.
> >
> > Aren't you talking about the distro DT there, rather than the the one
> > on the boot disk? That is my reading of that patch. If we need to do
> > that sort of thing, it doesn't matter where the the cointrol DT comes
> > from. You are still going to have to do that sort of thing.
> >
> > It is not ALWAYS the case. I've shown you how easy it is to disable
> > OF_BOARD and still boot / iterate.
>
> The DT we're passed in is the DT to pass to the OS. That's the hook for
> putting a DTB on the device as it ships, the OS will just work. The
> production case of needing to update that stored DTB is handled. It's
> always what should be used, again outside of developer doing
> development.
>
> Maybe that's part of the confusion here too. The DTB U-Boot is using is
> the DTB the OS will consume too, in the passed at run time case. Unless
> we're instead going to save that DTB aside? Which leaves me with a
> different set of design questions...
>
> > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should
> > > > > > provide a way to do that? But what is driving that desire?
> > > > >
> > > > > I'm looking for ways to convince you that we do not need to include a
> > > > > device tree in the binary. There's a growing set of devices where the
> > > > > device tree exists with the device. If it's missing, that's a huge
> > > > > fatal error we can't do all that much about. If we need to do something
> > > > > to that device tree for U-Boot, yes, fine, we should make it straight
> > > > > forward for the developer to do that. But that's not the common case!
> > > >
> > > > Well we could add another Kconfig which tells U-Boot not to include a
> > > > devicetree in u-boot.bin, if that would resolve this?
> > > >
> > > > I just want to make sure that we always build the devicetrees and that
> > > > it is easy for a knowledgeable dev to switch over to use them, without
> > > > spelunking through dozens of other projects to discover the secret DT
> > > > that no one will tell us about.
> > >
> > > Should we demand better documentation for boards? Yes. But it's still
> > > a valid case to have zero device trees for a given platform in-tree.
> > > Xen is an example of this. QEMU is an example of this. Platforms need
> > > to work without adding special tweaks for us. Maybe that means some
> > > features can't be tested in QEMU-as-virtual-platform and only in
> > > QEMU-faithfully-emulating-specific-physical-platforms.
> >
> > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
> > case, I think. How about we create a special Kconfig for that case? We
> > need to make some progress here.
>
> Yes, because there's a small number of OF_BOARD=y configs in tree right
> now, most of which are QEMU virtual machines, others of which are Pi
> (which we've talked to death), highbank (which Andre has explained), and
> then the octeontx stuff I don't know how works. I keep pushing to say
> that OF_BOARD=y is the special case we need to not overrule the device
> tree provided to us on. Unless we start saving off that passed-to-us DTB
> and then something-something for our own run-time DTB, and letting the
> OS consume that passed-to-us one with only normal fixups applied.
>
> > > > > I guess another part of the problem is that historically almost all
> > > > > platforms were in the first case I list above, no run time provided
> > > > > device tree, so we took the kernel one and added our bindings to it.
> > > > > Now we're being bit by the growing number of platforms that are the
> > > > > second case, and how do we get our properties in there, and which ones
> > > > > even make sense to do that for.
> > > >
> > > > I think upstreaming the bindings is the solution there. I've made a
> > > > start, but we need to make progress with this series and all the other
> > > > things in flight. I think a lot of people want U-Boot to not have a
> > > > devicetree source files in it for ARMv8 platforms. I am strongly
> > > > opposed to that. I've laid out my reasons very clearly in the past. I
> > > > think this is a good summary:
> > > >
> > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
> > >
> > > Yes, there are some ARMv8 platforms we will have to have the source
> > > files to, in tree, because they won't come to us at run time. But
> > > others we won't for practical reasons, namely that we can't statically
> > > provide something that exists dynamically without massive duplication of
> > > code or just taking things from that passed to us tree.
> >
> > So let's require that the static ones have the Linux DT in our tree
> > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If
> > that's it then I can agree a special case for them, so long as we sort
> > out the docs for Xen.
>
> I'm agreeable to saying that if the dts files exist in Linux (or other
> official source locations) we should have those in-tree, and the board
> maintainer doesn't object, yes. But I think that might be a slightly
> different list than what you say here. And that punts the run-time
> decision down the road. And I'm assuming you're OK with also not
> including a dtb in the image.
>
> > > > I believe I have been consistent in this although with all the
> > > > discussion I'm really not sure anymore.
> > >
> > > Yes, everyone has been consistent in these discussions.
> >
> > I'd like to think more people accept that U-Boot is allowed its own
> > properties than did at the start.
> >
> > >
> > > > The problem is that various people have various views about how U-Boot
> > > > should work with devicetree. I strongly believe that until we have
> > > > bindings upstream, a central repo for DTs with easy downloading for
> > > > builds, automated validation, among other things, we must maintain the
> > > > devicetree in U-Boot. Just from the POV of energy expended, I do not
> > > > want to be arguing with the Linaro folks about what U-Boot is allowed
> > > > to do every month for the next two years. I'd rather set out the stall
> > > > now and then deal with the problems it causes from that perspective.
> > >
> > > The problems of the last going on 12 years won't be solved instantly.
> > > The conflict as I see it is that you're insisting that all platforms
> > > must have statically usable device trees, and I (and I believe others)
> > > are saying that's unreasonable in cases where the trees are dynamic at
> > > heart, lets just ensure we have good enough documentation for them,
> > > which we don't today.
> > >
> > > To be clear and pick an example, I don't want Pi dts files in U-Boot,
> > > but, OK, it's an easy enough case to sync them up and so long as we
> > > aren't yet at the "now we pick at run time between compiled in or passed
> > > to us dtb", I can accept them in tree, but not in the resulting binary
> > > for OF_CONTROL=y. But as the Xen folks have also noted, there's no
> > > reasonable tree to include there. It does need to be better documented
> > > how to fire it up however, in our sources.
> >
> > I'm OK with us copying in the Linux devicetree and using that. But
> > OF_BOARD must be a run-time option and able to be disabled. The
> > devicetree must be built, so it is actually real. We can have a
> > separate OF_OMIT or something like that to omit the devicetree from
> > the output image, perhaps.
>
> You're changing the meaning of CONFIG options. I like the idea Mark
> suggested (probably after you wrote this..) of introducing something new
> for what you're talking about. But no, it's unreasonable to say that
> every U-Boot binary will bundle one or more dtb and make a run time
> decision about what to use as the normal way the world works.
>
> > All of the other things need to wait until we make progress with
> > devicetree bindings, validation,
> >
> > How can we make progress on this? We have different goals, as I have
> > explained, so we are not going to agree on everything.
>
> Replace patches 4 to 14 with syncing platforms dts files from current
> Linux release, and when OF_BOARD=y don't include a device tree in the
> resulting image? That might also need adding some documentation for
> some platforms on where the device tree is and how to extract it.
How about we create a new option for that, as we discussed on IRC a
while back? After all, sandbox uses OF_BOARD. It doesn't mean
OF_PRIOR_STAGE, just that we call board_fdt_blob_setup().
So something like OF_OMIT_DTB? For U-Boot as a whole this is an uncommon case.
We also need to think about the protections again, perhaps we define
OF_HAS_PRIOR_STAGE to indicate that the board works this way, then
make it hard to disable OF_BOARD if that is set.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-04 22:09 ` Simon Glass
@ 2021-12-05 13:32 ` Tom Rini
2021-12-06 15:24 ` Simon Glass
0 siblings, 1 reply; 136+ messages in thread
From: Tom Rini @ 2021-12-05 13:32 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng, Jerry Van Baren,
Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen
[-- Attachment #1: Type: text/plain, Size: 12267 bytes --]
On Sat, Dec 04, 2021 at 03:09:59PM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Sat, 4 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> > > >
> > > > [huge snip]
> > > > > > There's things that need to be cleaned up because we have some small
> > > > > > number of platforms that went off and did their own thing. But largely
> > > > > > yes, things make sense to me. We have:
> > > > > > - We embedded the device tree that will configure U-Boot, because there
> > > > > > is no way for the hardware to have provided us one.
> > > > > > - We do not embed the device tree that will configure U-Boot, because
> > > > > > there is already one present in memory for us to use.
> > > > > >
> > > > > > Then we have the developer option of:
> > > > > > - We embedded the device tree that will configure U-Boot, because we're
> > > > > > developing something.
> > > > >
> > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice.
> > > >
> > > > But it's not possible. That's the problem we keep going around and
> > > > around about. People keep raising real life examples where you cannot
> > > > make a run time choice between "device tree we're passed at run time"
> > > > and "device tree we're compiled with".
> > >
> > > I haven't seen one. The most extreme case is QEMU and it works fine. I
> > > even added a test with it. What am I missing?
> >
> > QEMU and Xen should both never have an in-source-tree dts as they are
> > dynamic. I think you missed the explanation about how U-Boot + Xen
> > works? You're running the same U-Boot under Xen on any arbitrary ARMv8
> > (with required features...) system. For QEMU virtual machines you're
> > not supposed to do what you're doing, for production.
> >
> > > > And it's not helpful. It is ALWAYS the case that we know that we want
> > > > to override the run time device tree with our own, because it's a
> > > > developer developing things or it's a user / production case where we
> > > > must use the provided tree. NOT doing that is what leads to madness
> > > > like we see for example on Pi where if we don't use the passed tree we
> > > > still need to copy X/Y/Z out of it.
> > >
> > > Aren't you talking about the distro DT there, rather than the the one
> > > on the boot disk? That is my reading of that patch. If we need to do
> > > that sort of thing, it doesn't matter where the the cointrol DT comes
> > > from. You are still going to have to do that sort of thing.
> > >
> > > It is not ALWAYS the case. I've shown you how easy it is to disable
> > > OF_BOARD and still boot / iterate.
> >
> > The DT we're passed in is the DT to pass to the OS. That's the hook for
> > putting a DTB on the device as it ships, the OS will just work. The
> > production case of needing to update that stored DTB is handled. It's
> > always what should be used, again outside of developer doing
> > development.
> >
> > Maybe that's part of the confusion here too. The DTB U-Boot is using is
> > the DTB the OS will consume too, in the passed at run time case. Unless
> > we're instead going to save that DTB aside? Which leaves me with a
> > different set of design questions...
> >
> > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should
> > > > > > > provide a way to do that? But what is driving that desire?
> > > > > >
> > > > > > I'm looking for ways to convince you that we do not need to include a
> > > > > > device tree in the binary. There's a growing set of devices where the
> > > > > > device tree exists with the device. If it's missing, that's a huge
> > > > > > fatal error we can't do all that much about. If we need to do something
> > > > > > to that device tree for U-Boot, yes, fine, we should make it straight
> > > > > > forward for the developer to do that. But that's not the common case!
> > > > >
> > > > > Well we could add another Kconfig which tells U-Boot not to include a
> > > > > devicetree in u-boot.bin, if that would resolve this?
> > > > >
> > > > > I just want to make sure that we always build the devicetrees and that
> > > > > it is easy for a knowledgeable dev to switch over to use them, without
> > > > > spelunking through dozens of other projects to discover the secret DT
> > > > > that no one will tell us about.
> > > >
> > > > Should we demand better documentation for boards? Yes. But it's still
> > > > a valid case to have zero device trees for a given platform in-tree.
> > > > Xen is an example of this. QEMU is an example of this. Platforms need
> > > > to work without adding special tweaks for us. Maybe that means some
> > > > features can't be tested in QEMU-as-virtual-platform and only in
> > > > QEMU-faithfully-emulating-specific-physical-platforms.
> > >
> > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
> > > case, I think. How about we create a special Kconfig for that case? We
> > > need to make some progress here.
> >
> > Yes, because there's a small number of OF_BOARD=y configs in tree right
> > now, most of which are QEMU virtual machines, others of which are Pi
> > (which we've talked to death), highbank (which Andre has explained), and
> > then the octeontx stuff I don't know how works. I keep pushing to say
> > that OF_BOARD=y is the special case we need to not overrule the device
> > tree provided to us on. Unless we start saving off that passed-to-us DTB
> > and then something-something for our own run-time DTB, and letting the
> > OS consume that passed-to-us one with only normal fixups applied.
> >
> > > > > > I guess another part of the problem is that historically almost all
> > > > > > platforms were in the first case I list above, no run time provided
> > > > > > device tree, so we took the kernel one and added our bindings to it.
> > > > > > Now we're being bit by the growing number of platforms that are the
> > > > > > second case, and how do we get our properties in there, and which ones
> > > > > > even make sense to do that for.
> > > > >
> > > > > I think upstreaming the bindings is the solution there. I've made a
> > > > > start, but we need to make progress with this series and all the other
> > > > > things in flight. I think a lot of people want U-Boot to not have a
> > > > > devicetree source files in it for ARMv8 platforms. I am strongly
> > > > > opposed to that. I've laid out my reasons very clearly in the past. I
> > > > > think this is a good summary:
> > > > >
> > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
> > > >
> > > > Yes, there are some ARMv8 platforms we will have to have the source
> > > > files to, in tree, because they won't come to us at run time. But
> > > > others we won't for practical reasons, namely that we can't statically
> > > > provide something that exists dynamically without massive duplication of
> > > > code or just taking things from that passed to us tree.
> > >
> > > So let's require that the static ones have the Linux DT in our tree
> > > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If
> > > that's it then I can agree a special case for them, so long as we sort
> > > out the docs for Xen.
> >
> > I'm agreeable to saying that if the dts files exist in Linux (or other
> > official source locations) we should have those in-tree, and the board
> > maintainer doesn't object, yes. But I think that might be a slightly
> > different list than what you say here. And that punts the run-time
> > decision down the road. And I'm assuming you're OK with also not
> > including a dtb in the image.
> >
> > > > > I believe I have been consistent in this although with all the
> > > > > discussion I'm really not sure anymore.
> > > >
> > > > Yes, everyone has been consistent in these discussions.
> > >
> > > I'd like to think more people accept that U-Boot is allowed its own
> > > properties than did at the start.
> > >
> > > >
> > > > > The problem is that various people have various views about how U-Boot
> > > > > should work with devicetree. I strongly believe that until we have
> > > > > bindings upstream, a central repo for DTs with easy downloading for
> > > > > builds, automated validation, among other things, we must maintain the
> > > > > devicetree in U-Boot. Just from the POV of energy expended, I do not
> > > > > want to be arguing with the Linaro folks about what U-Boot is allowed
> > > > > to do every month for the next two years. I'd rather set out the stall
> > > > > now and then deal with the problems it causes from that perspective.
> > > >
> > > > The problems of the last going on 12 years won't be solved instantly.
> > > > The conflict as I see it is that you're insisting that all platforms
> > > > must have statically usable device trees, and I (and I believe others)
> > > > are saying that's unreasonable in cases where the trees are dynamic at
> > > > heart, lets just ensure we have good enough documentation for them,
> > > > which we don't today.
> > > >
> > > > To be clear and pick an example, I don't want Pi dts files in U-Boot,
> > > > but, OK, it's an easy enough case to sync them up and so long as we
> > > > aren't yet at the "now we pick at run time between compiled in or passed
> > > > to us dtb", I can accept them in tree, but not in the resulting binary
> > > > for OF_CONTROL=y. But as the Xen folks have also noted, there's no
> > > > reasonable tree to include there. It does need to be better documented
> > > > how to fire it up however, in our sources.
> > >
> > > I'm OK with us copying in the Linux devicetree and using that. But
> > > OF_BOARD must be a run-time option and able to be disabled. The
> > > devicetree must be built, so it is actually real. We can have a
> > > separate OF_OMIT or something like that to omit the devicetree from
> > > the output image, perhaps.
> >
> > You're changing the meaning of CONFIG options. I like the idea Mark
> > suggested (probably after you wrote this..) of introducing something new
> > for what you're talking about. But no, it's unreasonable to say that
> > every U-Boot binary will bundle one or more dtb and make a run time
> > decision about what to use as the normal way the world works.
> >
> > > All of the other things need to wait until we make progress with
> > > devicetree bindings, validation,
> > >
> > > How can we make progress on this? We have different goals, as I have
> > > explained, so we are not going to agree on everything.
> >
> > Replace patches 4 to 14 with syncing platforms dts files from current
> > Linux release, and when OF_BOARD=y don't include a device tree in the
> > resulting image? That might also need adding some documentation for
> > some platforms on where the device tree is and how to extract it.
>
> How about we create a new option for that, as we discussed on IRC a
> while back? After all, sandbox uses OF_BOARD. It doesn't mean
> OF_PRIOR_STAGE, just that we call board_fdt_blob_setup().
>
> So something like OF_OMIT_DTB? For U-Boot as a whole this is an uncommon case.
>
> We also need to think about the protections again, perhaps we define
> OF_HAS_PRIOR_STAGE to indicate that the board works this way, then
> make it hard to disable OF_BOARD if that is set.
I guess my hard sticking point here is I'm still entirely unconvinced
that the future step of "now we make run-time choice between built in or
provided dtb" makes sense. And I worry the way these CONFIG options
keep being presented is setting the ground work for this change that I'm
not agreed to conceptually.
So, yes, we could add more CONFIG symbols and then maybe even follow up
and migrate a few more platforms over to them. I'm unclear why we need
more symbols, but, OK, yes, to make progress, lets try it. Sometimes I
understand patches better than paragraphs.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-05 13:32 ` Tom Rini
@ 2021-12-06 15:24 ` Simon Glass
2021-12-06 15:43 ` Tom Rini
0 siblings, 1 reply; 136+ messages in thread
From: Simon Glass @ 2021-12-06 15:24 UTC (permalink / raw)
To: Tom Rini
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng, Jerry Van Baren,
Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen
Hi Tom,
On Sun, 5 Dec 2021 at 06:32, Tom Rini <trini@konsulko.com> wrote:
>
> On Sat, Dec 04, 2021 at 03:09:59PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sat, 4 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> > > > >
> > > > > [huge snip]
> > > > > > > There's things that need to be cleaned up because we have some small
> > > > > > > number of platforms that went off and did their own thing. But largely
> > > > > > > yes, things make sense to me. We have:
> > > > > > > - We embedded the device tree that will configure U-Boot, because there
> > > > > > > is no way for the hardware to have provided us one.
> > > > > > > - We do not embed the device tree that will configure U-Boot, because
> > > > > > > there is already one present in memory for us to use.
> > > > > > >
> > > > > > > Then we have the developer option of:
> > > > > > > - We embedded the device tree that will configure U-Boot, because we're
> > > > > > > developing something.
> > > > > >
> > > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice.
> > > > >
> > > > > But it's not possible. That's the problem we keep going around and
> > > > > around about. People keep raising real life examples where you cannot
> > > > > make a run time choice between "device tree we're passed at run time"
> > > > > and "device tree we're compiled with".
> > > >
> > > > I haven't seen one. The most extreme case is QEMU and it works fine. I
> > > > even added a test with it. What am I missing?
> > >
> > > QEMU and Xen should both never have an in-source-tree dts as they are
> > > dynamic. I think you missed the explanation about how U-Boot + Xen
> > > works? You're running the same U-Boot under Xen on any arbitrary ARMv8
> > > (with required features...) system. For QEMU virtual machines you're
> > > not supposed to do what you're doing, for production.
> > >
> > > > > And it's not helpful. It is ALWAYS the case that we know that we want
> > > > > to override the run time device tree with our own, because it's a
> > > > > developer developing things or it's a user / production case where we
> > > > > must use the provided tree. NOT doing that is what leads to madness
> > > > > like we see for example on Pi where if we don't use the passed tree we
> > > > > still need to copy X/Y/Z out of it.
> > > >
> > > > Aren't you talking about the distro DT there, rather than the the one
> > > > on the boot disk? That is my reading of that patch. If we need to do
> > > > that sort of thing, it doesn't matter where the the cointrol DT comes
> > > > from. You are still going to have to do that sort of thing.
> > > >
> > > > It is not ALWAYS the case. I've shown you how easy it is to disable
> > > > OF_BOARD and still boot / iterate.
> > >
> > > The DT we're passed in is the DT to pass to the OS. That's the hook for
> > > putting a DTB on the device as it ships, the OS will just work. The
> > > production case of needing to update that stored DTB is handled. It's
> > > always what should be used, again outside of developer doing
> > > development.
> > >
> > > Maybe that's part of the confusion here too. The DTB U-Boot is using is
> > > the DTB the OS will consume too, in the passed at run time case. Unless
> > > we're instead going to save that DTB aside? Which leaves me with a
> > > different set of design questions...
> > >
> > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should
> > > > > > > > provide a way to do that? But what is driving that desire?
> > > > > > >
> > > > > > > I'm looking for ways to convince you that we do not need to include a
> > > > > > > device tree in the binary. There's a growing set of devices where the
> > > > > > > device tree exists with the device. If it's missing, that's a huge
> > > > > > > fatal error we can't do all that much about. If we need to do something
> > > > > > > to that device tree for U-Boot, yes, fine, we should make it straight
> > > > > > > forward for the developer to do that. But that's not the common case!
> > > > > >
> > > > > > Well we could add another Kconfig which tells U-Boot not to include a
> > > > > > devicetree in u-boot.bin, if that would resolve this?
> > > > > >
> > > > > > I just want to make sure that we always build the devicetrees and that
> > > > > > it is easy for a knowledgeable dev to switch over to use them, without
> > > > > > spelunking through dozens of other projects to discover the secret DT
> > > > > > that no one will tell us about.
> > > > >
> > > > > Should we demand better documentation for boards? Yes. But it's still
> > > > > a valid case to have zero device trees for a given platform in-tree.
> > > > > Xen is an example of this. QEMU is an example of this. Platforms need
> > > > > to work without adding special tweaks for us. Maybe that means some
> > > > > features can't be tested in QEMU-as-virtual-platform and only in
> > > > > QEMU-faithfully-emulating-specific-physical-platforms.
> > > >
> > > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
> > > > case, I think. How about we create a special Kconfig for that case? We
> > > > need to make some progress here.
> > >
> > > Yes, because there's a small number of OF_BOARD=y configs in tree right
> > > now, most of which are QEMU virtual machines, others of which are Pi
> > > (which we've talked to death), highbank (which Andre has explained), and
> > > then the octeontx stuff I don't know how works. I keep pushing to say
> > > that OF_BOARD=y is the special case we need to not overrule the device
> > > tree provided to us on. Unless we start saving off that passed-to-us DTB
> > > and then something-something for our own run-time DTB, and letting the
> > > OS consume that passed-to-us one with only normal fixups applied.
> > >
> > > > > > > I guess another part of the problem is that historically almost all
> > > > > > > platforms were in the first case I list above, no run time provided
> > > > > > > device tree, so we took the kernel one and added our bindings to it.
> > > > > > > Now we're being bit by the growing number of platforms that are the
> > > > > > > second case, and how do we get our properties in there, and which ones
> > > > > > > even make sense to do that for.
> > > > > >
> > > > > > I think upstreaming the bindings is the solution there. I've made a
> > > > > > start, but we need to make progress with this series and all the other
> > > > > > things in flight. I think a lot of people want U-Boot to not have a
> > > > > > devicetree source files in it for ARMv8 platforms. I am strongly
> > > > > > opposed to that. I've laid out my reasons very clearly in the past. I
> > > > > > think this is a good summary:
> > > > > >
> > > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
> > > > >
> > > > > Yes, there are some ARMv8 platforms we will have to have the source
> > > > > files to, in tree, because they won't come to us at run time. But
> > > > > others we won't for practical reasons, namely that we can't statically
> > > > > provide something that exists dynamically without massive duplication of
> > > > > code or just taking things from that passed to us tree.
> > > >
> > > > So let's require that the static ones have the Linux DT in our tree
> > > > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If
> > > > that's it then I can agree a special case for them, so long as we sort
> > > > out the docs for Xen.
> > >
> > > I'm agreeable to saying that if the dts files exist in Linux (or other
> > > official source locations) we should have those in-tree, and the board
> > > maintainer doesn't object, yes. But I think that might be a slightly
> > > different list than what you say here. And that punts the run-time
> > > decision down the road. And I'm assuming you're OK with also not
> > > including a dtb in the image.
> > >
> > > > > > I believe I have been consistent in this although with all the
> > > > > > discussion I'm really not sure anymore.
> > > > >
> > > > > Yes, everyone has been consistent in these discussions.
> > > >
> > > > I'd like to think more people accept that U-Boot is allowed its own
> > > > properties than did at the start.
> > > >
> > > > >
> > > > > > The problem is that various people have various views about how U-Boot
> > > > > > should work with devicetree. I strongly believe that until we have
> > > > > > bindings upstream, a central repo for DTs with easy downloading for
> > > > > > builds, automated validation, among other things, we must maintain the
> > > > > > devicetree in U-Boot. Just from the POV of energy expended, I do not
> > > > > > want to be arguing with the Linaro folks about what U-Boot is allowed
> > > > > > to do every month for the next two years. I'd rather set out the stall
> > > > > > now and then deal with the problems it causes from that perspective.
> > > > >
> > > > > The problems of the last going on 12 years won't be solved instantly.
> > > > > The conflict as I see it is that you're insisting that all platforms
> > > > > must have statically usable device trees, and I (and I believe others)
> > > > > are saying that's unreasonable in cases where the trees are dynamic at
> > > > > heart, lets just ensure we have good enough documentation for them,
> > > > > which we don't today.
> > > > >
> > > > > To be clear and pick an example, I don't want Pi dts files in U-Boot,
> > > > > but, OK, it's an easy enough case to sync them up and so long as we
> > > > > aren't yet at the "now we pick at run time between compiled in or passed
> > > > > to us dtb", I can accept them in tree, but not in the resulting binary
> > > > > for OF_CONTROL=y. But as the Xen folks have also noted, there's no
> > > > > reasonable tree to include there. It does need to be better documented
> > > > > how to fire it up however, in our sources.
> > > >
> > > > I'm OK with us copying in the Linux devicetree and using that. But
> > > > OF_BOARD must be a run-time option and able to be disabled. The
> > > > devicetree must be built, so it is actually real. We can have a
> > > > separate OF_OMIT or something like that to omit the devicetree from
> > > > the output image, perhaps.
> > >
> > > You're changing the meaning of CONFIG options. I like the idea Mark
> > > suggested (probably after you wrote this..) of introducing something new
> > > for what you're talking about. But no, it's unreasonable to say that
> > > every U-Boot binary will bundle one or more dtb and make a run time
> > > decision about what to use as the normal way the world works.
> > >
> > > > All of the other things need to wait until we make progress with
> > > > devicetree bindings, validation,
> > > >
> > > > How can we make progress on this? We have different goals, as I have
> > > > explained, so we are not going to agree on everything.
> > >
> > > Replace patches 4 to 14 with syncing platforms dts files from current
> > > Linux release, and when OF_BOARD=y don't include a device tree in the
> > > resulting image? That might also need adding some documentation for
> > > some platforms on where the device tree is and how to extract it.
> >
> > How about we create a new option for that, as we discussed on IRC a
> > while back? After all, sandbox uses OF_BOARD. It doesn't mean
> > OF_PRIOR_STAGE, just that we call board_fdt_blob_setup().
> >
> > So something like OF_OMIT_DTB? For U-Boot as a whole this is an uncommon case.
> >
> > We also need to think about the protections again, perhaps we define
> > OF_HAS_PRIOR_STAGE to indicate that the board works this way, then
> > make it hard to disable OF_BOARD if that is set.
>
> I guess my hard sticking point here is I'm still entirely unconvinced
> that the future step of "now we make run-time choice between built in or
> provided dtb" makes sense. And I worry the way these CONFIG options
> keep being presented is setting the ground work for this change that I'm
> not agreed to conceptually.
>
> So, yes, we could add more CONFIG symbols and then maybe even follow up
> and migrate a few more platforms over to them. I'm unclear why we need
> more symbols, but, OK, yes, to make progress, lets try it. Sometimes I
> understand patches better than paragraphs.
OK I am trying it. I will send v7 soon.
I am going to add the warnings we talked about in v7. I think the
whole 'confusion' thing is overblown, but hopefully that will help get
things moving too.
Note that the difference between 'built-in' and 'provided' is just the
run-time difference. The build puts the DT in the firmware image
anyway, otherwise of course the board cannot boot. The image includes
U-Boot and anything else that is needed. E.g. in the case of TF-A
doing this, the build includes TF-A, U-Boot and devicetree. TF-A reads
the devicetree, fiddles with it and passes it to U-Boot. So the
firmware includes a built-in devicetree, one way or another. The
question is what happens at runtime. This is related to my 'Binman'
point.
Regards,
Simon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
2021-12-06 15:24 ` Simon Glass
@ 2021-12-06 15:43 ` Tom Rini
0 siblings, 0 replies; 136+ messages in thread
From: Tom Rini @ 2021-12-06 15:43 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson,
Ilias Apalodimas, François Ozog, Heinrich Schuchardt,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng, Jerry Van Baren,
Linus Walleij, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Peter Maydell, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen
[-- Attachment #1: Type: text/plain, Size: 14197 bytes --]
On Mon, Dec 06, 2021 at 08:24:56AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Sun, 5 Dec 2021 at 06:32, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sat, Dec 04, 2021 at 03:09:59PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sat, 4 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> > > > > >
> > > > > > [huge snip]
> > > > > > > > There's things that need to be cleaned up because we have some small
> > > > > > > > number of platforms that went off and did their own thing. But largely
> > > > > > > > yes, things make sense to me. We have:
> > > > > > > > - We embedded the device tree that will configure U-Boot, because there
> > > > > > > > is no way for the hardware to have provided us one.
> > > > > > > > - We do not embed the device tree that will configure U-Boot, because
> > > > > > > > there is already one present in memory for us to use.
> > > > > > > >
> > > > > > > > Then we have the developer option of:
> > > > > > > > - We embedded the device tree that will configure U-Boot, because we're
> > > > > > > > developing something.
> > > > > > >
> > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice.
> > > > > >
> > > > > > But it's not possible. That's the problem we keep going around and
> > > > > > around about. People keep raising real life examples where you cannot
> > > > > > make a run time choice between "device tree we're passed at run time"
> > > > > > and "device tree we're compiled with".
> > > > >
> > > > > I haven't seen one. The most extreme case is QEMU and it works fine. I
> > > > > even added a test with it. What am I missing?
> > > >
> > > > QEMU and Xen should both never have an in-source-tree dts as they are
> > > > dynamic. I think you missed the explanation about how U-Boot + Xen
> > > > works? You're running the same U-Boot under Xen on any arbitrary ARMv8
> > > > (with required features...) system. For QEMU virtual machines you're
> > > > not supposed to do what you're doing, for production.
> > > >
> > > > > > And it's not helpful. It is ALWAYS the case that we know that we want
> > > > > > to override the run time device tree with our own, because it's a
> > > > > > developer developing things or it's a user / production case where we
> > > > > > must use the provided tree. NOT doing that is what leads to madness
> > > > > > like we see for example on Pi where if we don't use the passed tree we
> > > > > > still need to copy X/Y/Z out of it.
> > > > >
> > > > > Aren't you talking about the distro DT there, rather than the the one
> > > > > on the boot disk? That is my reading of that patch. If we need to do
> > > > > that sort of thing, it doesn't matter where the the cointrol DT comes
> > > > > from. You are still going to have to do that sort of thing.
> > > > >
> > > > > It is not ALWAYS the case. I've shown you how easy it is to disable
> > > > > OF_BOARD and still boot / iterate.
> > > >
> > > > The DT we're passed in is the DT to pass to the OS. That's the hook for
> > > > putting a DTB on the device as it ships, the OS will just work. The
> > > > production case of needing to update that stored DTB is handled. It's
> > > > always what should be used, again outside of developer doing
> > > > development.
> > > >
> > > > Maybe that's part of the confusion here too. The DTB U-Boot is using is
> > > > the DTB the OS will consume too, in the passed at run time case. Unless
> > > > we're instead going to save that DTB aside? Which leaves me with a
> > > > different set of design questions...
> > > >
> > > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should
> > > > > > > > > provide a way to do that? But what is driving that desire?
> > > > > > > >
> > > > > > > > I'm looking for ways to convince you that we do not need to include a
> > > > > > > > device tree in the binary. There's a growing set of devices where the
> > > > > > > > device tree exists with the device. If it's missing, that's a huge
> > > > > > > > fatal error we can't do all that much about. If we need to do something
> > > > > > > > to that device tree for U-Boot, yes, fine, we should make it straight
> > > > > > > > forward for the developer to do that. But that's not the common case!
> > > > > > >
> > > > > > > Well we could add another Kconfig which tells U-Boot not to include a
> > > > > > > devicetree in u-boot.bin, if that would resolve this?
> > > > > > >
> > > > > > > I just want to make sure that we always build the devicetrees and that
> > > > > > > it is easy for a knowledgeable dev to switch over to use them, without
> > > > > > > spelunking through dozens of other projects to discover the secret DT
> > > > > > > that no one will tell us about.
> > > > > >
> > > > > > Should we demand better documentation for boards? Yes. But it's still
> > > > > > a valid case to have zero device trees for a given platform in-tree.
> > > > > > Xen is an example of this. QEMU is an example of this. Platforms need
> > > > > > to work without adding special tweaks for us. Maybe that means some
> > > > > > features can't be tested in QEMU-as-virtual-platform and only in
> > > > > > QEMU-faithfully-emulating-specific-physical-platforms.
> > > > >
> > > > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
> > > > > case, I think. How about we create a special Kconfig for that case? We
> > > > > need to make some progress here.
> > > >
> > > > Yes, because there's a small number of OF_BOARD=y configs in tree right
> > > > now, most of which are QEMU virtual machines, others of which are Pi
> > > > (which we've talked to death), highbank (which Andre has explained), and
> > > > then the octeontx stuff I don't know how works. I keep pushing to say
> > > > that OF_BOARD=y is the special case we need to not overrule the device
> > > > tree provided to us on. Unless we start saving off that passed-to-us DTB
> > > > and then something-something for our own run-time DTB, and letting the
> > > > OS consume that passed-to-us one with only normal fixups applied.
> > > >
> > > > > > > > I guess another part of the problem is that historically almost all
> > > > > > > > platforms were in the first case I list above, no run time provided
> > > > > > > > device tree, so we took the kernel one and added our bindings to it.
> > > > > > > > Now we're being bit by the growing number of platforms that are the
> > > > > > > > second case, and how do we get our properties in there, and which ones
> > > > > > > > even make sense to do that for.
> > > > > > >
> > > > > > > I think upstreaming the bindings is the solution there. I've made a
> > > > > > > start, but we need to make progress with this series and all the other
> > > > > > > things in flight. I think a lot of people want U-Boot to not have a
> > > > > > > devicetree source files in it for ARMv8 platforms. I am strongly
> > > > > > > opposed to that. I've laid out my reasons very clearly in the past. I
> > > > > > > think this is a good summary:
> > > > > > >
> > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html
> > > > > >
> > > > > > Yes, there are some ARMv8 platforms we will have to have the source
> > > > > > files to, in tree, because they won't come to us at run time. But
> > > > > > others we won't for practical reasons, namely that we can't statically
> > > > > > provide something that exists dynamically without massive duplication of
> > > > > > code or just taking things from that passed to us tree.
> > > > >
> > > > > So let's require that the static ones have the Linux DT in our tree
> > > > > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If
> > > > > that's it then I can agree a special case for them, so long as we sort
> > > > > out the docs for Xen.
> > > >
> > > > I'm agreeable to saying that if the dts files exist in Linux (or other
> > > > official source locations) we should have those in-tree, and the board
> > > > maintainer doesn't object, yes. But I think that might be a slightly
> > > > different list than what you say here. And that punts the run-time
> > > > decision down the road. And I'm assuming you're OK with also not
> > > > including a dtb in the image.
> > > >
> > > > > > > I believe I have been consistent in this although with all the
> > > > > > > discussion I'm really not sure anymore.
> > > > > >
> > > > > > Yes, everyone has been consistent in these discussions.
> > > > >
> > > > > I'd like to think more people accept that U-Boot is allowed its own
> > > > > properties than did at the start.
> > > > >
> > > > > >
> > > > > > > The problem is that various people have various views about how U-Boot
> > > > > > > should work with devicetree. I strongly believe that until we have
> > > > > > > bindings upstream, a central repo for DTs with easy downloading for
> > > > > > > builds, automated validation, among other things, we must maintain the
> > > > > > > devicetree in U-Boot. Just from the POV of energy expended, I do not
> > > > > > > want to be arguing with the Linaro folks about what U-Boot is allowed
> > > > > > > to do every month for the next two years. I'd rather set out the stall
> > > > > > > now and then deal with the problems it causes from that perspective.
> > > > > >
> > > > > > The problems of the last going on 12 years won't be solved instantly.
> > > > > > The conflict as I see it is that you're insisting that all platforms
> > > > > > must have statically usable device trees, and I (and I believe others)
> > > > > > are saying that's unreasonable in cases where the trees are dynamic at
> > > > > > heart, lets just ensure we have good enough documentation for them,
> > > > > > which we don't today.
> > > > > >
> > > > > > To be clear and pick an example, I don't want Pi dts files in U-Boot,
> > > > > > but, OK, it's an easy enough case to sync them up and so long as we
> > > > > > aren't yet at the "now we pick at run time between compiled in or passed
> > > > > > to us dtb", I can accept them in tree, but not in the resulting binary
> > > > > > for OF_CONTROL=y. But as the Xen folks have also noted, there's no
> > > > > > reasonable tree to include there. It does need to be better documented
> > > > > > how to fire it up however, in our sources.
> > > > >
> > > > > I'm OK with us copying in the Linux devicetree and using that. But
> > > > > OF_BOARD must be a run-time option and able to be disabled. The
> > > > > devicetree must be built, so it is actually real. We can have a
> > > > > separate OF_OMIT or something like that to omit the devicetree from
> > > > > the output image, perhaps.
> > > >
> > > > You're changing the meaning of CONFIG options. I like the idea Mark
> > > > suggested (probably after you wrote this..) of introducing something new
> > > > for what you're talking about. But no, it's unreasonable to say that
> > > > every U-Boot binary will bundle one or more dtb and make a run time
> > > > decision about what to use as the normal way the world works.
> > > >
> > > > > All of the other things need to wait until we make progress with
> > > > > devicetree bindings, validation,
> > > > >
> > > > > How can we make progress on this? We have different goals, as I have
> > > > > explained, so we are not going to agree on everything.
> > > >
> > > > Replace patches 4 to 14 with syncing platforms dts files from current
> > > > Linux release, and when OF_BOARD=y don't include a device tree in the
> > > > resulting image? That might also need adding some documentation for
> > > > some platforms on where the device tree is and how to extract it.
> > >
> > > How about we create a new option for that, as we discussed on IRC a
> > > while back? After all, sandbox uses OF_BOARD. It doesn't mean
> > > OF_PRIOR_STAGE, just that we call board_fdt_blob_setup().
> > >
> > > So something like OF_OMIT_DTB? For U-Boot as a whole this is an uncommon case.
> > >
> > > We also need to think about the protections again, perhaps we define
> > > OF_HAS_PRIOR_STAGE to indicate that the board works this way, then
> > > make it hard to disable OF_BOARD if that is set.
> >
> > I guess my hard sticking point here is I'm still entirely unconvinced
> > that the future step of "now we make run-time choice between built in or
> > provided dtb" makes sense. And I worry the way these CONFIG options
> > keep being presented is setting the ground work for this change that I'm
> > not agreed to conceptually.
> >
> > So, yes, we could add more CONFIG symbols and then maybe even follow up
> > and migrate a few more platforms over to them. I'm unclear why we need
> > more symbols, but, OK, yes, to make progress, lets try it. Sometimes I
> > understand patches better than paragraphs.
>
> OK I am trying it. I will send v7 soon.
>
> I am going to add the warnings we talked about in v7. I think the
> whole 'confusion' thing is overblown, but hopefully that will help get
> things moving too.
>
> Note that the difference between 'built-in' and 'provided' is just the
> run-time difference. The build puts the DT in the firmware image
> anyway, otherwise of course the board cannot boot. The image includes
> U-Boot and anything else that is needed. E.g. in the case of TF-A
> doing this, the build includes TF-A, U-Boot and devicetree. TF-A reads
> the devicetree, fiddles with it and passes it to U-Boot. So the
> firmware includes a built-in devicetree, one way or another. The
> question is what happens at runtime. This is related to my 'Binman'
> point.
Thanks. I have questions, but I'll save them for after I've poked at
v7. Please note the git branch in the cover letter too.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread
[parent not found: <20211202155919.2429190-25-sjg@chromium.org>]
* Re: [PATCH v6 24/25] fdt: Drop remaining preprocessor macros in fdtdec_setup()
[not found] ` <20211202155919.2429190-25-sjg@chromium.org>
@ 2021-12-06 18:45 ` Ilias Apalodimas
0 siblings, 0 replies; 136+ messages in thread
From: Ilias Apalodimas @ 2021-12-06 18:45 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Sean Anderson, Tom Rini,
François Ozog, Heinrich Schuchardt, Jerry Van Baren
Hi Simon,
On Thu, 2 Dec 2021 at 18:00, Simon Glass <sjg@chromium.org> wrote:
>
> We only have two choices for obtaining the devicetree. Simplify the code
> to make that clear.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> (no changes since v1)
>
> lib/fdtdec.c | 20 +++++++++++---------
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index 5b31064cee2..a7f62123a94 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -1624,15 +1624,17 @@ static void setup_multi_dtb_fit(void)
> int fdtdec_setup(void)
> {
> int ret;
> -#ifdef CONFIG_OF_EMBED
> - /* Get a pointer to the FDT */
> - gd->fdt_blob = dtb_dt_embedded();
> -#elif defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE)
> - /* Allow the board to override the fdt address. */
> - gd->fdt_blob = board_fdt_blob_setup(&ret);
> - if (ret)
> - return ret;
> -#endif
> +
> + /* The devicetree is typically appended to U-Boot */
> + if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD)) {
> + /* Allow the board to override the fdt address. */
> + gd->fdt_blob = board_fdt_blob_setup(&ret);
> + if (ret)
> + return ret;
> + } else { /* embed dtb in ELF file for testing / development */
> + gd->fdt_blob = dtb_dt_embedded();
> + }
> +
> if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
> /* Allow the early environment to override the fdt address */
> gd->fdt_blob = map_sysmem(env_get_ulong("fdtcontroladdr", 16,
> --
> 2.34.0.rc2.393.gf8c9666880-goog
>
In case you need to resend this can you change the commit message a bit?
This doesn't really simplify the logic, just replaces ifdefs with IS_ENABLED
Other than that
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
^ permalink raw reply [flat|nested] 136+ messages in thread