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...

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 v7: - Fix 'linst' typo

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..e3b65f6fa66 --- /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 list, 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-deym... +.. _`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

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:

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

This uses QEMU virt which creates its own devicetree.

Add an empty version of this file, so that we can at least build this board when devicetrees are required.

Tested-by: Heinrich Schuchardt heinrich.schuchardt@canaonical.com Signed-off-by: Simon Glass sjg@chromium.org ---

Changes in v7: - Switch to using an empty file for qemu virt

Changes in v6: - Expand the commit message based on comments

arch/arm/dts/Makefile | 2 +- arch/arm/dts/qemu-arm64.dts | 11 +++++++++++ configs/qemu_arm64_defconfig | 1 + 3 files changed, 13 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..096b3910728 --- /dev/null +++ b/arch/arm/dts/qemu-arm64.dts @@ -0,0 +1,11 @@ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +/* + * Empty device tree for qemu_arm64 + + * Copyright 2021 Google LLC + */ + +/dts-v1/; + +/ { +}; 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

Sync these files, obtained from Linux v5.15.

This adds a devicetree file for rpi_4 which was not there before.

Testing shows no change so far as I can see: - boots to U-Boot prompt on rpi0, rpi2 - boots to distro on rpi3 - boots to distro on rpi4

I am assuming that syncing with Linux is safe, but the maintainer should know for sure.

Signed-off-by: Simon Glass sjg@chromium.org ---

Changes in v7: - Bring in files from Linux instead

arch/arm/dts/Makefile | 3 +- arch/arm/dts/bcm2711-rpi-4-b.dts | 262 +++++ arch/arm/dts/bcm2711-rpi.dtsi | 74 ++ arch/arm/dts/bcm2711.dtsi | 1100 ++++++++++++++++++ arch/arm/dts/bcm2835-common.dtsi | 207 ++++ arch/arm/dts/bcm2835-rpi-a-plus.dts | 18 +- arch/arm/dts/bcm2835-rpi-a.dts | 16 +- arch/arm/dts/bcm2835-rpi-b-plus.dts | 18 +- arch/arm/dts/bcm2835-rpi-b-rev2.dts | 16 +- arch/arm/dts/bcm2835-rpi-b.dts | 16 +- arch/arm/dts/bcm2835-rpi-cm1-io1.dts | 9 + arch/arm/dts/bcm2835-rpi-cm1.dtsi | 7 +- arch/arm/dts/bcm2835-rpi-common.dtsi | 12 + arch/arm/dts/bcm2835-rpi-zero-w.dts | 20 +- arch/arm/dts/bcm2835-rpi-zero.dts | 16 +- arch/arm/dts/bcm2835-rpi.dtsi | 35 +- arch/arm/dts/bcm2835.dtsi | 2 + arch/arm/dts/bcm2836-rpi-2-b.dts | 14 +- arch/arm/dts/bcm2836.dtsi | 2 + arch/arm/dts/bcm2837-rpi-3-a-plus.dts | 9 +- arch/arm/dts/bcm2837-rpi-3-b-plus.dts | 9 +- arch/arm/dts/bcm2837-rpi-3-b.dts | 5 +- arch/arm/dts/bcm2837-rpi-cm3-io3.dts | 9 + arch/arm/dts/bcm2837-rpi-cm3.dtsi | 9 + arch/arm/dts/bcm2837.dtsi | 2 + arch/arm/dts/bcm283x-rpi-usb-peripheral.dtsi | 7 + arch/arm/dts/bcm283x.dtsi | 224 +--- configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + include/dt-bindings/clock/bcm2835.h | 2 + 31 files changed, 1878 insertions(+), 248 deletions(-) create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts create mode 100644 arch/arm/dts/bcm2711-rpi.dtsi create mode 100644 arch/arm/dts/bcm2711.dtsi create mode 100644 arch/arm/dts/bcm2835-common.dtsi create mode 100644 arch/arm/dts/bcm2835-rpi-common.dtsi create mode 100644 arch/arm/dts/bcm283x-rpi-usb-peripheral.dtsi

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..72ce80fbf26 --- /dev/null +++ b/arch/arm/dts/bcm2711-rpi-4-b.dts @@ -0,0 +1,262 @@ +// SPDX-License-Identifier: GPL-2.0 +/dts-v1/; +#include "bcm2711.dtsi" +#include "bcm2711-rpi.dtsi" +#include "bcm283x-rpi-usb-peripheral.dtsi" + +/ { + compatible = "raspberrypi,4-model-b", "brcm,bcm2711"; + model = "Raspberry Pi 4 Model B"; + + chosen { + /* 8250 auxiliary UART instead of pl011 */ + stdout-path = "serial1:115200n8"; + }; + + leds { + led-act { + gpios = <&gpio 42 GPIO_ACTIVE_HIGH>; + }; + + led-pwr { + label = "PWR"; + gpios = <&expgpio 2 GPIO_ACTIVE_LOW>; + default-state = "keep"; + linux,default-trigger = "default-on"; + }; + }; + + wifi_pwrseq: wifi-pwrseq { + compatible = "mmc-pwrseq-simple"; + reset-gpios = <&expgpio 1 GPIO_ACTIVE_LOW>; + }; + + sd_io_1v8_reg: sd_io_1v8_reg { + compatible = "regulator-gpio"; + regulator-name = "vdd-sd-io"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + regulator-settling-time-us = <5000>; + gpios = <&expgpio 4 GPIO_ACTIVE_HIGH>; + states = <1800000 0x1>, + <3300000 0x0>; + status = "okay"; + }; + + sd_vcc_reg: sd_vcc_reg { + compatible = "regulator-fixed"; + regulator-name = "vcc-sd"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + enable-active-high; + gpio = <&expgpio 6 GPIO_ACTIVE_HIGH>; + }; +}; + +&ddc0 { + status = "okay"; +}; + +&ddc1 { + status = "okay"; +}; + +&expgpio { + gpio-line-names = "BT_ON", + "WL_ON", + "PWR_LED_OFF", + "GLOBAL_RESET", + "VDD_SD_IO_SEL", + "CAM_GPIO", + "SD_PWR_ON", + ""; +}; + +&gpio { + /* + * Parts taken from rpi_SCH_4b_4p0_reduced.pdf and + * the official GPU firmware DT blob. + * + * Legend: + * "FOO" = GPIO line named "FOO" on the schematic + * "FOO_N" = GPIO line named "FOO" on schematic, active low + */ + gpio-line-names = "ID_SDA", + "ID_SCL", + "SDA1", + "SCL1", + "GPIO_GCLK", + "GPIO5", + "GPIO6", + "SPI_CE1_N", + "SPI_CE0_N", + "SPI_MISO", + "SPI_MOSI", + "SPI_SCLK", + "GPIO12", + "GPIO13", + /* Serial port */ + "TXD1", + "RXD1", + "GPIO16", + "GPIO17", + "GPIO18", + "GPIO19", + "GPIO20", + "GPIO21", + "GPIO22", + "GPIO23", + "GPIO24", + "GPIO25", + "GPIO26", + "GPIO27", + "RGMII_MDIO", + "RGMIO_MDC", + /* Used by BT module */ + "CTS0", + "RTS0", + "TXD0", + "RXD0", + /* Used by Wifi */ + "SD1_CLK", + "SD1_CMD", + "SD1_DATA0", + "SD1_DATA1", + "SD1_DATA2", + "SD1_DATA3", + /* Shared with SPI flash */ + "PWM0_MISO", + "PWM1_MOSI", + "STATUS_LED_G_CLK", + "SPIFLASH_CE_N", + "SDA0", + "SCL0", + "RGMII_RXCLK", + "RGMII_RXCTL", + "RGMII_RXD0", + "RGMII_RXD1", + "RGMII_RXD2", + "RGMII_RXD3", + "RGMII_TXCLK", + "RGMII_TXCTL", + "RGMII_TXD0", + "RGMII_TXD1", + "RGMII_TXD2", + "RGMII_TXD3"; +}; + +&hdmi0 { + status = "okay"; +}; + +&hdmi1 { + status = "okay"; +}; + +&pixelvalve0 { + status = "okay"; +}; + +&pixelvalve1 { + status = "okay"; +}; + +&pixelvalve2 { + status = "okay"; +}; + +&pixelvalve4 { + status = "okay"; +}; + +&pwm1 { + pinctrl-names = "default"; + pinctrl-0 = <&pwm1_0_gpio40 &pwm1_1_gpio41>; + status = "okay"; +}; + +/* SDHCI is used to control the SDIO for wireless */ +&sdhci { + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&emmc_gpio34>; + bus-width = <4>; + non-removable; + mmc-pwrseq = <&wifi_pwrseq>; + status = "okay"; + + brcmf: wifi@1 { + reg = <1>; + compatible = "brcm,bcm4329-fmac"; + }; +}; + +/* EMMC2 is used to drive the SD card */ +&emmc2 { + vqmmc-supply = <&sd_io_1v8_reg>; + vmmc-supply = <&sd_vcc_reg>; + broken-cd; + status = "okay"; +}; + +&genet { + phy-handle = <&phy1>; + phy-mode = "rgmii-rxid"; + status = "okay"; +}; + +&genet_mdio { + phy1: ethernet-phy@1 { + /* No PHY interrupt */ + reg = <0x1>; + }; +}; + +&pcie0 { + pci@0,0 { + device_type = "pci"; + #address-cells = <3>; + #size-cells = <2>; + ranges; + + reg = <0 0 0 0 0>; + + usb@0,0 { + reg = <0 0 0 0 0>; + resets = <&reset RASPBERRYPI_FIRMWARE_RESET_ID_USB>; + }; + }; +}; + +/* uart0 communicates with the BT module */ +&uart0 { + pinctrl-names = "default"; + pinctrl-0 = <&uart0_ctsrts_gpio30 &uart0_gpio32>; + uart-has-rtscts; + status = "okay"; + + bluetooth { + compatible = "brcm,bcm43438-bt"; + max-speed = <2000000>; + shutdown-gpios = <&expgpio 0 GPIO_ACTIVE_HIGH>; + }; +}; + +/* uart1 is mapped to the pin header */ +&uart1 { + pinctrl-names = "default"; + pinctrl-0 = <&uart1_gpio14>; + status = "okay"; +}; + +&vc4 { + status = "okay"; +}; + +&vec { + status = "disabled"; +}; diff --git a/arch/arm/dts/bcm2711-rpi.dtsi b/arch/arm/dts/bcm2711-rpi.dtsi new file mode 100644 index 00000000000..ca266c5d9f9 --- /dev/null +++ b/arch/arm/dts/bcm2711-rpi.dtsi @@ -0,0 +1,74 @@ +// SPDX-License-Identifier: GPL-2.0 +#include "bcm2835-rpi.dtsi" + +#include <dt-bindings/reset/raspberrypi,firmware-reset.h> + +/ { + /* Will be filled by the bootloader */ + memory@0 { + device_type = "memory"; + reg = <0 0 0>; + }; + + aliases { + emmc2bus = &emmc2bus; + ethernet0 = &genet; + pcie0 = &pcie0; + blconfig = &blconfig; + }; +}; + +&firmware { + firmware_clocks: clocks { + compatible = "raspberrypi,firmware-clocks"; + #clock-cells = <1>; + }; + + expgpio: gpio { + compatible = "raspberrypi,firmware-gpio"; + gpio-controller; + #gpio-cells = <2>; + status = "okay"; + }; + + reset: reset { + compatible = "raspberrypi,firmware-reset"; + #reset-cells = <1>; + }; +}; + +&hdmi0 { + clocks = <&firmware_clocks 13>, <&firmware_clocks 14>, <&dvp 0>, <&clk_27MHz>; + clock-names = "hdmi", "bvb", "audio", "cec"; + wifi-2.4ghz-coexistence; +}; + +&hdmi1 { + clocks = <&firmware_clocks 13>, <&firmware_clocks 14>, <&dvp 1>, <&clk_27MHz>; + clock-names = "hdmi", "bvb", "audio", "cec"; + wifi-2.4ghz-coexistence; +}; + +&hvs { + clocks = <&firmware_clocks 4>; +}; + +&rmem { + /* + * RPi4's co-processor will copy the board's bootloader configuration + * into memory for the OS to consume. It'll also update this node with + * its placement information. + */ + blconfig: nvram@0 { + compatible = "raspberrypi,bootloader-config", "nvmem-rmem"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x0 0x0 0x0>; + no-map; + status = "disabled"; + }; +}; + +&vchiq { + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>; +}; diff --git a/arch/arm/dts/bcm2711.dtsi b/arch/arm/dts/bcm2711.dtsi new file mode 100644 index 00000000000..3b60297af7f --- /dev/null +++ b/arch/arm/dts/bcm2711.dtsi @@ -0,0 +1,1100 @@ +// SPDX-License-Identifier: GPL-2.0 +#include "bcm283x.dtsi" + +#include <dt-bindings/interrupt-controller/arm-gic.h> +#include <dt-bindings/soc/bcm2835-pm.h> + +/ { + compatible = "brcm,bcm2711"; + + #address-cells = <2>; + #size-cells = <1>; + + interrupt-parent = <&gicv2>; + + vc4: gpu { + compatible = "brcm,bcm2711-vc5"; + status = "disabled"; + }; + + clk_27MHz: clk-27M { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <27000000>; + clock-output-names = "27MHz-clock"; + }; + + clk_108MHz: clk-108M { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <108000000>; + clock-output-names = "108MHz-clock"; + }; + + soc { + /* + * Defined ranges: + * Common BCM283x peripherals + * BCM2711-specific peripherals + * ARM-local peripherals + */ + ranges = <0x7e000000 0x0 0xfe000000 0x01800000>, + <0x7c000000 0x0 0xfc000000 0x02000000>, + <0x40000000 0x0 0xff800000 0x00800000>; + /* Emulate a contiguous 30-bit address range for DMA */ + dma-ranges = <0xc0000000 0x0 0x00000000 0x40000000>; + + /* + * This node is the provider for the enable-method for + * bringing up secondary cores. + */ + local_intc: local_intc@40000000 { + compatible = "brcm,bcm2836-l1-intc"; + reg = <0x40000000 0x100>; + }; + + gicv2: interrupt-controller@40041000 { + interrupt-controller; + #interrupt-cells = <3>; + compatible = "arm,gic-400"; + reg = <0x40041000 0x1000>, + <0x40042000 0x2000>, + <0x40044000 0x2000>, + <0x40046000 0x2000>; + interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | + IRQ_TYPE_LEVEL_HIGH)>; + }; + + avs_monitor: avs-monitor@7d5d2000 { + compatible = "brcm,bcm2711-avs-monitor", + "syscon", "simple-mfd"; + reg = <0x7d5d2000 0xf00>; + + thermal: thermal { + compatible = "brcm,bcm2711-thermal"; + #thermal-sensor-cells = <0>; + }; + }; + + dma: dma@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xb00>; + interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>, + /* DMA lite 7 - 10 */ + <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "dma0", + "dma1", + "dma2", + "dma3", + "dma4", + "dma5", + "dma6", + "dma7", + "dma8", + "dma9", + "dma10"; + #dma-cells = <1>; + brcm,dma-channel-mask = <0x07f5>; + }; + + pm: watchdog@7e100000 { + compatible = "brcm,bcm2835-pm", "brcm,bcm2835-pm-wdt"; + #power-domain-cells = <1>; + #reset-cells = <1>; + reg = <0x7e100000 0x114>, + <0x7e00a000 0x24>, + <0x7ec11000 0x20>; + clocks = <&clocks BCM2835_CLOCK_V3D>, + <&clocks BCM2835_CLOCK_PERI_IMAGE>, + <&clocks BCM2835_CLOCK_H264>, + <&clocks BCM2835_CLOCK_ISP>; + clock-names = "v3d", "peri_image", "h264", "isp"; + system-power-controller; + }; + + rng@7e104000 { + compatible = "brcm,bcm2711-rng200"; + reg = <0x7e104000 0x28>; + }; + + uart2: serial@7e201400 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x7e201400 0x200>; + interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clocks BCM2835_CLOCK_UART>, + <&clocks BCM2835_CLOCK_VPU>; + clock-names = "uartclk", "apb_pclk"; + arm,primecell-periphid = <0x00241011>; + status = "disabled"; + }; + + uart3: serial@7e201600 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x7e201600 0x200>; + interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clocks BCM2835_CLOCK_UART>, + <&clocks BCM2835_CLOCK_VPU>; + clock-names = "uartclk", "apb_pclk"; + arm,primecell-periphid = <0x00241011>; + status = "disabled"; + }; + + uart4: serial@7e201800 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x7e201800 0x200>; + interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clocks BCM2835_CLOCK_UART>, + <&clocks BCM2835_CLOCK_VPU>; + clock-names = "uartclk", "apb_pclk"; + arm,primecell-periphid = <0x00241011>; + status = "disabled"; + }; + + uart5: serial@7e201a00 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x7e201a00 0x200>; + interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clocks BCM2835_CLOCK_UART>, + <&clocks BCM2835_CLOCK_VPU>; + clock-names = "uartclk", "apb_pclk"; + arm,primecell-periphid = <0x00241011>; + status = "disabled"; + }; + + spi3: spi@7e204600 { + compatible = "brcm,bcm2835-spi"; + reg = <0x7e204600 0x0200>; + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clocks BCM2835_CLOCK_VPU>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; + + spi4: spi@7e204800 { + compatible = "brcm,bcm2835-spi"; + reg = <0x7e204800 0x0200>; + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clocks BCM2835_CLOCK_VPU>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; + + spi5: spi@7e204a00 { + compatible = "brcm,bcm2835-spi"; + reg = <0x7e204a00 0x0200>; + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clocks BCM2835_CLOCK_VPU>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; + + spi6: spi@7e204c00 { + compatible = "brcm,bcm2835-spi"; + reg = <0x7e204c00 0x0200>; + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clocks BCM2835_CLOCK_VPU>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; + + i2c3: i2c@7e205600 { + compatible = "brcm,bcm2711-i2c", "brcm,bcm2835-i2c"; + reg = <0x7e205600 0x200>; + interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clocks BCM2835_CLOCK_VPU>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; + + i2c4: i2c@7e205800 { + compatible = "brcm,bcm2711-i2c", "brcm,bcm2835-i2c"; + reg = <0x7e205800 0x200>; + interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clocks BCM2835_CLOCK_VPU>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; + + i2c5: i2c@7e205a00 { + compatible = "brcm,bcm2711-i2c", "brcm,bcm2835-i2c"; + reg = <0x7e205a00 0x200>; + interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clocks BCM2835_CLOCK_VPU>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; + + i2c6: i2c@7e205c00 { + compatible = "brcm,bcm2711-i2c", "brcm,bcm2835-i2c"; + reg = <0x7e205c00 0x200>; + interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clocks BCM2835_CLOCK_VPU>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; + + pixelvalve0: pixelvalve@7e206000 { + compatible = "brcm,bcm2711-pixelvalve0"; + reg = <0x7e206000 0x100>; + interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + }; + + pixelvalve1: pixelvalve@7e207000 { + compatible = "brcm,bcm2711-pixelvalve1"; + reg = <0x7e207000 0x100>; + interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + }; + + pixelvalve2: pixelvalve@7e20a000 { + compatible = "brcm,bcm2711-pixelvalve2"; + reg = <0x7e20a000 0x100>; + interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + }; + + pwm1: pwm@7e20c800 { + compatible = "brcm,bcm2835-pwm"; + reg = <0x7e20c800 0x28>; + clocks = <&clocks BCM2835_CLOCK_PWM>; + assigned-clocks = <&clocks BCM2835_CLOCK_PWM>; + assigned-clock-rates = <10000000>; + #pwm-cells = <2>; + status = "disabled"; + }; + + pixelvalve4: pixelvalve@7e216000 { + compatible = "brcm,bcm2711-pixelvalve4"; + reg = <0x7e216000 0x100>; + interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + }; + + hvs: hvs@7e400000 { + compatible = "brcm,bcm2711-hvs"; + interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>; + }; + + pixelvalve3: pixelvalve@7ec12000 { + compatible = "brcm,bcm2711-pixelvalve3"; + reg = <0x7ec12000 0x100>; + interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + }; + + vec: vec@7ec13000 { + compatible = "brcm,bcm2711-vec"; + reg = <0x7ec13000 0x1000>; + clocks = <&clocks BCM2835_CLOCK_VEC>; + interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + }; + + dvp: clock@7ef00000 { + compatible = "brcm,brcm2711-dvp"; + reg = <0x7ef00000 0x10>; + clocks = <&clk_108MHz>; + #clock-cells = <1>; + #reset-cells = <1>; + }; + + aon_intr: interrupt-controller@7ef00100 { + compatible = "brcm,bcm2711-l2-intc", "brcm,l2-intc"; + reg = <0x7ef00100 0x30>; + interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <1>; + }; + + hdmi0: hdmi@7ef00700 { + compatible = "brcm,bcm2711-hdmi0"; + reg = <0x7ef00700 0x300>, + <0x7ef00300 0x200>, + <0x7ef00f00 0x80>, + <0x7ef00f80 0x80>, + <0x7ef01b00 0x200>, + <0x7ef01f00 0x400>, + <0x7ef00200 0x80>, + <0x7ef04300 0x100>, + <0x7ef20000 0x100>; + reg-names = "hdmi", + "dvp", + "phy", + "rm", + "packet", + "metadata", + "csc", + "cec", + "hd"; + clock-names = "hdmi", "bvb", "audio", "cec"; + resets = <&dvp 0>; + interrupt-parent = <&aon_intr>; + interrupts = <0>, <1>, <2>, + <3>, <4>, <5>; + interrupt-names = "cec-tx", "cec-rx", "cec-low", + "wakeup", "hpd-connected", "hpd-removed"; + ddc = <&ddc0>; + dmas = <&dma 10>; + dma-names = "audio-rx"; + status = "disabled"; + }; + + ddc0: i2c@7ef04500 { + compatible = "brcm,bcm2711-hdmi-i2c"; + reg = <0x7ef04500 0x100>, <0x7ef00b00 0x300>; + reg-names = "bsc", "auto-i2c"; + clock-frequency = <97500>; + status = "disabled"; + }; + + hdmi1: hdmi@7ef05700 { + compatible = "brcm,bcm2711-hdmi1"; + reg = <0x7ef05700 0x300>, + <0x7ef05300 0x200>, + <0x7ef05f00 0x80>, + <0x7ef05f80 0x80>, + <0x7ef06b00 0x200>, + <0x7ef06f00 0x400>, + <0x7ef00280 0x80>, + <0x7ef09300 0x100>, + <0x7ef20000 0x100>; + reg-names = "hdmi", + "dvp", + "phy", + "rm", + "packet", + "metadata", + "csc", + "cec", + "hd"; + ddc = <&ddc1>; + clock-names = "hdmi", "bvb", "audio", "cec"; + resets = <&dvp 1>; + interrupt-parent = <&aon_intr>; + interrupts = <8>, <7>, <6>, + <9>, <10>, <11>; + interrupt-names = "cec-tx", "cec-rx", "cec-low", + "wakeup", "hpd-connected", "hpd-removed"; + dmas = <&dma 17>; + dma-names = "audio-rx"; + status = "disabled"; + }; + + ddc1: i2c@7ef09500 { + compatible = "brcm,bcm2711-hdmi-i2c"; + reg = <0x7ef09500 0x100>, <0x7ef05b00 0x300>; + reg-names = "bsc", "auto-i2c"; + clock-frequency = <97500>; + status = "disabled"; + }; + }; + + /* + * emmc2 has different DMA constraints based on SoC revisions. It was + * moved into its own bus, so as for RPi4's firmware to update them. + * The firmware will find whether the emmc2bus alias is defined, and if + * so, it'll edit the dma-ranges property below accordingly. + */ + emmc2bus: emmc2bus { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + + ranges = <0x0 0x7e000000 0x0 0xfe000000 0x01800000>; + dma-ranges = <0x0 0xc0000000 0x0 0x00000000 0x40000000>; + + emmc2: mmc@7e340000 { + compatible = "brcm,bcm2711-emmc2"; + reg = <0x0 0x7e340000 0x100>; + interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clocks BCM2711_CLOCK_EMMC2>; + status = "disabled"; + }; + }; + + arm-pmu { + compatible = "arm,cortex-a72-pmu", "arm,armv8-pmuv3"; + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>; + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | + IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | + IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | + IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | + IRQ_TYPE_LEVEL_LOW)>; + /* This only applies to the ARMv7 stub */ + arm,cpu-registers-not-fw-configured; + }; + + cpus: cpus { + #address-cells = <1>; + #size-cells = <0>; + enable-method = "brcm,bcm2836-smp"; // for ARM 32-bit + + cpu0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a72"; + reg = <0>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x000000d8>; + }; + + cpu1: cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a72"; + reg = <1>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x000000e0>; + }; + + cpu2: cpu@2 { + device_type = "cpu"; + compatible = "arm,cortex-a72"; + reg = <2>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x000000e8>; + }; + + cpu3: cpu@3 { + device_type = "cpu"; + compatible = "arm,cortex-a72"; + reg = <3>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x000000f0>; + }; + }; + + scb { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + + ranges = <0x0 0x7c000000 0x0 0xfc000000 0x03800000>, + <0x6 0x00000000 0x6 0x00000000 0x40000000>; + + pcie0: pcie@7d500000 { + compatible = "brcm,bcm2711-pcie"; + reg = <0x0 0x7d500000 0x9310>; + device_type = "pci"; + #address-cells = <3>; + #interrupt-cells = <1>; + #size-cells = <2>; + interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "pcie", "msi"; + interrupt-map-mask = <0x0 0x0 0x0 0x7>; + interrupt-map = <0 0 0 1 &gicv2 GIC_SPI 143 + IRQ_TYPE_LEVEL_HIGH>; + msi-controller; + msi-parent = <&pcie0>; + + ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 + 0x0 0x04000000>; + /* + * The wrapper around the PCIe block has a bug + * preventing it from accessing beyond the first 3GB of + * memory. + */ + dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000 + 0x0 0xc0000000>; + brcm,enable-ssc; + }; + + genet: ethernet@7d580000 { + compatible = "brcm,bcm2711-genet-v5"; + reg = <0x0 0x7d580000 0x10000>; + #address-cells = <0x1>; + #size-cells = <0x1>; + interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + + genet_mdio: mdio@e14 { + compatible = "brcm,genet-mdio-v5"; + reg = <0xe14 0x8>; + reg-names = "mdio"; + #address-cells = <0x1>; + #size-cells = <0x0>; + }; + }; + }; +}; + +&clk_osc { + clock-frequency = <54000000>; +}; + +&clocks { + compatible = "brcm,bcm2711-cprman"; +}; + +&cpu_thermal { + coefficients = <(-487) 410040>; + thermal-sensors = <&thermal>; +}; + +&dsi0 { + interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>; +}; + +&dsi1 { + interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>; + compatible = "brcm,bcm2711-dsi1"; +}; + +&gpio { + compatible = "brcm,bcm2711-gpio"; + interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>; + + gpclk0_gpio49: gpclk0_gpio49 { + pin-gpclk { + pins = "gpio49"; + function = "alt1"; + bias-disable; + }; + }; + gpclk1_gpio50: gpclk1_gpio50 { + pin-gpclk { + pins = "gpio50"; + function = "alt1"; + bias-disable; + }; + }; + gpclk2_gpio51: gpclk2_gpio51 { + pin-gpclk { + pins = "gpio51"; + function = "alt1"; + bias-disable; + }; + }; + + i2c0_gpio46: i2c0_gpio46 { + pin-sda { + function = "alt0"; + pins = "gpio46"; + bias-pull-up; + }; + pin-scl { + function = "alt0"; + pins = "gpio47"; + bias-disable; + }; + }; + i2c1_gpio46: i2c1_gpio46 { + pin-sda { + function = "alt1"; + pins = "gpio46"; + bias-pull-up; + }; + pin-scl { + function = "alt1"; + pins = "gpio47"; + bias-disable; + }; + }; + i2c3_gpio2: i2c3_gpio2 { + pin-sda { + function = "alt5"; + pins = "gpio2"; + bias-pull-up; + }; + pin-scl { + function = "alt5"; + pins = "gpio3"; + bias-disable; + }; + }; + i2c3_gpio4: i2c3_gpio4 { + pin-sda { + function = "alt5"; + pins = "gpio4"; + bias-pull-up; + }; + pin-scl { + function = "alt5"; + pins = "gpio5"; + bias-disable; + }; + }; + i2c4_gpio6: i2c4_gpio6 { + pin-sda { + function = "alt5"; + pins = "gpio6"; + bias-pull-up; + }; + pin-scl { + function = "alt5"; + pins = "gpio7"; + bias-disable; + }; + }; + i2c4_gpio8: i2c4_gpio8 { + pin-sda { + function = "alt5"; + pins = "gpio8"; + bias-pull-up; + }; + pin-scl { + function = "alt5"; + pins = "gpio9"; + bias-disable; + }; + }; + i2c5_gpio10: i2c5_gpio10 { + pin-sda { + function = "alt5"; + pins = "gpio10"; + bias-pull-up; + }; + pin-scl { + function = "alt5"; + pins = "gpio11"; + bias-disable; + }; + }; + i2c5_gpio12: i2c5_gpio12 { + pin-sda { + function = "alt5"; + pins = "gpio12"; + bias-pull-up; + }; + pin-scl { + function = "alt5"; + pins = "gpio13"; + bias-disable; + }; + }; + i2c6_gpio0: i2c6_gpio0 { + pin-sda { + function = "alt5"; + pins = "gpio0"; + bias-pull-up; + }; + pin-scl { + function = "alt5"; + pins = "gpio1"; + bias-disable; + }; + }; + i2c6_gpio22: i2c6_gpio22 { + pin-sda { + function = "alt5"; + pins = "gpio22"; + bias-pull-up; + }; + pin-scl { + function = "alt5"; + pins = "gpio23"; + bias-disable; + }; + }; + i2c_slave_gpio8: i2c_slave_gpio8 { + pins-i2c-slave { + pins = "gpio8", + "gpio9", + "gpio10", + "gpio11"; + function = "alt3"; + }; + }; + + jtag_gpio48: jtag_gpio48 { + pins-jtag { + pins = "gpio48", + "gpio49", + "gpio50", + "gpio51", + "gpio52", + "gpio53"; + function = "alt4"; + }; + }; + + mii_gpio28: mii_gpio28 { + pins-mii { + pins = "gpio28", + "gpio29", + "gpio30", + "gpio31"; + function = "alt4"; + }; + }; + mii_gpio36: mii_gpio36 { + pins-mii { + pins = "gpio36", + "gpio37", + "gpio38", + "gpio39"; + function = "alt5"; + }; + }; + + pcm_gpio50: pcm_gpio50 { + pins-pcm { + pins = "gpio50", + "gpio51", + "gpio52", + "gpio53"; + function = "alt2"; + }; + }; + + pwm0_0_gpio12: pwm0_0_gpio12 { + pin-pwm { + pins = "gpio12"; + function = "alt0"; + bias-disable; + }; + }; + pwm0_0_gpio18: pwm0_0_gpio18 { + pin-pwm { + pins = "gpio18"; + function = "alt5"; + bias-disable; + }; + }; + pwm1_0_gpio40: pwm1_0_gpio40 { + pin-pwm { + pins = "gpio40"; + function = "alt0"; + bias-disable; + }; + }; + pwm0_1_gpio13: pwm0_1_gpio13 { + pin-pwm { + pins = "gpio13"; + function = "alt0"; + bias-disable; + }; + }; + pwm0_1_gpio19: pwm0_1_gpio19 { + pin-pwm { + pins = "gpio19"; + function = "alt5"; + bias-disable; + }; + }; + pwm1_1_gpio41: pwm1_1_gpio41 { + pin-pwm { + pins = "gpio41"; + function = "alt0"; + bias-disable; + }; + }; + pwm0_1_gpio45: pwm0_1_gpio45 { + pin-pwm { + pins = "gpio45"; + function = "alt0"; + bias-disable; + }; + }; + pwm0_0_gpio52: pwm0_0_gpio52 { + pin-pwm { + pins = "gpio52"; + function = "alt1"; + bias-disable; + }; + }; + pwm0_1_gpio53: pwm0_1_gpio53 { + pin-pwm { + pins = "gpio53"; + function = "alt1"; + bias-disable; + }; + }; + + rgmii_gpio35: rgmii_gpio35 { + pin-start-stop { + pins = "gpio35"; + function = "alt4"; + }; + pin-rx-ok { + pins = "gpio36"; + function = "alt4"; + }; + }; + rgmii_irq_gpio34: rgmii_irq_gpio34 { + pin-irq { + pins = "gpio34"; + function = "alt5"; + }; + }; + rgmii_irq_gpio39: rgmii_irq_gpio39 { + pin-irq { + pins = "gpio39"; + function = "alt4"; + }; + }; + rgmii_mdio_gpio28: rgmii_mdio_gpio28 { + pins-mdio { + pins = "gpio28", + "gpio29"; + function = "alt5"; + }; + }; + rgmii_mdio_gpio37: rgmii_mdio_gpio37 { + pins-mdio { + pins = "gpio37", + "gpio38"; + function = "alt4"; + }; + }; + + spi0_gpio46: spi0_gpio46 { + pins-spi { + pins = "gpio46", + "gpio47", + "gpio48", + "gpio49"; + function = "alt2"; + }; + }; + spi2_gpio46: spi2_gpio46 { + pins-spi { + pins = "gpio46", + "gpio47", + "gpio48", + "gpio49", + "gpio50"; + function = "alt5"; + }; + }; + spi3_gpio0: spi3_gpio0 { + pins-spi { + pins = "gpio0", + "gpio1", + "gpio2", + "gpio3"; + function = "alt3"; + }; + }; + spi4_gpio4: spi4_gpio4 { + pins-spi { + pins = "gpio4", + "gpio5", + "gpio6", + "gpio7"; + function = "alt3"; + }; + }; + spi5_gpio12: spi5_gpio12 { + pins-spi { + pins = "gpio12", + "gpio13", + "gpio14", + "gpio15"; + function = "alt3"; + }; + }; + spi6_gpio18: spi6_gpio18 { + pins-spi { + pins = "gpio18", + "gpio19", + "gpio20", + "gpio21"; + function = "alt3"; + }; + }; + + uart2_gpio0: uart2_gpio0 { + pin-tx { + pins = "gpio0"; + function = "alt4"; + bias-disable; + }; + pin-rx { + pins = "gpio1"; + function = "alt4"; + bias-pull-up; + }; + }; + uart2_ctsrts_gpio2: uart2_ctsrts_gpio2 { + pin-cts { + pins = "gpio2"; + function = "alt4"; + bias-pull-up; + }; + pin-rts { + pins = "gpio3"; + function = "alt4"; + bias-disable; + }; + }; + uart3_gpio4: uart3_gpio4 { + pin-tx { + pins = "gpio4"; + function = "alt4"; + bias-disable; + }; + pin-rx { + pins = "gpio5"; + function = "alt4"; + bias-pull-up; + }; + }; + uart3_ctsrts_gpio6: uart3_ctsrts_gpio6 { + pin-cts { + pins = "gpio6"; + function = "alt4"; + bias-pull-up; + }; + pin-rts { + pins = "gpio7"; + function = "alt4"; + bias-disable; + }; + }; + uart4_gpio8: uart4_gpio8 { + pin-tx { + pins = "gpio8"; + function = "alt4"; + bias-disable; + }; + pin-rx { + pins = "gpio9"; + function = "alt4"; + bias-pull-up; + }; + }; + uart4_ctsrts_gpio10: uart4_ctsrts_gpio10 { + pin-cts { + pins = "gpio10"; + function = "alt4"; + bias-pull-up; + }; + pin-rts { + pins = "gpio11"; + function = "alt4"; + bias-disable; + }; + }; + uart5_gpio12: uart5_gpio12 { + pin-tx { + pins = "gpio12"; + function = "alt4"; + bias-disable; + }; + pin-rx { + pins = "gpio13"; + function = "alt4"; + bias-pull-up; + }; + }; + uart5_ctsrts_gpio14: uart5_ctsrts_gpio14 { + pin-cts { + pins = "gpio14"; + function = "alt4"; + bias-pull-up; + }; + pin-rts { + pins = "gpio15"; + function = "alt4"; + bias-disable; + }; + }; +}; + +&rmem { + #address-cells = <2>; +}; + +&cma { + /* + * arm64 reserves the CMA by default somewhere in ZONE_DMA32, + * that's not good enough for the BCM2711 as some devices can + * only address the lower 1G of memory (ZONE_DMA). + */ + alloc-ranges = <0x0 0x00000000 0x40000000>; +}; + +&i2c0 { + compatible = "brcm,bcm2711-i2c", "brcm,bcm2835-i2c"; + interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>; +}; + +&i2c1 { + compatible = "brcm,bcm2711-i2c", "brcm,bcm2835-i2c"; + interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>; +}; + +&mailbox { + interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>; +}; + +&sdhci { + interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>; +}; + +&sdhost { + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; +}; + +&spi { + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>; +}; + +&spi1 { + interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>; +}; + +&spi2 { + interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>; +}; + +&system_timer { + interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; +}; + +&txp { + interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>; +}; + +&uart0 { + interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>; +}; + +&uart1 { + interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>; +}; + +&usb { + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>; +}; + +&vec { + compatible = "brcm,bcm2711-vec"; + interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>; +}; diff --git a/arch/arm/dts/bcm2835-common.dtsi b/arch/arm/dts/bcm2835-common.dtsi new file mode 100644 index 00000000000..c25e797b906 --- /dev/null +++ b/arch/arm/dts/bcm2835-common.dtsi @@ -0,0 +1,207 @@ +// SPDX-License-Identifier: GPL-2.0 + +/* This include file covers the common peripherals and configuration between + * bcm2835, bcm2836 and bcm2837 implementations. + */ + +/ { + interrupt-parent = <&intc>; + + soc { + dma: dma@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xf00>; + interrupts = <1 16>, + <1 17>, + <1 18>, + <1 19>, + <1 20>, + <1 21>, + <1 22>, + <1 23>, + <1 24>, + <1 25>, + <1 26>, + /* dma channel 11-14 share one irq */ + <1 27>, + <1 27>, + <1 27>, + <1 27>, + /* unused shared irq for all channels */ + <1 28>; + interrupt-names = "dma0", + "dma1", + "dma2", + "dma3", + "dma4", + "dma5", + "dma6", + "dma7", + "dma8", + "dma9", + "dma10", + "dma11", + "dma12", + "dma13", + "dma14", + "dma-shared-all"; + #dma-cells = <1>; + brcm,dma-channel-mask = <0x7f35>; + }; + + intc: interrupt-controller@7e00b200 { + compatible = "brcm,bcm2835-armctrl-ic"; + reg = <0x7e00b200 0x200>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + pm: watchdog@7e100000 { + compatible = "brcm,bcm2835-pm", "brcm,bcm2835-pm-wdt"; + #power-domain-cells = <1>; + #reset-cells = <1>; + reg = <0x7e100000 0x114>, + <0x7e00a000 0x24>; + clocks = <&clocks BCM2835_CLOCK_V3D>, + <&clocks BCM2835_CLOCK_PERI_IMAGE>, + <&clocks BCM2835_CLOCK_H264>, + <&clocks BCM2835_CLOCK_ISP>; + clock-names = "v3d", "peri_image", "h264", "isp"; + system-power-controller; + }; + + rng@7e104000 { + compatible = "brcm,bcm2835-rng"; + reg = <0x7e104000 0x10>; + interrupts = <2 29>; + }; + + pixelvalve@7e206000 { + compatible = "brcm,bcm2835-pixelvalve0"; + reg = <0x7e206000 0x100>; + interrupts = <2 13>; /* pwa0 */ + }; + + pixelvalve@7e207000 { + compatible = "brcm,bcm2835-pixelvalve1"; + reg = <0x7e207000 0x100>; + interrupts = <2 14>; /* pwa1 */ + }; + + thermal: thermal@7e212000 { + compatible = "brcm,bcm2835-thermal"; + reg = <0x7e212000 0x8>; + clocks = <&clocks BCM2835_CLOCK_TSENS>; + #thermal-sensor-cells = <0>; + status = "disabled"; + }; + + i2c2: i2c@7e805000 { + compatible = "brcm,bcm2835-i2c"; + reg = <0x7e805000 0x1000>; + interrupts = <2 21>; + clocks = <&clocks BCM2835_CLOCK_VPU>; + #address-cells = <1>; + #size-cells = <0>; + status = "okay"; + }; + + vec: vec@7e806000 { + compatible = "brcm,bcm2835-vec"; + reg = <0x7e806000 0x1000>; + clocks = <&clocks BCM2835_CLOCK_VEC>; + interrupts = <2 27>; + status = "disabled"; + }; + + pixelvalve@7e807000 { + compatible = "brcm,bcm2835-pixelvalve2"; + reg = <0x7e807000 0x100>; + interrupts = <2 10>; /* pixelvalve */ + }; + + hdmi: hdmi@7e902000 { + compatible = "brcm,bcm2835-hdmi"; + reg = <0x7e902000 0x600>, + <0x7e808000 0x100>; + interrupts = <2 8>, <2 9>; + ddc = <&i2c2>; + clocks = <&clocks BCM2835_PLLH_PIX>, + <&clocks BCM2835_CLOCK_HSM>; + clock-names = "pixel", "hdmi"; + dmas = <&dma 17>; + dma-names = "audio-rx"; + status = "disabled"; + }; + + v3d: v3d@7ec00000 { + compatible = "brcm,bcm2835-v3d"; + reg = <0x7ec00000 0x1000>; + interrupts = <1 10>; + }; + + vc4: gpu { + compatible = "brcm,bcm2835-vc4"; + }; + }; +}; + +&cpu_thermal { + thermal-sensors = <&thermal>; +}; + +&gpio { + i2c_slave_gpio18: i2c_slave_gpio18 { + brcm,pins = <18 19 20 21>; + brcm,function = <BCM2835_FSEL_ALT3>; + }; + + jtag_gpio4: jtag_gpio4 { + brcm,pins = <4 5 6 12 13>; + brcm,function = <BCM2835_FSEL_ALT5>; + }; + + pwm0_gpio12: pwm0_gpio12 { + brcm,pins = <12>; + brcm,function = <BCM2835_FSEL_ALT0>; + }; + pwm0_gpio18: pwm0_gpio18 { + brcm,pins = <18>; + brcm,function = <BCM2835_FSEL_ALT5>; + }; + pwm0_gpio40: pwm0_gpio40 { + brcm,pins = <40>; + brcm,function = <BCM2835_FSEL_ALT0>; + }; + pwm1_gpio13: pwm1_gpio13 { + brcm,pins = <13>; + brcm,function = <BCM2835_FSEL_ALT0>; + }; + pwm1_gpio19: pwm1_gpio19 { + brcm,pins = <19>; + brcm,function = <BCM2835_FSEL_ALT5>; + }; + pwm1_gpio41: pwm1_gpio41 { + brcm,pins = <41>; + brcm,function = <BCM2835_FSEL_ALT0>; + }; + pwm1_gpio45: pwm1_gpio45 { + brcm,pins = <45>; + brcm,function = <BCM2835_FSEL_ALT0>; + }; +}; + +&i2s { + dmas = <&dma 2>, <&dma 3>; + dma-names = "tx", "rx"; +}; + +&sdhost { + dmas = <&dma 13>; + dma-names = "rx-tx"; +}; + +&spi { + dmas = <&dma 6>, <&dma 7>; + dma-names = "tx", "rx"; +}; diff --git a/arch/arm/dts/bcm2835-rpi-a-plus.dts b/arch/arm/dts/bcm2835-rpi-a-plus.dts index db8a6017f22..40b9405f1a8 100644 --- a/arch/arm/dts/bcm2835-rpi-a-plus.dts +++ b/arch/arm/dts/bcm2835-rpi-a-plus.dts @@ -8,12 +8,17 @@ compatible = "raspberrypi,model-a-plus", "brcm,bcm2835"; model = "Raspberry Pi Model A+";

+ memory@0 { + device_type = "memory"; + reg = <0 0x10000000>; + }; + leds { - act { + led-act { gpios = <&gpio 47 GPIO_ACTIVE_HIGH>; };

- pwr { + led-pwr { label = "PWR"; gpios = <&gpio 35 GPIO_ACTIVE_HIGH>; default-state = "keep"; @@ -99,6 +104,8 @@

&hdmi { hpd-gpios = <&gpio 46 GPIO_ACTIVE_LOW>; + power-domains = <&power RPI_POWER_DOMAIN_HDMI>; + status = "okay"; };

&pwm { @@ -107,6 +114,13 @@ status = "okay"; };

+&sdhost { + pinctrl-names = "default"; + pinctrl-0 = <&sdhost_gpio48>; + bus-width = <4>; + status = "okay"; +}; + &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_gpio14>; diff --git a/arch/arm/dts/bcm2835-rpi-a.dts b/arch/arm/dts/bcm2835-rpi-a.dts index 067d1f07a2d..11edb581dba 100644 --- a/arch/arm/dts/bcm2835-rpi-a.dts +++ b/arch/arm/dts/bcm2835-rpi-a.dts @@ -8,8 +8,13 @@ compatible = "raspberrypi,model-a", "brcm,bcm2835"; model = "Raspberry Pi Model A";

+ memory@0 { + device_type = "memory"; + reg = <0 0x10000000>; + }; + leds { - act { + led-act { gpios = <&gpio 16 GPIO_ACTIVE_LOW>; }; }; @@ -94,6 +99,8 @@

&hdmi { hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>; + power-domains = <&power RPI_POWER_DOMAIN_HDMI>; + status = "okay"; };

&pwm { @@ -102,6 +109,13 @@ status = "okay"; };

+&sdhost { + pinctrl-names = "default"; + pinctrl-0 = <&sdhost_gpio48>; + bus-width = <4>; + status = "okay"; +}; + &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_gpio14>; diff --git a/arch/arm/dts/bcm2835-rpi-b-plus.dts b/arch/arm/dts/bcm2835-rpi-b-plus.dts index 1e40d672b05..1b435c64bd9 100644 --- a/arch/arm/dts/bcm2835-rpi-b-plus.dts +++ b/arch/arm/dts/bcm2835-rpi-b-plus.dts @@ -9,12 +9,17 @@ compatible = "raspberrypi,model-b-plus", "brcm,bcm2835"; model = "Raspberry Pi Model B+";

+ memory@0 { + device_type = "memory"; + reg = <0 0x20000000>; + }; + leds { - act { + led-act { gpios = <&gpio 47 GPIO_ACTIVE_HIGH>; };

- pwr { + led-pwr { label = "PWR"; gpios = <&gpio 35 GPIO_ACTIVE_HIGH>; default-state = "keep"; @@ -101,6 +106,8 @@

&hdmi { hpd-gpios = <&gpio 46 GPIO_ACTIVE_LOW>; + power-domains = <&power RPI_POWER_DOMAIN_HDMI>; + status = "okay"; };

&pwm { @@ -109,6 +116,13 @@ status = "okay"; };

+&sdhost { + pinctrl-names = "default"; + pinctrl-0 = <&sdhost_gpio48>; + bus-width = <4>; + status = "okay"; +}; + &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_gpio14>; diff --git a/arch/arm/dts/bcm2835-rpi-b-rev2.dts b/arch/arm/dts/bcm2835-rpi-b-rev2.dts index 28e7513ce61..a23c25c00ee 100644 --- a/arch/arm/dts/bcm2835-rpi-b-rev2.dts +++ b/arch/arm/dts/bcm2835-rpi-b-rev2.dts @@ -9,8 +9,13 @@ compatible = "raspberrypi,model-b-rev2", "brcm,bcm2835"; model = "Raspberry Pi Model B rev2";

+ memory@0 { + device_type = "memory"; + reg = <0 0x10000000>; + }; + leds { - act { + led-act { gpios = <&gpio 16 GPIO_ACTIVE_LOW>; }; }; @@ -94,6 +99,8 @@

&hdmi { hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>; + power-domains = <&power RPI_POWER_DOMAIN_HDMI>; + status = "okay"; };

&pwm { @@ -102,6 +109,13 @@ status = "okay"; };

+&sdhost { + pinctrl-names = "default"; + pinctrl-0 = <&sdhost_gpio48>; + bus-width = <4>; + status = "okay"; +}; + &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_gpio14>; diff --git a/arch/arm/dts/bcm2835-rpi-b.dts b/arch/arm/dts/bcm2835-rpi-b.dts index 31ff602e2cd..1b63d6b1975 100644 --- a/arch/arm/dts/bcm2835-rpi-b.dts +++ b/arch/arm/dts/bcm2835-rpi-b.dts @@ -9,8 +9,13 @@ compatible = "raspberrypi,model-b", "brcm,bcm2835"; model = "Raspberry Pi Model B";

+ memory@0 { + device_type = "memory"; + reg = <0 0x10000000>; + }; + leds { - act { + led-act { gpios = <&gpio 16 GPIO_ACTIVE_LOW>; }; }; @@ -89,6 +94,8 @@

&hdmi { hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>; + power-domains = <&power RPI_POWER_DOMAIN_HDMI>; + status = "okay"; };

&pwm { @@ -97,6 +104,13 @@ status = "okay"; };

+&sdhost { + pinctrl-names = "default"; + pinctrl-0 = <&sdhost_gpio48>; + bus-width = <4>; + status = "okay"; +}; + &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_gpio14>; diff --git a/arch/arm/dts/bcm2835-rpi-cm1-io1.dts b/arch/arm/dts/bcm2835-rpi-cm1-io1.dts index 4764a25585a..a75c882e657 100644 --- a/arch/arm/dts/bcm2835-rpi-cm1-io1.dts +++ b/arch/arm/dts/bcm2835-rpi-cm1-io1.dts @@ -79,6 +79,15 @@

&hdmi { hpd-gpios = <&gpio 46 GPIO_ACTIVE_LOW>; + power-domains = <&power RPI_POWER_DOMAIN_HDMI>; + status = "okay"; +}; + +&sdhost { + pinctrl-names = "default"; + pinctrl-0 = <&sdhost_gpio48>; + bus-width = <4>; + status = "okay"; };

&uart0 { diff --git a/arch/arm/dts/bcm2835-rpi-cm1.dtsi b/arch/arm/dts/bcm2835-rpi-cm1.dtsi index ef22c2da783..e4e6b6abbfc 100644 --- a/arch/arm/dts/bcm2835-rpi-cm1.dtsi +++ b/arch/arm/dts/bcm2835-rpi-cm1.dtsi @@ -5,11 +5,16 @@

/ { leds { - act { + led-act { gpios = <&gpio 47 GPIO_ACTIVE_LOW>; }; };

+ memory@0 { + device_type = "memory"; + reg = <0 0x20000000>; + }; + reg_3v3: fixed-regulator { compatible = "regulator-fixed"; regulator-name = "3V3"; diff --git a/arch/arm/dts/bcm2835-rpi-common.dtsi b/arch/arm/dts/bcm2835-rpi-common.dtsi new file mode 100644 index 00000000000..8a55b6cded5 --- /dev/null +++ b/arch/arm/dts/bcm2835-rpi-common.dtsi @@ -0,0 +1,12 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * This include file covers the common peripherals and configuration between + * bcm2835, bcm2836 and bcm2837 implementations that interact with RPi's + * firmware interface. + */ + +#include <dt-bindings/power/raspberrypi-power.h> + +&v3d { + power-domains = <&power RPI_POWER_DOMAIN_V3D>; +}; diff --git a/arch/arm/dts/bcm2835-rpi-zero-w.dts b/arch/arm/dts/bcm2835-rpi-zero-w.dts index ba0167df6c5..33b2b77aa47 100644 --- a/arch/arm/dts/bcm2835-rpi-zero-w.dts +++ b/arch/arm/dts/bcm2835-rpi-zero-w.dts @@ -12,14 +12,19 @@ compatible = "raspberrypi,model-zero-w", "brcm,bcm2835"; model = "Raspberry Pi Zero W";

+ memory@0 { + device_type = "memory"; + reg = <0 0x20000000>; + }; + chosen { /* 8250 auxiliary UART instead of pl011 */ stdout-path = "serial1:115200n8"; };

leds { - act { - gpios = <&gpio 47 GPIO_ACTIVE_HIGH>; + led-act { + gpios = <&gpio 47 GPIO_ACTIVE_LOW>; }; };

@@ -100,12 +105,16 @@

&hdmi { hpd-gpios = <&gpio 46 GPIO_ACTIVE_LOW>; + power-domains = <&power RPI_POWER_DOMAIN_HDMI>; + status = "okay"; };

&sdhci { #address-cells = <1>; #size-cells = <0>; + pinctrl-names = "default"; pinctrl-0 = <&emmc_gpio34 &gpclk2_gpio43>; + bus-width = <4>; mmc-pwrseq = <&wifi_pwrseq>; non-removable; status = "okay"; @@ -116,6 +125,13 @@ }; };

+&sdhost { + pinctrl-names = "default"; + pinctrl-0 = <&sdhost_gpio48>; + bus-width = <4>; + status = "okay"; +}; + &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>; diff --git a/arch/arm/dts/bcm2835-rpi-zero.dts b/arch/arm/dts/bcm2835-rpi-zero.dts index 3b35a8a4a55..6f9b3a908f2 100644 --- a/arch/arm/dts/bcm2835-rpi-zero.dts +++ b/arch/arm/dts/bcm2835-rpi-zero.dts @@ -12,8 +12,13 @@ compatible = "raspberrypi,model-zero", "brcm,bcm2835"; model = "Raspberry Pi Zero";

+ memory@0 { + device_type = "memory"; + reg = <0 0x20000000>; + }; + leds { - act { + led-act { gpios = <&gpio 47 GPIO_ACTIVE_HIGH>; }; }; @@ -96,6 +101,15 @@

&hdmi { hpd-gpios = <&gpio 46 GPIO_ACTIVE_LOW>; + power-domains = <&power RPI_POWER_DOMAIN_HDMI>; + status = "okay"; +}; + +&sdhost { + pinctrl-names = "default"; + pinctrl-0 = <&sdhost_gpio48>; + bus-width = <4>; + status = "okay"; };

&uart0 { diff --git a/arch/arm/dts/bcm2835-rpi.dtsi b/arch/arm/dts/bcm2835-rpi.dtsi index 715d50c6452..87ddcad7608 100644 --- a/arch/arm/dts/bcm2835-rpi.dtsi +++ b/arch/arm/dts/bcm2835-rpi.dtsi @@ -1,15 +1,10 @@ #include <dt-bindings/power/raspberrypi-power.h>

/ { - memory@0 { - device_type = "memory"; - reg = <0 0x10000000>; - }; - leds { compatible = "gpio-leds";

- act { + led-act { label = "ACT"; default-state = "keep"; linux,default-trigger = "heartbeat"; @@ -18,8 +13,12 @@

soc { firmware: firmware { - compatible = "raspberrypi,bcm2835-firmware", "simple-bus"; + compatible = "raspberrypi,bcm2835-firmware", "simple-mfd"; + #address-cells = <1>; + #size-cells = <1>; + mboxes = <&mailbox>; + dma-ranges; };

power: power { @@ -64,32 +63,10 @@ clock-frequency = <100000>; };

-&i2c2 { - status = "okay"; -}; - -&sdhci { - pinctrl-names = "default"; - pinctrl-0 = <&emmc_gpio48>; - bus-width = <4>; -}; - -&sdhost { - pinctrl-names = "default"; - pinctrl-0 = <&sdhost_gpio48>; - status = "okay"; - bus-width = <4>; -}; - &usb { power-domains = <&power RPI_POWER_DOMAIN_USB>; };

-&hdmi { - power-domains = <&power RPI_POWER_DOMAIN_HDMI>; - status = "okay"; -}; - &vec { power-domains = <&power RPI_POWER_DOMAIN_VEC>; status = "okay"; diff --git a/arch/arm/dts/bcm2835.dtsi b/arch/arm/dts/bcm2835.dtsi index a5c3824c805..0549686134e 100644 --- a/arch/arm/dts/bcm2835.dtsi +++ b/arch/arm/dts/bcm2835.dtsi @@ -1,5 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 #include "bcm283x.dtsi" +#include "bcm2835-common.dtsi" +#include "bcm2835-rpi-common.dtsi"

/ { compatible = "brcm,bcm2835"; diff --git a/arch/arm/dts/bcm2836-rpi-2-b.dts b/arch/arm/dts/bcm2836-rpi-2-b.dts index 7b4e651bafd..d8af8eeac7b 100644 --- a/arch/arm/dts/bcm2836-rpi-2-b.dts +++ b/arch/arm/dts/bcm2836-rpi-2-b.dts @@ -10,15 +10,16 @@ model = "Raspberry Pi 2 Model B";

memory@0 { + device_type = "memory"; reg = <0 0x40000000>; };

leds { - act { + led-act { gpios = <&gpio 47 GPIO_ACTIVE_HIGH>; };

- pwr { + led-pwr { label = "PWR"; gpios = <&gpio 35 GPIO_ACTIVE_HIGH>; default-state = "keep"; @@ -105,6 +106,8 @@

&hdmi { hpd-gpios = <&gpio 46 GPIO_ACTIVE_LOW>; + power-domains = <&power RPI_POWER_DOMAIN_HDMI>; + status = "okay"; };

&pwm { @@ -113,6 +116,13 @@ status = "okay"; };

+&sdhost { + pinctrl-names = "default"; + pinctrl-0 = <&sdhost_gpio48>; + bus-width = <4>; + status = "okay"; +}; + &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_gpio14>; diff --git a/arch/arm/dts/bcm2836.dtsi b/arch/arm/dts/bcm2836.dtsi index c933e841388..b390006aef7 100644 --- a/arch/arm/dts/bcm2836.dtsi +++ b/arch/arm/dts/bcm2836.dtsi @@ -1,5 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 #include "bcm283x.dtsi" +#include "bcm2835-common.dtsi" +#include "bcm2835-rpi-common.dtsi"

/ { compatible = "brcm,bcm2836"; diff --git a/arch/arm/dts/bcm2837-rpi-3-a-plus.dts b/arch/arm/dts/bcm2837-rpi-3-a-plus.dts index 7f4437a8eed..77099a7871b 100644 --- a/arch/arm/dts/bcm2837-rpi-3-a-plus.dts +++ b/arch/arm/dts/bcm2837-rpi-3-a-plus.dts @@ -14,17 +14,20 @@ };

memory@0 { + device_type = "memory"; reg = <0 0x20000000>; };

leds { - act { + led-act { gpios = <&gpio 29 GPIO_ACTIVE_HIGH>; };

- pwr { + led-pwr { label = "PWR"; gpios = <&expgpio 2 GPIO_ACTIVE_LOW>; + default-state = "keep"; + linux,default-trigger = "default-on"; }; }; }; @@ -117,6 +120,8 @@

&hdmi { hpd-gpios = <&gpio 28 GPIO_ACTIVE_LOW>; + power-domains = <&power RPI_POWER_DOMAIN_HDMI>; + status = "okay"; };

&pwm { diff --git a/arch/arm/dts/bcm2837-rpi-3-b-plus.dts b/arch/arm/dts/bcm2837-rpi-3-b-plus.dts index c6fa34c2410..61010266ca9 100644 --- a/arch/arm/dts/bcm2837-rpi-3-b-plus.dts +++ b/arch/arm/dts/bcm2837-rpi-3-b-plus.dts @@ -15,17 +15,20 @@ };

memory@0 { + device_type = "memory"; reg = <0 0x40000000>; };

leds { - act { + led-act { gpios = <&gpio 29 GPIO_ACTIVE_HIGH>; };

- pwr { + led-pwr { label = "PWR"; gpios = <&expgpio 2 GPIO_ACTIVE_LOW>; + default-state = "keep"; + linux,default-trigger = "default-on"; }; };

@@ -124,6 +127,8 @@

&hdmi { hpd-gpios = <&gpio 28 GPIO_ACTIVE_LOW>; + power-domains = <&power RPI_POWER_DOMAIN_HDMI>; + status = "okay"; };

&pwm { diff --git a/arch/arm/dts/bcm2837-rpi-3-b.dts b/arch/arm/dts/bcm2837-rpi-3-b.dts index ce71f578c51..dd4a4860409 100644 --- a/arch/arm/dts/bcm2837-rpi-3-b.dts +++ b/arch/arm/dts/bcm2837-rpi-3-b.dts @@ -15,11 +15,12 @@ };

memory@0 { + device_type = "memory"; reg = <0 0x40000000>; };

leds { - act { + led-act { gpios = <&expgpio 2 GPIO_ACTIVE_HIGH>; }; }; @@ -125,6 +126,8 @@

&hdmi { hpd-gpios = <&expgpio 4 GPIO_ACTIVE_LOW>; + power-domains = <&power RPI_POWER_DOMAIN_HDMI>; + status = "okay"; };

/* uart0 communicates with the BT module */ diff --git a/arch/arm/dts/bcm2837-rpi-cm3-io3.dts b/arch/arm/dts/bcm2837-rpi-cm3-io3.dts index 6c8233a36d8..588d9411ceb 100644 --- a/arch/arm/dts/bcm2837-rpi-cm3-io3.dts +++ b/arch/arm/dts/bcm2837-rpi-cm3-io3.dts @@ -78,6 +78,15 @@

&hdmi { hpd-gpios = <&expgpio 1 GPIO_ACTIVE_LOW>; + power-domains = <&power RPI_POWER_DOMAIN_HDMI>; + status = "okay"; +}; + +&sdhost { + pinctrl-names = "default"; + pinctrl-0 = <&sdhost_gpio48>; + bus-width = <4>; + status = "okay"; };

&uart0 { diff --git a/arch/arm/dts/bcm2837-rpi-cm3.dtsi b/arch/arm/dts/bcm2837-rpi-cm3.dtsi index 81399b2c5af..828a20561b9 100644 --- a/arch/arm/dts/bcm2837-rpi-cm3.dtsi +++ b/arch/arm/dts/bcm2837-rpi-cm3.dtsi @@ -5,9 +5,18 @@

/ { memory@0 { + device_type = "memory"; reg = <0 0x40000000>; };

+ leds { + /* + * Since there is no upstream GPIO driver yet, + * remove the incomplete node. + */ + /delete-node/ led-act; + }; + reg_3v3: fixed-regulator { compatible = "regulator-fixed"; regulator-name = "3V3"; diff --git a/arch/arm/dts/bcm2837.dtsi b/arch/arm/dts/bcm2837.dtsi index beb6c502dad..0199ec98cd6 100644 --- a/arch/arm/dts/bcm2837.dtsi +++ b/arch/arm/dts/bcm2837.dtsi @@ -1,4 +1,6 @@ #include "bcm283x.dtsi" +#include "bcm2835-common.dtsi" +#include "bcm2835-rpi-common.dtsi"

/ { compatible = "brcm,bcm2837"; diff --git a/arch/arm/dts/bcm283x-rpi-usb-peripheral.dtsi b/arch/arm/dts/bcm283x-rpi-usb-peripheral.dtsi new file mode 100644 index 00000000000..0ff0e9e2532 --- /dev/null +++ b/arch/arm/dts/bcm283x-rpi-usb-peripheral.dtsi @@ -0,0 +1,7 @@ +// SPDX-License-Identifier: GPL-2.0 +&usb { + dr_mode = "peripheral"; + g-rx-fifo-size = <256>; + g-np-tx-fifo-size = <32>; + g-tx-fifo-size = <256 256 512 512 512 768 768>; +}; diff --git a/arch/arm/dts/bcm283x.dtsi b/arch/arm/dts/bcm283x.dtsi index 9777644c6c2..a3e06b68094 100644 --- a/arch/arm/dts/bcm283x.dtsi +++ b/arch/arm/dts/bcm283x.dtsi @@ -18,7 +18,6 @@ / { compatible = "brcm,bcm2835"; model = "BCM2835"; - interrupt-parent = <&intc>; #address-cells = <1>; #size-cells = <1>;

@@ -31,16 +30,27 @@ stdout-path = "serial0:115200n8"; };

+ rmem: reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + cma: linux,cma { + compatible = "shared-dma-pool"; + size = <0x4000000>; /* 64MB */ + reusable; + linux,cma-default; + }; + }; + thermal-zones { cpu_thermal: cpu-thermal { polling-delay-passive = <0>; polling-delay = <1000>;

- thermal-sensors = <&thermal>; - trips { cpu-crit { - temperature = <80000>; + temperature = <90000>; hysteresis = <0>; type = "critical"; }; @@ -56,7 +66,7 @@ #address-cells = <1>; #size-cells = <1>;

- timer@7e003000 { + system_timer: timer@7e003000 { compatible = "brcm,bcm2835-system-timer"; reg = <0x7e003000 0x1000>; interrupts = <1 0>, <1 1>, <1 2>, <1 3>; @@ -67,74 +77,12 @@ clock-frequency = <1000000>; };

- txp@7e004000 { + txp: txp@7e004000 { compatible = "brcm,bcm2835-txp"; reg = <0x7e004000 0x20>; interrupts = <1 11>; };

- dma: dma@7e007000 { - compatible = "brcm,bcm2835-dma"; - reg = <0x7e007000 0xf00>; - interrupts = <1 16>, - <1 17>, - <1 18>, - <1 19>, - <1 20>, - <1 21>, - <1 22>, - <1 23>, - <1 24>, - <1 25>, - <1 26>, - /* dma channel 11-14 share one irq */ - <1 27>, - <1 27>, - <1 27>, - <1 27>, - /* unused shared irq for all channels */ - <1 28>; - interrupt-names = "dma0", - "dma1", - "dma2", - "dma3", - "dma4", - "dma5", - "dma6", - "dma7", - "dma8", - "dma9", - "dma10", - "dma11", - "dma12", - "dma13", - "dma14", - "dma-shared-all"; - #dma-cells = <1>; - brcm,dma-channel-mask = <0x7f35>; - }; - - intc: interrupt-controller@7e00b200 { - compatible = "brcm,bcm2835-armctrl-ic"; - reg = <0x7e00b200 0x200>; - interrupt-controller; - #interrupt-cells = <2>; - }; - - pm: watchdog@7e100000 { - compatible = "brcm,bcm2835-pm", "brcm,bcm2835-pm-wdt"; - #power-domain-cells = <1>; - #reset-cells = <1>; - reg = <0x7e100000 0x114>, - <0x7e00a000 0x24>; - clocks = <&clocks BCM2835_CLOCK_V3D>, - <&clocks BCM2835_CLOCK_PERI_IMAGE>, - <&clocks BCM2835_CLOCK_H264>, - <&clocks BCM2835_CLOCK_ISP>; - clock-names = "v3d", "peri_image", "h264", "isp"; - system-power-controller; - }; - clocks: cprman@7e101000 { compatible = "brcm,bcm2835-cprman"; #clock-cells = <1>; @@ -149,12 +97,6 @@ <&dsi1 0>, <&dsi1 1>, <&dsi1 2>; };

- rng@7e104000 { - compatible = "brcm,bcm2835-rng"; - reg = <0x7e104000 0x10>; - interrupts = <2 29>; - }; - mailbox: mailbox@7e00b880 { compatible = "brcm,bcm2835-mbox"; reg = <0x7e00b880 0x40>; @@ -184,8 +126,7 @@ interrupt-controller; #interrupt-cells = <2>;

- /* Defines pin muxing groups according to - * BCM2835-ARM-Peripherals.pdf page 102. + /* Defines common pin muxing groups * * While each pin can have its mux selected * for various functions individually, some @@ -263,15 +204,7 @@ brcm,pins = <44 45>; brcm,function = <BCM2835_FSEL_ALT2>; }; - i2c_slave_gpio18: i2c_slave_gpio18 { - brcm,pins = <18 19 20 21>; - brcm,function = <BCM2835_FSEL_ALT3>; - };

- jtag_gpio4: jtag_gpio4 { - brcm,pins = <4 5 6 12 13>; - brcm,function = <BCM2835_FSEL_ALT5>; - }; jtag_gpio22: jtag_gpio22 { brcm,pins = <22 23 24 25 26 27>; brcm,function = <BCM2835_FSEL_ALT4>; @@ -286,35 +219,6 @@ brcm,function = <BCM2835_FSEL_ALT2>; };

- pwm0_gpio12: pwm0_gpio12 { - brcm,pins = <12>; - brcm,function = <BCM2835_FSEL_ALT0>; - }; - pwm0_gpio18: pwm0_gpio18 { - brcm,pins = <18>; - brcm,function = <BCM2835_FSEL_ALT5>; - }; - pwm0_gpio40: pwm0_gpio40 { - brcm,pins = <40>; - brcm,function = <BCM2835_FSEL_ALT0>; - }; - pwm1_gpio13: pwm1_gpio13 { - brcm,pins = <13>; - brcm,function = <BCM2835_FSEL_ALT0>; - }; - pwm1_gpio19: pwm1_gpio19 { - brcm,pins = <19>; - brcm,function = <BCM2835_FSEL_ALT5>; - }; - pwm1_gpio41: pwm1_gpio41 { - brcm,pins = <41>; - brcm,function = <BCM2835_FSEL_ALT0>; - }; - pwm1_gpio45: pwm1_gpio45 { - brcm,pins = <45>; - brcm,function = <BCM2835_FSEL_ALT0>; - }; - sdhost_gpio48: sdhost_gpio48 { brcm,pins = <48 49 50 51 52 53>; brcm,function = <BCM2835_FSEL_ALT0>; @@ -396,8 +300,8 @@ };

uart0: serial@7e201000 { - compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell"; - reg = <0x7e201000 0x1000>; + compatible = "arm,pl011", "arm,primecell"; + reg = <0x7e201000 0x200>; interrupts = <2 25>; clocks = <&clocks BCM2835_CLOCK_UART>, <&clocks BCM2835_CLOCK_VPU>; @@ -410,8 +314,6 @@ reg = <0x7e202000 0x100>; interrupts = <2 24>; clocks = <&clocks BCM2835_CLOCK_VPU>; - dmas = <&dma 13>; - dma-names = "rx-tx"; status = "disabled"; };

@@ -419,16 +321,12 @@ compatible = "brcm,bcm2835-i2s"; reg = <0x7e203000 0x24>; clocks = <&clocks BCM2835_CLOCK_PCM>; - - dmas = <&dma 2>, - <&dma 3>; - dma-names = "tx", "rx"; status = "disabled"; };

spi: spi@7e204000 { compatible = "brcm,bcm2835-spi"; - reg = <0x7e204000 0x1000>; + reg = <0x7e204000 0x200>; interrupts = <2 22>; clocks = <&clocks BCM2835_CLOCK_VPU>; #address-cells = <1>; @@ -438,7 +336,7 @@

i2c0: i2c@7e205000 { compatible = "brcm,bcm2835-i2c"; - reg = <0x7e205000 0x1000>; + reg = <0x7e205000 0x200>; interrupts = <2 21>; clocks = <&clocks BCM2835_CLOCK_VPU>; #address-cells = <1>; @@ -446,18 +344,6 @@ status = "disabled"; };

- pixelvalve@7e206000 { - compatible = "brcm,bcm2835-pixelvalve0"; - reg = <0x7e206000 0x100>; - interrupts = <2 13>; /* pwa0 */ - }; - - pixelvalve@7e207000 { - compatible = "brcm,bcm2835-pixelvalve1"; - reg = <0x7e207000 0x100>; - interrupts = <2 14>; /* pwa1 */ - }; - dpi: dpi@7e208000 { compatible = "brcm,bcm2835-dpi"; reg = <0x7e208000 0x8c>; @@ -486,13 +372,6 @@ "dsi0_ddr2", "dsi0_ddr";

- }; - - thermal: thermal@7e212000 { - compatible = "brcm,bcm2835-thermal"; - reg = <0x7e212000 0x8>; - clocks = <&clocks BCM2835_CLOCK_TSENS>; - #thermal-sensor-cells = <0>; status = "disabled"; };

@@ -541,7 +420,7 @@ status = "disabled"; };

- sdhci: sdhci@7e300000 { + sdhci: mmc@7e300000 { compatible = "brcm,bcm2835-sdhci"; reg = <0x7e300000 0x100>; interrupts = <2 30>; @@ -585,44 +464,6 @@ status = "disabled"; };

- i2c2: i2c@7e805000 { - compatible = "brcm,bcm2835-i2c"; - reg = <0x7e805000 0x1000>; - interrupts = <2 21>; - clocks = <&clocks BCM2835_CLOCK_VPU>; - #address-cells = <1>; - #size-cells = <0>; - status = "disabled"; - }; - - vec: vec@7e806000 { - compatible = "brcm,bcm2835-vec"; - reg = <0x7e806000 0x1000>; - clocks = <&clocks BCM2835_CLOCK_VEC>; - interrupts = <2 27>; - status = "disabled"; - }; - - pixelvalve@7e807000 { - compatible = "brcm,bcm2835-pixelvalve2"; - reg = <0x7e807000 0x100>; - interrupts = <2 10>; /* pixelvalve */ - }; - - hdmi: hdmi@7e902000 { - compatible = "brcm,bcm2835-hdmi"; - reg = <0x7e902000 0x600>, - <0x7e808000 0x100>; - interrupts = <2 8>, <2 9>; - ddc = <&i2c2>; - clocks = <&clocks BCM2835_PLLH_PIX>, - <&clocks BCM2835_CLOCK_HSM>; - clock-names = "pixel", "hdmi"; - dmas = <&dma 17>; - dma-names = "audio-rx"; - status = "disabled"; - }; - usb: usb@7e980000 { compatible = "brcm,bcm2835-usb"; reg = <0x7e980000 0x10000>; @@ -634,36 +475,19 @@ phys = <&usbphy>; phy-names = "usb2-phy"; }; - - v3d: v3d@7ec00000 { - compatible = "brcm,bcm2835-v3d"; - reg = <0x7ec00000 0x1000>; - interrupts = <1 10>; - power-domains = <&pm BCM2835_POWER_DOMAIN_GRAFX_V3D>; - }; - - vc4: gpu { - compatible = "brcm,bcm2835-vc4"; - }; };

clocks { - compatible = "simple-bus"; - #address-cells = <1>; - #size-cells = <0>; - /* The oscillator is the root of the clock tree. */ - clk_osc: clock@3 { + clk_osc: clk-osc { compatible = "fixed-clock"; - reg = <3>; #clock-cells = <0>; clock-output-names = "osc"; clock-frequency = <19200000>; };

- clk_usb: clock@4 { + clk_usb: clk-usb { compatible = "fixed-clock"; - reg = <4>; #clock-cells = <0>; clock-output-names = "otg"; clock-frequency = <480000000>; 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;" diff --git a/include/dt-bindings/clock/bcm2835.h b/include/dt-bindings/clock/bcm2835.h index 2cec01f9689..b60c03430cf 100644 --- a/include/dt-bindings/clock/bcm2835.h +++ b/include/dt-bindings/clock/bcm2835.h @@ -58,3 +58,5 @@ #define BCM2835_CLOCK_DSI1E 48 #define BCM2835_CLOCK_DSI0P 49 #define BCM2835_CLOCK_DSI1P 50 + +#define BCM2711_CLOCK_EMMC2 51

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 ---

Changes in v7: - Use 'empty' instead of 'fake'

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

This uses QEMU virt which creates its own devicetree.

Add an empty version of this file, so that we can at least build this board when devicetrees are required.

Signed-off-by: Simon Glass sjg@chromium.org ---

Changes in v7: - Switch to using an empty file for qemu virt

arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/qemu-ppce500.dts | 10 ++++++++++ configs/qemu-ppce500_defconfig | 1 + 3 files changed, 12 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..e88e09e1796 --- /dev/null +++ b/arch/powerpc/dts/qemu-ppce500.dts @@ -0,0 +1,10 @@ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +/* + * Empty device tree for qemu-ppce400 + * + * Copyright 2021 Google LLC + */ +/dts-v1/; + +/ { +}; 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