[PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so there are only three ways to obtain a devicetree:
- OF_SEPARATE - the normal way, where the devicetree is built and appended to U-Boot - OF_EMBED - for development purposes, the devicetree is embedded in the ELF file (also used for EFI) - OF_BOARD - the board figures it out on its own
The last one is currently set up so that no devicetree is needed at all in the U-Boot tree. Most boards do provide one, but some don't. Some don't even provide instructions on how to boot on the board.
The problems with this approach are documented in another patch in this series: "doc: Add documentation about devicetree usage"
In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board can obtain its devicetree at runtime, even it is has a devicetree built in U-Boot. This is because U-Boot may be a second-stage bootloader and its caller may have a better idea about the hardware available in the machine. This is the case with a few QEMU boards, for example.
So it makes no sense to have OF_BOARD as a 'choice'. It should be an option, available with either OF_SEPARATE or OF_EMBED.
This series makes this change, adding various missing devicetree files (and placeholders) to make the build work.
Note: If board maintainers are able to add their own patch to add the files, some patches in this series can be dropped.
It also provides a few qemu clean-ups discovered along the way.
Note: This breaks the qemu-riscv64_spl test, which still needs investigation.
[1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sj...
Changes in v5: - Bring into the OF_BOARD series - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed - Refer to the 'control' DTB in the first paragraph - Use QEMU instead of qemu - Merge RISC-V and ARM patches since they are similar - Add new patches to clean up fdtdec_setup() and surrounds
Changes in v3: - Clarify the 'bug' refered to at the top - Reword 'This means that there' paragraph to explain U-Boot-specific things - Move to doc/develop/devicetree now that OF_CONTROL is in the docs
Changes in v2: - Fix typos per Sean (thank you!) and a few others - Add a 'Use of U-Boot /config node' section - Drop mention of dm-verity since that actually uses the kernel cmdline - Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph) - Expand a bit on the reason why the 'Current situation' is bad - Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...' - Expand on why we should have rules for other projects in 'Devicetree in another project' - Add a comment as to why devicetree in U-Boot is not 'bad design' - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' - Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1 - Add 'Why does U-Boot have its nodes and properties?' - Add 'Why not have two devicetrees?'
Ilias Apalodimas (1): sandbox: Remove OF_HOSTFILE
Simon Glass (25): doc: Add documentation about devicetree usage arm: qemu: Mention -nographic in the docs arm: riscv: qemu: Explain how to extract the generated dt arm: qemu: Add a devicetree file for qemu_arm arm: qemu: Add a devicetree file for qemu_arm64 riscv: qemu: Add devicetree files for qemu_riscv32/64 arm: rpi: Add a devicetree file for rpi_4 arm: vexpress: Add a devicetree file for juno arm: xenguest_arm64: Add a fake devicetree file arm: octeontx: Add a fake devicetree file arm: xilinx_versal_virt: Add a devicetree file arm: bcm7xxx: Add a devicetree file arm: qemu-ppce500: Add a devicetree file arm: highbank: Add a fake devicetree file fdt: Make OF_BOARD a bool option Drop CONFIG_BINMAN_STANDALONE_FDT doc: Update info on devicetree update fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() fdt: Drop #ifdefs with MULTI_DTB_FIT fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() fdt: Drop #ifdef around board_fdt_blob_setup() fdt: Use if() for fdtcontroladdr check fdt: Drop OF_CONTROL check in fdtdec_setup() fdt: Drop remaining preprocessor macros in fdtdec_setup() fdt: Don't call board_fdt_blob_setup() without OF_BOARD
Makefile | 7 +- arch/arm/dts/Makefile | 20 +- arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 +++++++++++++++++++++ arch/arm/dts/bcm7xxx.dts | 15 + arch/arm/dts/highbank.dts | 14 + arch/arm/dts/juno-r2.dts | 1038 +++++++++++ arch/arm/dts/octeontx.dts | 14 + arch/arm/dts/qemu-arm.dts | 402 +++++ arch/arm/dts/qemu-arm64.dts | 381 ++++ arch/arm/dts/xenguest-arm64.dts | 15 + arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/qemu-ppce500.dts | 264 +++ arch/riscv/dts/Makefile | 2 +- arch/riscv/dts/qemu-virt.dts | 8 - arch/riscv/dts/qemu-virt32.dts | 217 +++ arch/riscv/dts/qemu-virt64.dts | 217 +++ arch/sandbox/cpu/cpu.c | 21 +- arch/sandbox/include/asm/u-boot-sandbox.h | 8 - configs/bcm7260_defconfig | 1 + configs/bcm7445_defconfig | 1 + configs/highbank_defconfig | 2 +- configs/octeontx2_95xx_defconfig | 1 + configs/octeontx2_96xx_defconfig | 1 + configs/octeontx_81xx_defconfig | 1 + configs/octeontx_83xx_defconfig | 1 + configs/qemu-ppce500_defconfig | 2 + configs/qemu-riscv32_defconfig | 1 + configs/qemu-riscv32_smode_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 4 +- configs/qemu-riscv64_defconfig | 1 + configs/qemu-riscv64_smode_defconfig | 1 + configs/qemu-riscv64_spl_defconfig | 3 +- configs/qemu_arm64_defconfig | 1 + configs/qemu_arm_defconfig | 1 + configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + configs/sandbox64_defconfig | 2 +- configs/sandbox_defconfig | 2 +- configs/sandbox_flattree_defconfig | 2 +- configs/sandbox_noinst_defconfig | 2 +- configs/sandbox_spl_defconfig | 2 +- configs/tools-only_defconfig | 2 +- configs/vexpress_aemv8a_juno_defconfig | 1 + configs/xenguest_arm64_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + doc/board/emulation/qemu-arm.rst | 10 +- doc/board/emulation/qemu-riscv.rst | 3 + doc/develop/devicetree/control.rst | 7 +- doc/develop/devicetree/dt_qemu.rst | 48 + doc/develop/devicetree/dt_update.rst | 498 ++++++ doc/develop/devicetree/index.rst | 2 + dts/Kconfig | 37 +- include/asm-generic/global_data.h | 8 + include/fdtdec.h | 21 +- lib/fdtdec.c | 116 +- scripts/Makefile.spl | 4 +- tools/binman/binman.rst | 20 - 59 files changed, 5560 insertions(+), 164 deletions(-) create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts create mode 100644 arch/arm/dts/bcm7xxx.dts create mode 100644 arch/arm/dts/highbank.dts create mode 100644 arch/arm/dts/juno-r2.dts create mode 100644 arch/arm/dts/octeontx.dts create mode 100644 arch/arm/dts/qemu-arm.dts create mode 100644 arch/arm/dts/qemu-arm64.dts create mode 100644 arch/arm/dts/xenguest-arm64.dts create mode 100644 arch/arm/dts/xilinx-versal-virt.dts create mode 100644 arch/powerpc/dts/qemu-ppce500.dts delete mode 100644 arch/riscv/dts/qemu-virt.dts create mode 100644 arch/riscv/dts/qemu-virt32.dts create mode 100644 arch/riscv/dts/qemu-virt64.dts create mode 100644 doc/develop/devicetree/dt_qemu.rst create mode 100644 doc/develop/devicetree/dt_update.rst
From: Ilias Apalodimas ilias.apalodimas@linaro.org
OF_HOSTFILE is used on sandbox configs only. Although it's pretty unique not a source of any confusions, we are better of having simple config options for the DTB. So let's replace that with the existing OF_BOARD. This will make U-Boot have only three different config options for the DTB origin. - OF_SEPARATE, build separately from U-Boot - OF_BOARD, board specific way of providing the DTB - OF_EMBED embedded in the u-boot binary, but discouraged from being used in production
Signed-off-by: Ilias Apalodimas ilias.apalodimas@linaro.org Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
Makefile | 6 +++--- arch/sandbox/cpu/cpu.c | 21 ++++++++++++--------- arch/sandbox/include/asm/u-boot-sandbox.h | 8 -------- configs/sandbox64_defconfig | 2 +- configs/sandbox_defconfig | 2 +- configs/sandbox_flattree_defconfig | 2 +- configs/sandbox_noinst_defconfig | 2 +- configs/sandbox_spl_defconfig | 2 +- configs/tools-only_defconfig | 2 +- doc/develop/devicetree/control.rst | 7 +++---- dts/Kconfig | 9 --------- lib/fdtdec.c | 5 ----- scripts/Makefile.spl | 4 ++-- 13 files changed, 26 insertions(+), 46 deletions(-)
diff --git a/Makefile b/Makefile index 5194e4dc782..c0ea933cb63 100644 --- a/Makefile +++ b/Makefile @@ -947,7 +947,7 @@ INPUTS-$(CONFIG_BINMAN_STANDALONE_FDT) += u-boot.dtb ifeq ($(CONFIG_SPL_FRAMEWORK),y) INPUTS-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img endif -INPUTS-$(CONFIG_OF_HOSTFILE) += u-boot.dtb +INPUTS-$(CONFIG_SANDBOX) += u-boot.dtb ifneq ($(CONFIG_SPL_TARGET),) INPUTS-$(CONFIG_SPL) += $(CONFIG_SPL_TARGET:"%"=%) endif @@ -1407,7 +1407,7 @@ u-boot-lzma.img: u-boot.bin.lzma FORCE
u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \ $(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin \ - $(if $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb) \ + $(if $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb) \ ,$(UBOOT_BIN)) FORCE $(call if_changed,mkimage) $(BOARD_SIZE_CHECK) @@ -1421,7 +1421,7 @@ MKIMAGEFLAGS_u-boot.itb += -B 0x8
ifdef U_BOOT_ITS u-boot.itb: u-boot-nodtb.bin \ - $(if $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE),dts/dt.dtb) \ + $(if $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX),dts/dt.dtb) \ $(U_BOOT_ITS) FORCE $(call if_changed,mkfitimage) $(BOARD_SIZE_CHECK) diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c index 48636ab6391..bc67a5a5a10 100644 --- a/arch/sandbox/cpu/cpu.c +++ b/arch/sandbox/cpu/cpu.c @@ -291,44 +291,47 @@ void invalidate_dcache_range(unsigned long start, unsigned long stop) { }
-int sandbox_read_fdt_from_file(void) +void *board_fdt_blob_setup(void) { struct sandbox_state *state = state_get_current(); const char *fname = state->fdt_fname; - void *blob; + void *blob = NULL; loff_t size; int err; int fd;
+ printf("SETUP BLOB\n"); blob = map_sysmem(CONFIG_SYS_FDT_LOAD_ADDR, 0); if (!state->fdt_fname) { err = fdt_create_empty_tree(blob, 256); if (!err) goto done; printf("Unable to create empty FDT: %s\n", fdt_strerror(err)); - return -EINVAL; + goto fail; }
err = os_get_filesize(fname, &size); if (err < 0) { printf("Failed to file FDT file '%s'\n", fname); - return err; + goto fail; } fd = os_open(fname, OS_O_RDONLY); if (fd < 0) { printf("Failed to open FDT file '%s'\n", fname); - return -EACCES; + goto fail; } + if (os_read(fd, blob, size) != size) { os_close(fd); - return -EIO; + printf("Failed to read file '%s'\n", fname); + goto fail; } os_close(fd);
done: - gd->fdt_blob = blob; - - return 0; + return blob; +fail: + return NULL; }
ulong timer_get_boot_us(void) diff --git a/arch/sandbox/include/asm/u-boot-sandbox.h b/arch/sandbox/include/asm/u-boot-sandbox.h index 73b1897191d..56dc13c3eb1 100644 --- a/arch/sandbox/include/asm/u-boot-sandbox.h +++ b/arch/sandbox/include/asm/u-boot-sandbox.h @@ -76,14 +76,6 @@ int pci_unmap_physmem(const void *addr, unsigned long len, */ void sandbox_set_enable_pci_map(int enable);
-/** - * sandbox_read_fdt_from_file() - Read a device tree from a file - * - * Read a device tree file from a host file and set it up for use as the - * control FDT. - */ -int sandbox_read_fdt_from_file(void); - /** * sandbox_reset() - reset sandbox * diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig index df9633d762a..931d7a88ff6 100644 --- a/configs/sandbox64_defconfig +++ b/configs/sandbox64_defconfig @@ -88,7 +88,7 @@ CONFIG_MAC_PARTITION=y CONFIG_AMIGA_PARTITION=y CONFIG_OF_CONTROL=y CONFIG_OF_LIVE=y -CONFIG_OF_HOSTFILE=y +CONFIG_OF_BOARD=y CONFIG_ENV_IS_NOWHERE=y CONFIG_ENV_IS_IN_EXT4=y CONFIG_ENV_EXT4_INTERFACE="host" diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 9a462cb57c4..4c53dbdd5bc 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -113,7 +113,7 @@ CONFIG_MAC_PARTITION=y CONFIG_AMIGA_PARTITION=y CONFIG_OF_CONTROL=y CONFIG_OF_LIVE=y -CONFIG_OF_HOSTFILE=y +CONFIG_OF_BOARD=y CONFIG_ENV_IS_NOWHERE=y CONFIG_ENV_IS_IN_EXT4=y CONFIG_ENV_EXT4_INTERFACE="host" diff --git a/configs/sandbox_flattree_defconfig b/configs/sandbox_flattree_defconfig index 11015744e7a..4ddb39147e9 100644 --- a/configs/sandbox_flattree_defconfig +++ b/configs/sandbox_flattree_defconfig @@ -69,7 +69,7 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_MAC_PARTITION=y CONFIG_AMIGA_PARTITION=y CONFIG_OF_CONTROL=y -CONFIG_OF_HOSTFILE=y +CONFIG_OF_BOARD=y CONFIG_ENV_IS_NOWHERE=y CONFIG_ENV_IS_IN_EXT4=y CONFIG_ENV_EXT4_INTERFACE="host" diff --git a/configs/sandbox_noinst_defconfig b/configs/sandbox_noinst_defconfig index b3584563d24..2902492060e 100644 --- a/configs/sandbox_noinst_defconfig +++ b/configs/sandbox_noinst_defconfig @@ -88,7 +88,7 @@ CONFIG_MAC_PARTITION=y CONFIG_AMIGA_PARTITION=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y -CONFIG_OF_HOSTFILE=y +CONFIG_OF_BOARD=y CONFIG_SPL_OF_PLATDATA=y CONFIG_ENV_IS_NOWHERE=y CONFIG_ENV_IS_IN_EXT4=y diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig index 73cf5dd2b04..2f8d297cedf 100644 --- a/configs/sandbox_spl_defconfig +++ b/configs/sandbox_spl_defconfig @@ -89,7 +89,7 @@ CONFIG_MAC_PARTITION=y CONFIG_AMIGA_PARTITION=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y -CONFIG_OF_HOSTFILE=y +CONFIG_OF_BOARD=y CONFIG_SPL_OF_PLATDATA=y CONFIG_SPL_OF_PLATDATA_INST=y CONFIG_ENV_IS_NOWHERE=y diff --git a/configs/tools-only_defconfig b/configs/tools-only_defconfig index d0e34cb7fa8..da4f5901f07 100644 --- a/configs/tools-only_defconfig +++ b/configs/tools-only_defconfig @@ -16,7 +16,7 @@ CONFIG_AVB_BUF_SIZE=0x8192 CONFIG_BOOTP_DNS2=y # CONFIG_CMD_DATE is not set CONFIG_OF_CONTROL=y -CONFIG_OF_HOSTFILE=y +CONFIG_OF_BOARD=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_BOOTP_SEND_HOSTNAME=y CONFIG_IP_DEFRAG=y diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index e84dfb6677a..0e6f85d5af1 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -108,10 +108,9 @@ If CONFIG_OF_BOARD is defined, a board-specific routine will provide the devicetree at runtime, for example if an earlier bootloader stage creates it and passes it to U-Boot.
-If CONFIG_OF_HOSTFILE is defined, then it will be read from a file on -startup. This is only useful for sandbox. Use the -d flag to U-Boot to -specify the file to read, -D for the default and -T for the test devicetree, -used to run sandbox unit tests. +If CONFIG_SANDBOX is defined, then it will be read from a file on +startup. Use the -d flag to U-Boot to specify the file to read, -D for the +default and -T for the test devicetree, used to run sandbox unit tests.
You cannot use more than one of these options at the same time.
diff --git a/dts/Kconfig b/dts/Kconfig index 90c7a1c5f49..99a7a8b0338 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -115,20 +115,11 @@ config OF_EMBED
config OF_BOARD bool "Provided by the board (e.g a previous loader) at runtime" - depends on !SANDBOX help If this option is enabled, the device tree will be provided by the board at runtime if the board supports it, instead of being bundled with the image.
-config OF_HOSTFILE - bool "Host filed DTB for DT control" - depends on SANDBOX - help - If this option is enabled, DTB will be read from a file on startup. - This is only useful for Sandbox. Use the -d flag to U-Boot to - specify the file to read. - endchoice
config DEFAULT_DEVICE_TREE diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 959b337cdc8..688741108c7 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -1608,11 +1608,6 @@ int fdtdec_setup(void) # elif defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE) /* Allow the board to override the fdt address. */ gd->fdt_blob = board_fdt_blob_setup(); -# elif defined(CONFIG_OF_HOSTFILE) - if (sandbox_read_fdt_from_file()) { - puts("Failed to read control FDT\n"); - return -1; - } # endif # ifndef CONFIG_SPL_BUILD /* Allow the early environment to override the fdt address */ diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index 6f26eb1fa1f..9f93c178943 100644 --- a/scripts/Makefile.spl +++ b/scripts/Makefile.spl @@ -297,10 +297,10 @@ endif
# Build the .dtb file if needed # - OF_REAL is enabled -# - we have either OF_SEPARATE or OF_HOSTFILE +# - we have OF_SEPARATE build_dtb := ifneq ($(CONFIG_$(SPL_TPL_)OF_REAL),) -ifeq ($(CONFIG_OF_SEPARATE)$(CONFIG_OF_HOSTFILE),y) +ifeq ($(CONFIG_OF_SEPARATE),y) build_dtb := y endif endif
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 v5: - Bring into the OF_BOARD series - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed - Refer to the 'control' DTB in the first paragraph - Use QEMU instead of qemu
Changes in v3: - Clarify the 'bug' refered to at the top - Reword 'This means that there' paragraph to explain U-Boot-specific things - Move to doc/develop/devicetree now that OF_CONTROL is in the docs
Changes in v2: - Fix typos per Sean (thank you!) and a few others - Add a 'Use of U-Boot /config node' section - Drop mention of dm-verity since that actually uses the kernel cmdline - Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph) - Expand a bit on the reason why the 'Current situation' is bad - Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...' - Expand on why we should have rules for other projects in 'Devicetree in another project' - Add a comment as to why devicetree in U-Boot is not 'bad design' - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' - Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1 - Add 'Why does U-Boot have its nodes and properties?' - Add 'Why not have two devicetrees?'
doc/develop/devicetree/dt_update.rst | 556 +++++++++++++++++++++++++++ doc/develop/devicetree/index.rst | 1 + 2 files changed, 557 insertions(+) create mode 100644 doc/develop/devicetree/dt_update.rst
diff --git a/doc/develop/devicetree/dt_update.rst b/doc/develop/devicetree/dt_update.rst new file mode 100644 index 00000000000..3d4902e3592 --- /dev/null +++ b/doc/develop/devicetree/dt_update.rst @@ -0,0 +1,556 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Updating the devicetree +======================= + +U-Boot uses devicetree for runtime configuration and storing required blobs or +any other information it needs to operate. This is called the 'control' +devicetree since it controls U-Boot. It is possible to update the control +devicetree separately from actually building U-Boot. This provides a good degree +of control and flexibility for firmware that uses U-Boot in conjunction with +other project. + +There are many reasons why it is useful to modify the devicetree after building +it: + +- Configuration can be changed, e.g. which UART to use +- A serial number can be added +- Public keys can be added to allow image verification +- Console output can be changed (e.g. to select serial or vidconsole) + +This section describes how to work with devicetree to accomplish your goals. + +See also :doc:`../devicetree/control` for a basic summary of the available +features. + + +Devicetree source +----------------- + +Every board in U-Boot must include a devicetree sufficient to build and boot +that board on suitable hardware (or emulation). This is specified using the +`CONFIG DEFAULT_DEVICE_TREE` option. + + +Current situation (October 2021) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty, +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an enormous +amount of confusion and some wasted effort. This was not intended. Support for +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. + +Some of the problems created are: + +- It is not obvious that the devicetree is coming from another project + +- There is no way to see even a sample devicetree for these platform in U-Boot, + so it is hard to know what is going on, e.g. which devices are typically + present + +- The other project may not provide a way to support U-Boot's requirements for + devicetree, such as the /config node. Note: On the U-Boot mailing linst, this + was only discovered after weeks of discussion and confusion + +- For QEMU specifically, consulting two QEMU source files is required, for which + there are no references in U-Boot documentation. The code is generating a + devicetree, but it is not clear what controls affect this generation. + +Specifically on the changes in U-Bootm `CONFIG_OF_BOARD` was added in +rpi_patch_ for Raspberry Pi, which does have an in-tree devicetree, but this +feature has since been used for boards that don't + +Once this bug is fixed, CONFIG_OF_BOARD will override (at runtime) the +evicetree suppled with U-Boot, but will otherwise use CONFIG_OF_SEPARATE for the +in-tree build. So these two will become options, moving out of the 'choice' in +`dts/Kconfig`. + +This means that there is a basic devicetree build in the U-Boot tree, for +build-testing, consistency and documentation purposes, but at runtime U-Boot can +accept its devicetree from another source. The in-tree devicetree may contain +U-Boot-specific features (in u-boot*.dtsi files) and this may prove useful for +the other project, so it can ensure that U-Boot functions correctly and supports +all its expected features. + +To be clear, while U-Boot has its own copy of the devicetree source for each +board, this must match the Linux source, perhaps with some u-boot.dtsi +additions. The intent here is not to create a separate binding, just to provide +a representative devicetree in U-Boot. + +Offending boards are: + +- rpi_4 and rpi_4_32b (other rpi boards do have an in-tree devicetree) +- qemu_arm64 +- qemu_arm +- qemu-ppce500 +- qemu-riscv32 +- qemu-riscv32_smode +- qemu-riscv64 +- qemu-riscv64_smode + +All of these need to have a devicetree added in-tree. This is targeted to be +fixed in the 2022.01 release. + + +Building the devicetree +----------------------- + +U-Boot automatically builds the devicetree for a board, from the +`arch/<arch>/dts` directory. The Makefile in those directories has rules for +building devicetree files. It is preferable to avoid target-specific rules in +those files: i.e. all boards for a particular SoC should be built at once, +where practical. Apart from simplifying the Makefile, this helps to efficiently +(and immediately) ensure that changes in one board's DT do not break others that +are related. Building devicetrees is fast, so performance is seldom a concern +here. + + +Overriding the default devicetree +--------------------------------- + +When building U-Boot, the `DEVICE_TREE` environment variable allows the +default devicetree file to be overridden at build time. This can be useful if +modifications have to be made to the in-tree devicetree file, for the benefit +of a downstream build system. Note that the in-tree devicetree must be +sufficient to build and boot, so this is not a way to bypass that requirement. + + +Modifying the devicetree after building +--------------------------------------- + +While it is generally painful and hacky to modify the code or rodata of a +program after it is built, in many cases it is useful to do so, e.g. to add +configuration information like serial numbers, enabling/disabling features, etc. + +Devicetree provides a very nice solution to these problems since it is +structured data and it is relatively easy to change it, even in binary form +(see fdtput). + +U-Boot takes care that the devicetree is easily accessible after the build +process. In fact it is placed in a separate file called `u-boot.dtb`. If the +build system wants to modify or replace that file, it can do so. Then all that +is needed is to run `binman update` to update the file inside the image. If +binman is not used, then `u-boot-nodtb.bin` and the new `u-boot.dtb` can simply +be concatenated to achieve the desired result. U-Boot happily copes with the +devicetree growing or shrinking. + +The `u-boot.bin` image contains both pieces. While it is possible to locate the +devicetree within the image using the signature at the start of the file, this +is a bit messy. + +This is why `CONFIG_OF_SEPARATE` should always be used when building U-Boot. +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot ELF +image as rodata, meaning that it is hard to find it and it cannot increase in +size. + +When modifying the devicetree, the different cases to consider are as follows: + +- CONFIG_OF_SEPARATE + This is easy, described above. Just change, replace or rebuild the + devicetree so it suits your needs, then rerun binman or redo the `cat` + operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb` + +- CONFIG_OF_EMBED + This is tricky, since the devicetree cannot easily be located. If the EFL + file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can be + examined to find it. While it is possible to contract the file, it is not + possible to expand the file since that would involve re-linking + +- CONFIG_OF_BOARD + This is a board-specific situation, so needs to be considered on a + case-by-case base. The devicetree must be modified so that the correct + one is provided to U-Boot. How this is done depends entirely on the + implementation of this option for the board. It might require injecting the + changes into a different project somehow using tooling available there, or + it might involve merging an overlay file at runtime to obtain the desired + result. + + +Use of U-Boot /config node +-------------------------- + +A common problem with firmware is that many builds are needed to deal with the +slight variations between different, related models. For example, one model may +have a TPM and another may not. Devicetree provides an excellent solution to +this problem, in that the devicetree to actually use on a platform can be +injected in the factory based on which model is being manufactured at the time. + +A related problem causing build proliferation is dealing with the differences +between development firmware, developer-friendly firmware (e.g. with all +security features present but with the ability to access the command line), +test firmware (which runs tests used in the factory), final production firmware +(before signing), signed firmware (where the signatures have been inserted) and +the like. Ideally all or most of these should use the same U-Boot build, with +just some options to determine the features available. For example, being able +to control whether the UART console or JTAG are available, on any image, is a +great debugging aid. + +When the firmware consists of multiple parts, it is helpful that all operate +the same way at runtime, regardless of how they were built. This can be achieved +by passing the runtime configuration (e.g. 'enable UART console) along the chain +through each firmware stage. It is frustrating to have to replicate a bug on +production firmware which does happen on developer firmware, because they are +completely different builds. + +The /config node provides useful functionality for this. It allows the different +controls to be 'factored out' of the U-Boot binary, so they can be controlled +separately from the initial source-code build. The node can be easily updated by +a build or factory tool and can control various features in U-Boot. It is +similar in concept to a Kconfig option, except that it can be changed after +U-Boot is built. + +The /config node is similar in concept to the `/chosen node`_ except that it is +for passing information *into* firmware instead of from firmware to the +Operating System. Also, while Linux has a (sometimes extremely long) command +line, U-Boot does not support this. The devicetree provides a more structured +approach in any case. + + +Devicetree in another project +----------------------------- + +In some cases U-Boot receive its devicetree at runtime from a program that calls +it. For example ARM's Trusted Firmware A (`TF-A`_) may have a devicetree that it +passes to U-Boot. This overrides any devicetree build by U-Boot. When packaging +the firmware, the U-Boot devicetree may in fact be left out if it can be +guaranteed that it will receive one from another project. + +In this case, the devicetree in the other project must track U-Boot's use of +device tree, for the following reasons: + +- U-Boot only has one devicetree. See `Why not have two devicetrees?`_. +- For a consistent firmware build, decisions made in early stages should be + communicated to later ones at runtime. For example, if the serial console is + enabled in an early stage, it should be enabled in U-Boot too. +- U-Boot is quite capable of managing its own copy of the devicetree. If + another project wants to bypass this (often for good reason), it is reasonable + that it should take on the (fairly small) requirements that U-Boot features + that rely on devicetree are still available +- The point here is not that *U-Boot needs this extra node*, or *U-Boot needs + to have this public key*. These features are present in U-Boot in service of + the entire firmware system. If the U-Boot features are used, but cannot be + supported in the normal way, then there is pressure to implement these + features in other ways. In the end, we would have a different mechanism for + every other project that uses U-Boot. This introduces duplicate ways of doing + the same thing, needlessly increases the complexity of the U-Boot source code, + forces authors to consider parallel implementations when writing new features, + makes U-Boot harder to test, complicates documentation and confuses the + runtime flow of U-Boot. If every board did things its own way rather than + contributing to the common code, U-Boot would lose a lot of its cross-platform + value. + +The above does not indicate *bad design* within U-Boot. Devicetree is a core +component of U-Boot and U-Boot makes use of it to the full. It solves a myriad +of problems that would otherwise need their own special C struct, binary format, +special property, tooling for viewing and updating, etc. + +Specifically, the other project must provide a way to add configuration and +other information to the devicetree for use by U-Boot, such as the /config node. +Note that the U-Boot in-tree devicetree source must be sufficient to build and +boot, so this is not a way to bypass that requirement. + +If binman is used, the devicetree source in U-Boot must contain the binman +definition so that a valid image can be build. This helps people discover what +other firmware components are needed and seek out appropriate documentation. + +If verified boot is used, the project must provide a way to inject a public key, +certificate or other material into the U-Boot devicetree so that it is available +to U-Boot at runtime. See `Signing with U-Boot devicetree`_. This may be +through tooling in the project itself or by making use of U-Boot's tooling. + + +Devicetree generated on-the-fly in another project +-------------------------------------------------- + +In some rare cases, another project may wish to create a devicetree for U-Boot +entirely on-the-fly, then pass it to U-Boot at runtime. The only known example +of this at the time of writing (2021) is QEMU, for ARM (`QEMU ARM`_) and +RISC-V (`QEMU RISC-V`_). + +In effect, when the board boots, U-Boot is *downstream* of the other project. +It is entirely reliant on that project for its correct operation. + +This does not mean to imply that the other project is creating its own, +incompatible devicetree. In fact QEMU generates a valid devicetree which is +suitable for both U-Boot and Linux. It is quite normal for a devicetree to be +present in flash and be made available to U-Boot at runtime. What matters is +where the devicetree comes from. If the other project builds a devicetree for +U-Boot then it needs to support adding the things needed by U-Boot features. +Without them, for example: + +- U-Boot may not boot because too many devices are enabled before relocation +- U-Boot may not have access to the developer or production public keys used for + signing +- U-Boot may not support controlling whether the console is enabled +- U-Boot may not be know which MMC device to boot from +- U-Boot may not be able to find other firmware components that it needs to load + +Normally, supporting U-Boot's features is trivial, since the devicetree compiler +(dtc) can compile the source, including any U-Boot pieces. So the burden is +extremely low. + +In this case, the devicetree in the other project must track U-Boot's use of +device tree, so that it remains compatible. See `Devicetree in another project`_ +for reasons why. + +If a particular version of the project is needed for a particular version of +U-Boot, that must be documented in both projects. + +Further, it must provide a way to add configuration and other information to +the devicetree for use by U-Boot, such as the `/config` node and the tags used +by driver model. Note that the U-Boot in-tree devicetree must be sufficient to +build and boot, so this is not a way to bypass that requirement. + +More specifically, tooling or command-line arguments must provide a way to +add a `/config` node or items within that node, so that U-Boot can receive a +suitable configuration. It must provide a way of adding `u-boot,dm-...` tags for +correct operation of driver model. These options can then be used as part of the +build process, which puts the firmware image together. For binman, a way must be +provided to add the binman definition into the devicetree in the same way. + +One way to do this is to allow a .dtsi file to be merged in with the generated +devicetree. + +Note that the burden goes both ways. If a new feature is added to U-Boot which +needs support in another project, then the author of the U-Boot patch must add +any required support to the other project. + + +Passing the devicetree through to Linux +--------------------------------------- + +Ideally U-Boot and Linux use the same devicetree source, even though it is +hosted in separate projects. U-Boot adds some extra pieces, such as the +`config/` node and tags like `u-boot,dm-spl`. Linux adds some extra pieces, such +as `linux,default-trigger` and `linux,code`. This should not interfere with +each other. + +In principle it is possible for U-Boot's control devicetree to be passed to +Linux. This is, after all, one of the goals of devicetree and the original +Open Firmware project, to have the firmware provide the hardware description to +the Operating System. + +For boards where this approach is used, care must be taken. U-Boot typically +needs to 'fix up' the devicetree before passing it to Linux, e.g. to add +information about the memory map, about which serial console is used, provide +the kernel address space layout randomization (KASLR) seed or select whether the +console should be silenced for a faster boot. + +Fix-ups involve modifying the devicetree. If the control devicetree is used, +that means the control devicetree could be modified, while U-Boot is using it. +Removing a device and reinserting it can cause problems if the devicetree offset +has changed, for example, since the device will be unable to locates its +devicetree properties at the expected devicetree offset, which is a fixed +integer. + +To deal with this, it is recommended to employ one or more of the following +approaches: + +- Make a copy of the devicetree and 'fix up' the copy, leaving the control + devicetree alone +- Enable `CONFIG_OF_LIVE` so that U-Boot makes its own copy of the devicetree + during relocation; fixups then happen on the original flat tree +- Ensure that fix-ups happen after all loading has happened and U-Boot has + completed image verification + +In practice,the last point is typically observed, since boot_prep_linux() is +called just before jumping to Linux, long after signature verification, for +example. But it is important to make sure that this line is not blurred, +particularly if untrusted user data is involved. + + +Devicetree use cases that must be supported +------------------------------------------- + +Regardless of how the devicetree is provided to U-Boot at runtime, various +U-Boot features must be fully supported. This section describes some of these +features and the implications for other projects. + +If U-Boot uses its own in-tree devicetree these features are supported +automatically. + + +Signing with U-Boot devicetree +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +U-Boot supports signing a payload so that it can be verified to have been +created by a party owning a private key. This is called verified boot in U-Boot +(see doc/uImage.FIT/verified-boot.txt). + +Typically this works by creating a FIT and then running the `mkimage` tool to +add signatures for particular images. As part of this process, `mkimage` writes +a public key to the U-Boot devicetree, although this can be done separately. +See fdt_add_pubkey_ for patches for a suitable tool, for example. + +As with all configuration information, if another project is providing the +devicetree to U-Boot, it must provide a way to add this public key into the +devicetree it passes to U-Boot. This could be via a tooling option, making use +of `mkimage`, or allowing a .dtsi file to be merged in with what is generated in +the other project. + + +Providing the binman image definition +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In complex systems U-Boot must locate and make use of other firmware components, +such as images for the user interface, files containing peripheral firmware, +multiple copies of U-Boot for use with A/B boot, etc. U-Boot uses +:doc:`Binman <../package/binman>` as a standard way of putting an image +together. + +Typically this works by running binman with the devicetree as an input, to +create the file image. Binman then outputs an updated devicetree which is +packed in the firmware image, so U-Boot can access the binman definition and +locate all the components. + +As with all configuration information, if another project is providing the +devicetree to U-Boot, it must provide a way to add this binman definition into +the devicetree it passes to U-Boot. This could be via a tooling option, making +use of `binman`, or alowing a .dtsi file to be merged in with what is generated +in the other project. + + +Protecting the devicetree +------------------------- + +U-Boot relies heavily on devicetree for correct operation. A corrupt or invalid +device can cause U-Boot to fail to start, behave incorrectly, crash (e.g. if +`CONFIG_OF_LIBFDT_ASSUME_MASK` is adjusted, or fail to boot an Operating System. +Within U-Boot, the devicetree is as important as any other part of the source +code. At ruuntime, the devicetree can be considered to be structured rodata. + +With secure systems, care must be taken that the devicetree is valid: + +- If the code / rodata has a hash or signature, the devicetree should also, if + they are packaged separately. +- If the code / rodata is write-protected when running, the devicetree should be + also. Note that U-Boot relocates its code and devicetree, so this is not as + simple as it sounds. U-Boot must write-protect these items after relocating. + + +Why does U-Boot have its nodes and properties? +---------------------------------------------- + +See also :doc:`../devicetree/intro`. + +There has been pushback at the concept that U-Boot dares have its own nodes and +properties in the devicetree. + +Apart from these nodes and properties, U-Boot uses the same bindings as Linux. +A `u-boot.dtsi` file helps to keep U-Boot-specific changes in separate files, +making it easier to keep devicetree source files in U-Boot in sync with Linux. + +As a counter-example, the Zephyr OS project takes a different approach. It uses +entirely different bindings, in general, making no effort to sync devicetree +source files with Linux. U-Boot strives to be compatible with Linux in a number +of ways, such as source code style and common APIs, to aid porting of code +between the projects. Devicetree is another way where U-Boot and Linux follow a +similar approach. + +Fundamentally, the idea that U-Boot cannot have its own tags flies in the face +of the devicetree specification (see dtspec_), which says: + + Nonstandard property names should specify a **unique string prefix**, such as + a stock ticker symbol, identifying the name of the company **or organization** + that defined the property. Examples: + + - fsl,channel-fifo-len + - ibm,ppc-interrupt-server#s + - **linux**,network-index + +It is also fundamentally unbalanced. Linux has many tags of its own (some 36 in +version 5.13) and at least one Linux-specific node, even if you ignore things +like flash partitions which clearly provide configuration information to Linux. + +Practically speaking there are many reasons why U-Boot has its own nodes and +properties. Some examples: + +- Binding every device before relocation even if it won't be used, consumes time + and memory: tags on each node can specify which are needed in SPL or before + relocation. Linux has no such constraints. + +- Requiring the full clock tree to be up and running just to get the debug UART + running is inefficient. It is also and self-defeating, since if that much + code is working properly, you probably don't need the debug UART. A devicetree + property to provide the UART input-clock frequency is a simple solution. + +- U-Boot does not have a user space to provide policy and configuration. It + cannot do what Linux does and run programs and look up filesystems to figure + out how to boot. + + +Why not have two devicetrees? +----------------------------- + +Setting aside the argument for restricting U-Boot from having its own nodes and +properties, another idea proposed is to have two devicetrees, one for the +U-Boot-specific bits (here called `special`) and one for everything else (here +called `linux`). + +On the positive side, it might quieten the discussion alluded to in the section +above. But there are many negatives to consider and many open questions to +resolve. + +- **Bindings** - Presumably the special devicetree would have its own bindings. + It would not be necessary to put a `u-boot,` prefix on anything. People coming + across the devicetree source would wonder how it fits in with the Linux + devicetree. + +- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This + would need to be expanded to support two trees. Features which need to access + both (such as a device driver which reads the special devicetree to get some + configuration info) could become quite confusing to read and write. + +- **Merging** - Can the two devicetree be merged if a platform desires it? If + so, how is this managed in tooling? Does it happen during the build, in which + case they are not really separate at all. Or does U-Boot merge them at + runtime, in which case this adds time and memory? + +- **Efficiency** - A second device tree adds more code and more code paths. It + requires that both be made available to the code in U-Boot, e.g. via a + separate pointer or argument or API. Overall the separation would certainly + not speed up U-Boot, nor decrease its size. + +- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for + U-Boot for a particular board. Would we use these same files for the special + devicetree? + +- **Complexity** - Two devicetrees complicates the build system since it must + build and package them both. Errors must be reported in such a way that it + is obvious which one is failing. + +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model + are currently placed in the nodes they relate to. How would these tags + reference a node that is in a separate devicetree? What extra validation would + be needed? + +- **Storage** - How would the two devicetrees be stored in the image? At present + we simply concatenate the U-Boot binary and the devicetree. We could add the + special devicetree before the Linux one, so two are concatenated, but it is + not pretty. We could use binman to support more complex arrangements, but only + some boards use this at present, so it would be a big change. + +- **API** - How would another project provide two devicetree files to U-Boot at + runtime? Presumably this would just be too painful. But if it doesn't, it + would be unable to configure run-time features of U-Boot during the boot. + +- **Confusion** - No other project has two devicetrees. U-Boot would be in the + unfortunate position of having to describe this fact to new users, along with + the (arguably contrived) reason for the arrangement. + +- **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
Hi Simon,
[...]
+This is why `CONFIG_OF_SEPARATE` should always be used when building U-Boot. +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot ELF +image as rodata, meaning that it is hard to find it and it cannot increase in +size.
+When modifying the devicetree, the different cases to consider are as follows:
+- CONFIG_OF_SEPARATE
- This is easy, described above. Just change, replace or rebuild the
- devicetree so it suits your needs, then rerun binman or redo the `cat`
- operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb`
+- CONFIG_OF_EMBED
- This is tricky, since the devicetree cannot easily be located. If the EFL
- file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can be
- examined to find it. While it is possible to contract the file, it is not
- possible to expand the file since that would involve re-linking
+- CONFIG_OF_BOARD
- This is a board-specific situation, so needs to be considered on a
- case-by-case base. The devicetree must be modified so that the correct
- one is provided to U-Boot. How this is done depends entirely on the
- implementation of this option for the board. It might require injecting the
- changes into a different project somehow using tooling available there, or
- it might involve merging an overlay file at runtime to obtain the desired
- result.
I thought this document was trying to describe the current situation in U-Boot. If so, the current CONFIG_OF_BOARD usage is far from what we have here.
[...]
Regards /Ilias
Hi Ilias,
On Tue, 26 Oct 2021 at 08:06, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
[...]
+This is why `CONFIG_OF_SEPARATE` should always be used when building U-Boot. +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot ELF +image as rodata, meaning that it is hard to find it and it cannot increase in +size.
+When modifying the devicetree, the different cases to consider are as follows:
+- CONFIG_OF_SEPARATE
- This is easy, described above. Just change, replace or rebuild the
- devicetree so it suits your needs, then rerun binman or redo the `cat`
- operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb`
+- CONFIG_OF_EMBED
- This is tricky, since the devicetree cannot easily be located. If the EFL
- file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can be
- examined to find it. While it is possible to contract the file, it is not
- possible to expand the file since that would involve re-linking
+- CONFIG_OF_BOARD
- This is a board-specific situation, so needs to be considered on a
- case-by-case base. The devicetree must be modified so that the correct
- one is provided to U-Boot. How this is done depends entirely on the
- implementation of this option for the board. It might require injecting the
- changes into a different project somehow using tooling available there, or
- it might involve merging an overlay file at runtime to obtain the desired
- result.
I thought this document was trying to describe the current situation in U-Boot. If so, the current CONFIG_OF_BOARD usage is far from what we have here.
Can you be more specific? What is the difference here? Also see the doc update later in the series, after OF_BOARD becomes a bool option.
Regards, SImon
On Tue, 26 Oct 2021 at 18:27, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Tue, 26 Oct 2021 at 08:06, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
[...]
+This is why `CONFIG_OF_SEPARATE` should always be used when building U-Boot. +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot ELF +image as rodata, meaning that it is hard to find it and it cannot increase in +size.
+When modifying the devicetree, the different cases to consider are as follows:
+- CONFIG_OF_SEPARATE
- This is easy, described above. Just change, replace or rebuild the
- devicetree so it suits your needs, then rerun binman or redo the `cat`
- operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb`
+- CONFIG_OF_EMBED
- This is tricky, since the devicetree cannot easily be located. If the EFL
- file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can be
- examined to find it. While it is possible to contract the file, it is not
- possible to expand the file since that would involve re-linking
+- CONFIG_OF_BOARD
- This is a board-specific situation, so needs to be considered on a
- case-by-case base. The devicetree must be modified so that the correct
- one is provided to U-Boot. How this is done depends entirely on the
- implementation of this option for the board. It might require injecting the
- changes into a different project somehow using tooling available there, or
- it might involve merging an overlay file at runtime to obtain the desired
- result.
I thought this document was trying to describe the current situation in U-Boot. If so, the current CONFIG_OF_BOARD usage is far from what we have here.
Can you be more specific? What is the difference here? Also see the doc update later in the series, after OF_BOARD becomes a bool option.
The doc you sent says "devicetree must be modified so that the correct one is provided to U-Boot. By this I assume you mean the 'config/' node etc right? If that's the case this is *not* what is currently happening. We simply replace the entire device tree with whatever was configured.
Regards /Ilias
Regards, SImon
Hi Simon,
On Tue, 26 Oct 2021 at 02:25, Simon Glass sjg@chromium.org wrote:
At present some of the ideas and techniques behind devicetree in U-Boot are assumed, implied or unsaid. Add some documentation to cover how devicetree is build, how it can be modified and the rules about using the various CONFIG_OF_... options.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Marcel Ziswiler marcel.ziswiler@toradex.com
This patch attracted quite a bit of discussion here:
https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-sjg...
I have not included the text suggested by François. While I agree that it would be useful to have an introduction in this space, I do not agree that we should have two devicetrees or that U-Boot should not have its own things in the devicetree, so it is not clear to me what we should actually write.
The 'Devicetree Control in U-Boot' docs were recently merged and these provide some base info, for now.
Changes in v5:
- Bring into the OF_BOARD series
- Rebase to master and drop mention of OF_PRIOR_STAGE, since removed
- Refer to the 'control' DTB in the first paragraph
- Use QEMU instead of qemu
Changes in v3:
- Clarify the 'bug' refered to at the top
- Reword 'This means that there' paragraph to explain U-Boot-specific
things
- Move to doc/develop/devicetree now that OF_CONTROL is in the docs
Changes in v2:
- Fix typos per Sean (thank you!) and a few others
- Add a 'Use of U-Boot /config node' section
- Drop mention of dm-verity since that actually uses the kernel cmdline
- Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph)
- Expand a bit on the reason why the 'Current situation' is bad
- Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...'
- Expand on why we should have rules for other projects in 'Devicetree in another project'
- Add a comment as to why devicetree in U-Boot is not 'bad design'
- Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
- Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1
- Add 'Why does U-Boot have its nodes and properties?'
- Add 'Why not have two devicetrees?'
doc/develop/devicetree/dt_update.rst | 556 +++++++++++++++++++++++++++ doc/develop/devicetree/index.rst | 1 + 2 files changed, 557 insertions(+) create mode 100644 doc/develop/devicetree/dt_update.rst
diff --git a/doc/develop/devicetree/dt_update.rst b/doc/develop/devicetree/dt_update.rst new file mode 100644 index 00000000000..3d4902e3592 --- /dev/null +++ b/doc/develop/devicetree/dt_update.rst @@ -0,0 +1,556 @@ +.. SPDX-License-Identifier: GPL-2.0+
+Updating the devicetree +=======================
+U-Boot uses devicetree for runtime configuration and storing required blobs or +any other information it needs to operate. This is called the 'control' +devicetree since it controls U-Boot. It is possible to update the control +devicetree separately from actually building U-Boot. This provides a good degree +of control and flexibility for firmware that uses U-Boot in conjunction with +other project.
+There are many reasons why it is useful to modify the devicetree after building +it:
+- Configuration can be changed, e.g. which UART to use +- A serial number can be added +- Public keys can be added to allow image verification +- Console output can be changed (e.g. to select serial or vidconsole)
+This section describes how to work with devicetree to accomplish your goals.
+See also :doc:`../devicetree/control` for a basic summary of the available +features.
+Devicetree source +-----------------
+Every board in U-Boot must include a devicetree sufficient to build and boot +that board on suitable hardware (or emulation). This is specified using the +`CONFIG DEFAULT_DEVICE_TREE` option.
+Current situation (October 2021) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty, +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an enormous +amount of confusion and some wasted effort. This was not intended. Support for +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon.
+Some of the problems created are:
+- It is not obvious that the devicetree is coming from another project
+- There is no way to see even a sample devicetree for these platform in U-Boot,
- so it is hard to know what is going on, e.g. which devices are typically
- present
+- The other project may not provide a way to support U-Boot's requirements for
- devicetree, such as the /config node. Note: On the U-Boot mailing
linst, this
- was only discovered after weeks of discussion and confusion
+- For QEMU specifically, consulting two QEMU source files is required, for which
- there are no references in U-Boot documentation. The code is generating
a
- devicetree, but it is not clear what controls affect this generation.
+Specifically on the changes in U-Bootm `CONFIG_OF_BOARD` was added in +rpi_patch_ for Raspberry Pi, which does have an in-tree devicetree, but this +feature has since been used for boards that don't
+Once this bug is fixed, CONFIG_OF_BOARD will override (at runtime) the +evicetree suppled with U-Boot, but will otherwise use CONFIG_OF_SEPARATE for the +in-tree build. So these two will become options, moving out of the 'choice' in +`dts/Kconfig`.
+This means that there is a basic devicetree build in the U-Boot tree, for +build-testing, consistency and documentation purposes, but at runtime U-Boot can +accept its devicetree from another source. The in-tree devicetree may contain +U-Boot-specific features (in u-boot*.dtsi files) and this may prove useful for +the other project, so it can ensure that U-Boot functions correctly and supports +all its expected features.
+To be clear, while U-Boot has its own copy of the devicetree source for each +board, this must match the Linux source, perhaps with some u-boot.dtsi +additions. The intent here is not to create a separate binding, just to provide +a representative devicetree in U-Boot.
+Offending boards are:
+- rpi_4 and rpi_4_32b (other rpi boards do have an in-tree devicetree) +- qemu_arm64 +- qemu_arm +- qemu-ppce500 +- qemu-riscv32 +- qemu-riscv32_smode +- qemu-riscv64 +- qemu-riscv64_smode
+All of these need to have a devicetree added in-tree. This is targeted to be +fixed in the 2022.01 release.
+Building the devicetree +-----------------------
+U-Boot automatically builds the devicetree for a board, from the +`arch/<arch>/dts` directory. The Makefile in those directories has rules for +building devicetree files. It is preferable to avoid target-specific rules in +those files: i.e. all boards for a particular SoC should be built at once, +where practical. Apart from simplifying the Makefile, this helps to efficiently +(and immediately) ensure that changes in one board's DT do not break others that +are related. Building devicetrees is fast, so performance is seldom a concern +here.
+Overriding the default devicetree +---------------------------------
+When building U-Boot, the `DEVICE_TREE` environment variable allows the +default devicetree file to be overridden at build time. This can be useful if +modifications have to be made to the in-tree devicetree file, for the benefit +of a downstream build system. Note that the in-tree devicetree must be +sufficient to build and boot, so this is not a way to bypass that requirement.
+Modifying the devicetree after building +---------------------------------------
+While it is generally painful and hacky to modify the code or rodata of a +program after it is built, in many cases it is useful to do so, e.g. to add +configuration information like serial numbers, enabling/disabling features, etc.
+Devicetree provides a very nice solution to these problems since it is +structured data and it is relatively easy to change it, even in binary form +(see fdtput).
+U-Boot takes care that the devicetree is easily accessible after the build +process. In fact it is placed in a separate file called `u-boot.dtb`. If the +build system wants to modify or replace that file, it can do so. Then all that +is needed is to run `binman update` to update the file inside the image. If +binman is not used, then `u-boot-nodtb.bin` and the new `u-boot.dtb` can simply +be concatenated to achieve the desired result. U-Boot happily copes with the +devicetree growing or shrinking.
+The `u-boot.bin` image contains both pieces. While it is possible to locate the +devicetree within the image using the signature at the start of the file, this +is a bit messy.
+This is why `CONFIG_OF_SEPARATE` should always be used when building U-Boot. +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot ELF +image as rodata, meaning that it is hard to find it and it cannot increase in +size.
+When modifying the devicetree, the different cases to consider are as follows:
+- CONFIG_OF_SEPARATE
- This is easy, described above. Just change, replace or rebuild the
- devicetree so it suits your needs, then rerun binman or redo the `cat`
- operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb`
+- CONFIG_OF_EMBED
- This is tricky, since the devicetree cannot easily be located. If the
EFL
- file is available, then the _dtb_dt_begin and __dtb_dt_end symbols
can be
- examined to find it. While it is possible to contract the file, it is
not
- possible to expand the file since that would involve re-linking
+- CONFIG_OF_BOARD
- This is a board-specific situation, so needs to be considered on a
- case-by-case base. The devicetree must be modified so that the correct
- one is provided to U-Boot. How this is done depends entirely on the
- implementation of this option for the board. It might require
injecting the
- changes into a different project somehow using tooling available
there, or
- it might involve merging an overlay file at runtime to obtain the
desired
- result.
+Use of U-Boot /config node +--------------------------
+A common problem with firmware is that many builds are needed to deal with the +slight variations between different, related models. For example, one model may +have a TPM and another may not. Devicetree provides an excellent solution to +this problem, in that the devicetree to actually use on a platform can be +injected in the factory based on which model is being manufactured at the time.
+A related problem causing build proliferation is dealing with the differences +between development firmware, developer-friendly firmware (e.g. with all +security features present but with the ability to access the command line), +test firmware (which runs tests used in the factory), final production firmware +(before signing), signed firmware (where the signatures have been inserted) and +the like. Ideally all or most of these should use the same U-Boot build, with +just some options to determine the features available. For example, being able +to control whether the UART console or JTAG are available, on any image, is a +great debugging aid.
+When the firmware consists of multiple parts, it is helpful that all operate +the same way at runtime, regardless of how they were built. This can be achieved +by passing the runtime configuration (e.g. 'enable UART console) along the chain +through each firmware stage. It is frustrating to have to replicate a bug on +production firmware which does happen on developer firmware, because they are +completely different builds.
+The /config node provides useful functionality for this. It allows the different +controls to be 'factored out' of the U-Boot binary, so they can be controlled +separately from the initial source-code build. The node can be easily updated by +a build or factory tool and can control various features in U-Boot. It is +similar in concept to a Kconfig option, except that it can be changed after +U-Boot is built.
+The /config node is similar in concept to the `/chosen node`_ except that it is +for passing information *into* firmware instead of from firmware to the +Operating System. Also, while Linux has a (sometimes extremely long) command +line, U-Boot does not support this. The devicetree provides a more structured +approach in any case.
+Devicetree in another project +-----------------------------
+In some cases U-Boot receive its devicetree at runtime from a program that calls +it. For example ARM's Trusted Firmware A (`TF-A`_) may have a devicetree that it +passes to U-Boot. This overrides any devicetree build by U-Boot. When packaging +the firmware, the U-Boot devicetree may in fact be left out if it can be +guaranteed that it will receive one from another project.
+In this case, the devicetree in the other project must track U-Boot's use of +device tree, for the following reasons:
+- U-Boot only has one devicetree. See `Why not have two devicetrees?`_. +- For a consistent firmware build, decisions made in early stages should be
- communicated to later ones at runtime. For example, if the serial
console is
- enabled in an early stage, it should be enabled in U-Boot too.
+- U-Boot is quite capable of managing its own copy of the devicetree. If
- another project wants to bypass this (often for good reason), it is
reasonable
- that it should take on the (fairly small) requirements that U-Boot
features
- that rely on devicetree are still available
+- The point here is not that *U-Boot needs this extra node*, or *U-Boot needs
- to have this public key*. These features are present in U-Boot in
service of
- the entire firmware system. If the U-Boot features are used, but cannot
be
- supported in the normal way, then there is pressure to implement these
- features in other ways. In the end, we would have a different mechanism
for
- every other project that uses U-Boot. This introduces duplicate ways of
doing
- the same thing, needlessly increases the complexity of the U-Boot
source code,
- forces authors to consider parallel implementations when writing new
features,
- makes U-Boot harder to test, complicates documentation and confuses the
- runtime flow of U-Boot. If every board did things its own way rather
than
- contributing to the common code, U-Boot would lose a lot of its
cross-platform
- value.
+The above does not indicate *bad design* within U-Boot. Devicetree is a core +component of U-Boot and U-Boot makes use of it to the full. It solves a myriad +of problems that would otherwise need their own special C struct, binary format, +special property, tooling for viewing and updating, etc.
+Specifically, the other project must provide a way to add configuration and +other information to the devicetree for use by U-Boot, such as the /config node. +Note that the U-Boot in-tree devicetree source must be sufficient to build and +boot, so this is not a way to bypass that requirement.
+If binman is used, the devicetree source in U-Boot must contain the binman +definition so that a valid image can be build. This helps people discover what +other firmware components are needed and seek out appropriate documentation.
+If verified boot is used, the project must provide a way to inject a public key, +certificate or other material into the U-Boot devicetree so that it is available +to U-Boot at runtime. See `Signing with U-Boot devicetree`_. This may be +through tooling in the project itself or by making use of U-Boot's tooling.
+Devicetree generated on-the-fly in another project +--------------------------------------------------
+In some rare cases, another project may wish to create a devicetree for U-Boot +entirely on-the-fly, then pass it to U-Boot at runtime. The only known example +of this at the time of writing (2021) is QEMU, for ARM (`QEMU ARM`_) and +RISC-V (`QEMU RISC-V`_).
+In effect, when the board boots, U-Boot is *downstream* of the other project. +It is entirely reliant on that project for its correct operation.
+This does not mean to imply that the other project is creating its own, +incompatible devicetree. In fact QEMU generates a valid devicetree which is +suitable for both U-Boot and Linux. It is quite normal for a devicetree to be +present in flash and be made available to U-Boot at runtime. What matters is +where the devicetree comes from. If the other project builds a devicetree for +U-Boot then it needs to support adding the things needed by U-Boot features. +Without them, for example:
+- U-Boot may not boot because too many devices are enabled before relocation +- U-Boot may not have access to the developer or production public keys used for
- signing
+- U-Boot may not support controlling whether the console is enabled +- U-Boot may not be know which MMC device to boot from +- U-Boot may not be able to find other firmware components that it needs to load
+Normally, supporting U-Boot's features is trivial, since the devicetree compiler +(dtc) can compile the source, including any U-Boot pieces. So the burden is +extremely low.
+In this case, the devicetree in the other project must track U-Boot's use of +device tree, so that it remains compatible. See `Devicetree in another project`_ +for reasons why.
+If a particular version of the project is needed for a particular version of +U-Boot, that must be documented in both projects.
+Further, it must provide a way to add configuration and other information to +the devicetree for use by U-Boot, such as the `/config` node and the tags used +by driver model. Note that the U-Boot in-tree devicetree must be sufficient to +build and boot, so this is not a way to bypass that requirement.
+More specifically, tooling or command-line arguments must provide a way to +add a `/config` node or items within that node, so that U-Boot can receive a +suitable configuration. It must provide a way of adding `u-boot,dm-...` tags for +correct operation of driver model. These options can then be used as part of the +build process, which puts the firmware image together. For binman, a way must be +provided to add the binman definition into the devicetree in the same way.
+One way to do this is to allow a .dtsi file to be merged in with the generated +devicetree.
+Note that the burden goes both ways. If a new feature is added to U-Boot which +needs support in another project, then the author of the U-Boot patch must add +any required support to the other project.
+Passing the devicetree through to Linux +---------------------------------------
+Ideally U-Boot and Linux use the same devicetree source, even though it is +hosted in separate projects. U-Boot adds some extra pieces, such as the +`config/` node and tags like `u-boot,dm-spl`. Linux adds some extra pieces, such +as `linux,default-trigger` and `linux,code`. This should not interfere with +each other.
+In principle it is possible for U-Boot's control devicetree to be passed to +Linux. This is, after all, one of the goals of devicetree and the original +Open Firmware project, to have the firmware provide the hardware description to +the Operating System.
+For boards where this approach is used, care must be taken. U-Boot typically +needs to 'fix up' the devicetree before passing it to Linux, e.g. to add +information about the memory map, about which serial console is used, provide +the kernel address space layout randomization (KASLR) seed or select whether the +console should be silenced for a faster boot.
+Fix-ups involve modifying the devicetree. If the control devicetree is used, +that means the control devicetree could be modified, while U-Boot is using it. +Removing a device and reinserting it can cause problems if the devicetree offset +has changed, for example, since the device will be unable to locates its +devicetree properties at the expected devicetree offset, which is a fixed +integer.
+To deal with this, it is recommended to employ one or more of the following +approaches:
+- Make a copy of the devicetree and 'fix up' the copy, leaving the control
- devicetree alone
+- Enable `CONFIG_OF_LIVE` so that U-Boot makes its own copy of the devicetree
- during relocation; fixups then happen on the original flat tree
+- Ensure that fix-ups happen after all loading has happened and U-Boot has
- completed image verification
+In practice,the last point is typically observed, since boot_prep_linux() is +called just before jumping to Linux, long after signature verification, for +example. But it is important to make sure that this line is not blurred, +particularly if untrusted user data is involved.
+Devicetree use cases that must be supported +-------------------------------------------
+Regardless of how the devicetree is provided to U-Boot at runtime, various +U-Boot features must be fully supported. This section describes some of these +features and the implications for other projects.
+If U-Boot uses its own in-tree devicetree these features are supported +automatically.
+Signing with U-Boot devicetree +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+U-Boot supports signing a payload so that it can be verified to have been +created by a party owning a private key. This is called verified boot in U-Boot +(see doc/uImage.FIT/verified-boot.txt).
+Typically this works by creating a FIT and then running the `mkimage` tool to +add signatures for particular images. As part of this process, `mkimage` writes +a public key to the U-Boot devicetree, although this can be done separately. +See fdt_add_pubkey_ for patches for a suitable tool, for example.
+As with all configuration information, if another project is providing the +devicetree to U-Boot, it must provide a way to add this public key into the +devicetree it passes to U-Boot. This could be via a tooling option, making use +of `mkimage`, or allowing a .dtsi file to be merged in with what is generated in +the other project.
+Providing the binman image definition +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+In complex systems U-Boot must locate and make use of other firmware components, +such as images for the user interface, files containing peripheral firmware, +multiple copies of U-Boot for use with A/B boot, etc. U-Boot uses +:doc:`Binman <../package/binman>` as a standard way of putting an image +together.
+Typically this works by running binman with the devicetree as an input, to +create the file image. Binman then outputs an updated devicetree which is +packed in the firmware image, so U-Boot can access the binman definition and +locate all the components.
+As with all configuration information, if another project is providing the +devicetree to U-Boot, it must provide a way to add this binman definition into +the devicetree it passes to U-Boot. This could be via a tooling option, making +use of `binman`, or alowing a .dtsi file to be merged in with what is generated +in the other project.
+Protecting the devicetree +-------------------------
+U-Boot relies heavily on devicetree for correct operation. A corrupt or invalid +device can cause U-Boot to fail to start, behave incorrectly, crash (e.g. if +`CONFIG_OF_LIBFDT_ASSUME_MASK` is adjusted, or fail to boot an Operating System. +Within U-Boot, the devicetree is as important as any other part of the source +code. At ruuntime, the devicetree can be considered to be structured rodata.
+With secure systems, care must be taken that the devicetree is valid:
+- If the code / rodata has a hash or signature, the devicetree should also, if
- they are packaged separately.
+- If the code / rodata is write-protected when running, the devicetree should be
- also. Note that U-Boot relocates its code and devicetree, so this is
not as
- simple as it sounds. U-Boot must write-protect these items after
relocating.
+Why does U-Boot have its nodes and properties? +----------------------------------------------
+See also :doc:`../devicetree/intro`.
+There has been pushback at the concept that U-Boot dares have its own nodes and +properties in the devicetree.
+Apart from these nodes and properties, U-Boot uses the same bindings as Linux. +A `u-boot.dtsi` file helps to keep U-Boot-specific changes in separate files, +making it easier to keep devicetree source files in U-Boot in sync with Linux.
+As a counter-example, the Zephyr OS project takes a different approach. It uses +entirely different bindings, in general, making no effort to sync devicetree +source files with Linux. U-Boot strives to be compatible with Linux in a number +of ways, such as source code style and common APIs, to aid porting of code +between the projects. Devicetree is another way where U-Boot and Linux follow a +similar approach.
+Fundamentally, the idea that U-Boot cannot have its own tags flies in the face +of the devicetree specification (see dtspec_), which says:
- Nonstandard property names should specify a **unique string prefix**,
such as
- a stock ticker symbol, identifying the name of the company **or
organization**
- that defined the property. Examples:
- fsl,channel-fifo-len
- ibm,ppc-interrupt-server#s
- **linux**,network-index
+It is also fundamentally unbalanced. Linux has many tags of its own (some 36 in +version 5.13) and at least one Linux-specific node, even if you ignore things +like flash partitions which clearly provide configuration information to Linux.
+Practically speaking there are many reasons why U-Boot has its own nodes and +properties. Some examples:
+- Binding every device before relocation even if it won't be used, consumes time
- and memory: tags on each node can specify which are needed in SPL or
before
- relocation. Linux has no such constraints.
+- Requiring the full clock tree to be up and running just to get the debug UART
- running is inefficient. It is also and self-defeating, since if that
much
- code is working properly, you probably don't need the debug UART. A
devicetree
- property to provide the UART input-clock frequency is a simple solution.
+- U-Boot does not have a user space to provide policy and configuration. It
- cannot do what Linux does and run programs and look up filesystems to
figure
- out how to boot.
+Why not have two devicetrees? +-----------------------------
+Setting aside the argument for restricting U-Boot from having its own nodes and +properties, another idea proposed is to have two devicetrees, one for the +U-Boot-specific bits (here called `special`) and one for everything else (here +called `linux`).
+On the positive side, it might quieten the discussion alluded to in the section +above. But there are many negatives to consider and many open questions to +resolve.
+- **Bindings** - Presumably the special devicetree would have its own bindings.
- It would not be necessary to put a `u-boot,` prefix on anything. People
coming
- across the devicetree source would wonder how it fits in with the Linux
- devicetree.
+- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This
- would need to be expanded to support two trees. Features which need to
access
- both (such as a device driver which reads the special devicetree to get
some
- configuration info) could become quite confusing to read and write.
+- **Merging** - Can the two devicetree be merged if a platform desires it? If
- so, how is this managed in tooling? Does it happen during the build, in
which
- case they are not really separate at all. Or does U-Boot merge them at
- runtime, in which case this adds time and memory?
+- **Efficiency** - A second device tree adds more code and more code paths. It
- requires that both be made available to the code in U-Boot, e.g. via a
- separate pointer or argument or API. Overall the separation would
certainly
- not speed up U-Boot, nor decrease its size.
+- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for
- U-Boot for a particular board. Would we use these same files for the
special
- devicetree?
+- **Complexity** - Two devicetrees complicates the build system since it must
- build and package them both. Errors must be reported in such a way that
it
- is obvious which one is failing.
+- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model
- are currently placed in the nodes they relate to. How would these tags
- reference a node that is in a separate devicetree? What extra
validation would
- be needed?
+- **Storage** - How would the two devicetrees be stored in the image? At present
- we simply concatenate the U-Boot binary and the devicetree. We could
add the
- special devicetree before the Linux one, so two are concatenated, but
it is
- not pretty. We could use binman to support more complex arrangements,
but only
- some boards use this at present, so it would be a big change.
+- **API** - How would another project provide two devicetree files to U-Boot at
- runtime? Presumably this would just be too painful. But if it doesn't,
it
- would be unable to configure run-time features of U-Boot during the
boot.
+- **Confusion** - No other project has two devicetrees. U-Boot would be in the
- unfortunate position of having to describe this fact to new users,
along with
- the (arguably contrived) reason for the arrangement.
False: 1) projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes. 2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT. If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
+- **Signing flow** - The current signing flow is simple as it involves
running
- `mkimage` with the U-Boot devicetree. This would have to be updated to
use the
- special devicetree. Some way of telling the user that they have done it
wrong
- would have to be invented.
+Overall, adding a second devicetree would create enormous confusion and +complexity. It seems a lot cheaper to solve this by a change of attitude.
+.. _rpi_patch: https://patchwork.ozlabs.org/project/uboot/patch/20170402082520.32546-1-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
-- 2.33.0.1079.g6e70778dc9-goog
Hi François,
On Tue, 26 Oct 2021 at 08:31, François Ozog francois.ozog@linaro.org wrote:
Hi Simon,
On Tue, 26 Oct 2021 at 02:25, Simon Glass sjg@chromium.org wrote:
At present some of the ideas and techniques behind devicetree in U-Boot are assumed, implied or unsaid. Add some documentation to cover how devicetree is build, how it can be modified and the rules about using the various CONFIG_OF_... options.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Marcel Ziswiler marcel.ziswiler@toradex.com
This patch attracted quite a bit of discussion here:
https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-sjg...
I have not included the text suggested by François. While I agree that it would be useful to have an introduction in this space, I do not agree that we should have two devicetrees or that U-Boot should not have its own things in the devicetree, so it is not clear to me what we should actually write.
The 'Devicetree Control in U-Boot' docs were recently merged and these provide some base info, for now.
Changes in v5:
- Bring into the OF_BOARD series
- Rebase to master and drop mention of OF_PRIOR_STAGE, since removed
- Refer to the 'control' DTB in the first paragraph
- Use QEMU instead of qemu
Changes in v3:
- Clarify the 'bug' refered to at the top
- Reword 'This means that there' paragraph to explain U-Boot-specific things
- Move to doc/develop/devicetree now that OF_CONTROL is in the docs
Changes in v2:
- Fix typos per Sean (thank you!) and a few others
- Add a 'Use of U-Boot /config node' section
- Drop mention of dm-verity since that actually uses the kernel cmdline
- Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph)
- Expand a bit on the reason why the 'Current situation' is bad
- Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...'
- Expand on why we should have rules for other projects in 'Devicetree in another project'
- Add a comment as to why devicetree in U-Boot is not 'bad design'
- Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
- Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1
- Add 'Why does U-Boot have its nodes and properties?'
- Add 'Why not have two devicetrees?'
doc/develop/devicetree/dt_update.rst | 556 +++++++++++++++++++++++++++ doc/develop/devicetree/index.rst | 1 + 2 files changed, 557 insertions(+) create mode 100644 doc/develop/devicetree/dt_update.rst
diff --git a/doc/develop/devicetree/dt_update.rst b/doc/develop/devicetree/dt_update.rst new file mode 100644 index 00000000000..3d4902e3592 --- /dev/null +++ b/doc/develop/devicetree/dt_update.rst @@ -0,0 +1,556 @@ +.. SPDX-License-Identifier: GPL-2.0+
+Updating the devicetree +=======================
+U-Boot uses devicetree for runtime configuration and storing required blobs or +any other information it needs to operate. This is called the 'control' +devicetree since it controls U-Boot. It is possible to update the control +devicetree separately from actually building U-Boot. This provides a good degree +of control and flexibility for firmware that uses U-Boot in conjunction with +other project.
+There are many reasons why it is useful to modify the devicetree after building +it:
+- Configuration can be changed, e.g. which UART to use +- A serial number can be added +- Public keys can be added to allow image verification +- Console output can be changed (e.g. to select serial or vidconsole)
+This section describes how to work with devicetree to accomplish your goals.
+See also :doc:`../devicetree/control` for a basic summary of the available +features.
+Devicetree source +-----------------
+Every board in U-Boot must include a devicetree sufficient to build and boot +that board on suitable hardware (or emulation). This is specified using the +`CONFIG DEFAULT_DEVICE_TREE` option.
+Current situation (October 2021) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty, +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an enormous +amount of confusion and some wasted effort. This was not intended. Support for +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon.
+Some of the problems created are:
+- It is not obvious that the devicetree is coming from another project
+- There is no way to see even a sample devicetree for these platform in U-Boot,
- so it is hard to know what is going on, e.g. which devices are typically
- present
+- The other project may not provide a way to support U-Boot's requirements for
- devicetree, such as the /config node. Note: On the U-Boot mailing linst, this
- was only discovered after weeks of discussion and confusion
+- For QEMU specifically, consulting two QEMU source files is required, for which
- there are no references in U-Boot documentation. The code is generating a
- devicetree, but it is not clear what controls affect this generation.
+Specifically on the changes in U-Bootm `CONFIG_OF_BOARD` was added in +rpi_patch_ for Raspberry Pi, which does have an in-tree devicetree, but this +feature has since been used for boards that don't
+Once this bug is fixed, CONFIG_OF_BOARD will override (at runtime) the +evicetree suppled with U-Boot, but will otherwise use CONFIG_OF_SEPARATE for the +in-tree build. So these two will become options, moving out of the 'choice' in +`dts/Kconfig`.
+This means that there is a basic devicetree build in the U-Boot tree, for +build-testing, consistency and documentation purposes, but at runtime U-Boot can +accept its devicetree from another source. The in-tree devicetree may contain +U-Boot-specific features (in u-boot*.dtsi files) and this may prove useful for +the other project, so it can ensure that U-Boot functions correctly and supports +all its expected features.
+To be clear, while U-Boot has its own copy of the devicetree source for each +board, this must match the Linux source, perhaps with some u-boot.dtsi +additions. The intent here is not to create a separate binding, just to provide +a representative devicetree in U-Boot.
+Offending boards are:
+- rpi_4 and rpi_4_32b (other rpi boards do have an in-tree devicetree) +- qemu_arm64 +- qemu_arm +- qemu-ppce500 +- qemu-riscv32 +- qemu-riscv32_smode +- qemu-riscv64 +- qemu-riscv64_smode
+All of these need to have a devicetree added in-tree. This is targeted to be +fixed in the 2022.01 release.
+Building the devicetree +-----------------------
+U-Boot automatically builds the devicetree for a board, from the +`arch/<arch>/dts` directory. The Makefile in those directories has rules for +building devicetree files. It is preferable to avoid target-specific rules in +those files: i.e. all boards for a particular SoC should be built at once, +where practical. Apart from simplifying the Makefile, this helps to efficiently +(and immediately) ensure that changes in one board's DT do not break others that +are related. Building devicetrees is fast, so performance is seldom a concern +here.
+Overriding the default devicetree +---------------------------------
+When building U-Boot, the `DEVICE_TREE` environment variable allows the +default devicetree file to be overridden at build time. This can be useful if +modifications have to be made to the in-tree devicetree file, for the benefit +of a downstream build system. Note that the in-tree devicetree must be +sufficient to build and boot, so this is not a way to bypass that requirement.
+Modifying the devicetree after building +---------------------------------------
+While it is generally painful and hacky to modify the code or rodata of a +program after it is built, in many cases it is useful to do so, e.g. to add +configuration information like serial numbers, enabling/disabling features, etc.
+Devicetree provides a very nice solution to these problems since it is +structured data and it is relatively easy to change it, even in binary form +(see fdtput).
+U-Boot takes care that the devicetree is easily accessible after the build +process. In fact it is placed in a separate file called `u-boot.dtb`. If the +build system wants to modify or replace that file, it can do so. Then all that +is needed is to run `binman update` to update the file inside the image. If +binman is not used, then `u-boot-nodtb.bin` and the new `u-boot.dtb` can simply +be concatenated to achieve the desired result. U-Boot happily copes with the +devicetree growing or shrinking.
+The `u-boot.bin` image contains both pieces. While it is possible to locate the +devicetree within the image using the signature at the start of the file, this +is a bit messy.
+This is why `CONFIG_OF_SEPARATE` should always be used when building U-Boot. +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot ELF +image as rodata, meaning that it is hard to find it and it cannot increase in +size.
+When modifying the devicetree, the different cases to consider are as follows:
+- CONFIG_OF_SEPARATE
- This is easy, described above. Just change, replace or rebuild the
- devicetree so it suits your needs, then rerun binman or redo the `cat`
- operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb`
+- CONFIG_OF_EMBED
- This is tricky, since the devicetree cannot easily be located. If the EFL
- file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can be
- examined to find it. While it is possible to contract the file, it is not
- possible to expand the file since that would involve re-linking
+- CONFIG_OF_BOARD
- This is a board-specific situation, so needs to be considered on a
- case-by-case base. The devicetree must be modified so that the correct
- one is provided to U-Boot. How this is done depends entirely on the
- implementation of this option for the board. It might require injecting the
- changes into a different project somehow using tooling available there, or
- it might involve merging an overlay file at runtime to obtain the desired
- result.
+Use of U-Boot /config node +--------------------------
+A common problem with firmware is that many builds are needed to deal with the +slight variations between different, related models. For example, one model may +have a TPM and another may not. Devicetree provides an excellent solution to +this problem, in that the devicetree to actually use on a platform can be +injected in the factory based on which model is being manufactured at the time.
+A related problem causing build proliferation is dealing with the differences +between development firmware, developer-friendly firmware (e.g. with all +security features present but with the ability to access the command line), +test firmware (which runs tests used in the factory), final production firmware +(before signing), signed firmware (where the signatures have been inserted) and +the like. Ideally all or most of these should use the same U-Boot build, with +just some options to determine the features available. For example, being able +to control whether the UART console or JTAG are available, on any image, is a +great debugging aid.
+When the firmware consists of multiple parts, it is helpful that all operate +the same way at runtime, regardless of how they were built. This can be achieved +by passing the runtime configuration (e.g. 'enable UART console) along the chain +through each firmware stage. It is frustrating to have to replicate a bug on +production firmware which does happen on developer firmware, because they are +completely different builds.
+The /config node provides useful functionality for this. It allows the different +controls to be 'factored out' of the U-Boot binary, so they can be controlled +separately from the initial source-code build. The node can be easily updated by +a build or factory tool and can control various features in U-Boot. It is +similar in concept to a Kconfig option, except that it can be changed after +U-Boot is built.
+The /config node is similar in concept to the `/chosen node`_ except that it is +for passing information *into* firmware instead of from firmware to the +Operating System. Also, while Linux has a (sometimes extremely long) command +line, U-Boot does not support this. The devicetree provides a more structured +approach in any case.
+Devicetree in another project +-----------------------------
+In some cases U-Boot receive its devicetree at runtime from a program that calls +it. For example ARM's Trusted Firmware A (`TF-A`_) may have a devicetree that it +passes to U-Boot. This overrides any devicetree build by U-Boot. When packaging +the firmware, the U-Boot devicetree may in fact be left out if it can be +guaranteed that it will receive one from another project.
+In this case, the devicetree in the other project must track U-Boot's use of +device tree, for the following reasons:
+- U-Boot only has one devicetree. See `Why not have two devicetrees?`_. +- For a consistent firmware build, decisions made in early stages should be
- communicated to later ones at runtime. For example, if the serial console is
- enabled in an early stage, it should be enabled in U-Boot too.
+- U-Boot is quite capable of managing its own copy of the devicetree. If
- another project wants to bypass this (often for good reason), it is reasonable
- that it should take on the (fairly small) requirements that U-Boot features
- that rely on devicetree are still available
+- The point here is not that *U-Boot needs this extra node*, or *U-Boot needs
- to have this public key*. These features are present in U-Boot in service of
- the entire firmware system. If the U-Boot features are used, but cannot be
- supported in the normal way, then there is pressure to implement these
- features in other ways. In the end, we would have a different mechanism for
- every other project that uses U-Boot. This introduces duplicate ways of doing
- the same thing, needlessly increases the complexity of the U-Boot source code,
- forces authors to consider parallel implementations when writing new features,
- makes U-Boot harder to test, complicates documentation and confuses the
- runtime flow of U-Boot. If every board did things its own way rather than
- contributing to the common code, U-Boot would lose a lot of its cross-platform
- value.
+The above does not indicate *bad design* within U-Boot. Devicetree is a core +component of U-Boot and U-Boot makes use of it to the full. It solves a myriad +of problems that would otherwise need their own special C struct, binary format, +special property, tooling for viewing and updating, etc.
+Specifically, the other project must provide a way to add configuration and +other information to the devicetree for use by U-Boot, such as the /config node. +Note that the U-Boot in-tree devicetree source must be sufficient to build and +boot, so this is not a way to bypass that requirement.
+If binman is used, the devicetree source in U-Boot must contain the binman +definition so that a valid image can be build. This helps people discover what +other firmware components are needed and seek out appropriate documentation.
+If verified boot is used, the project must provide a way to inject a public key, +certificate or other material into the U-Boot devicetree so that it is available +to U-Boot at runtime. See `Signing with U-Boot devicetree`_. This may be +through tooling in the project itself or by making use of U-Boot's tooling.
+Devicetree generated on-the-fly in another project +--------------------------------------------------
+In some rare cases, another project may wish to create a devicetree for U-Boot +entirely on-the-fly, then pass it to U-Boot at runtime. The only known example +of this at the time of writing (2021) is QEMU, for ARM (`QEMU ARM`_) and +RISC-V (`QEMU RISC-V`_).
+In effect, when the board boots, U-Boot is *downstream* of the other project. +It is entirely reliant on that project for its correct operation.
+This does not mean to imply that the other project is creating its own, +incompatible devicetree. In fact QEMU generates a valid devicetree which is +suitable for both U-Boot and Linux. It is quite normal for a devicetree to be +present in flash and be made available to U-Boot at runtime. What matters is +where the devicetree comes from. If the other project builds a devicetree for +U-Boot then it needs to support adding the things needed by U-Boot features. +Without them, for example:
+- U-Boot may not boot because too many devices are enabled before relocation +- U-Boot may not have access to the developer or production public keys used for
- signing
+- U-Boot may not support controlling whether the console is enabled +- U-Boot may not be know which MMC device to boot from +- U-Boot may not be able to find other firmware components that it needs to load
+Normally, supporting U-Boot's features is trivial, since the devicetree compiler +(dtc) can compile the source, including any U-Boot pieces. So the burden is +extremely low.
+In this case, the devicetree in the other project must track U-Boot's use of +device tree, so that it remains compatible. See `Devicetree in another project`_ +for reasons why.
+If a particular version of the project is needed for a particular version of +U-Boot, that must be documented in both projects.
+Further, it must provide a way to add configuration and other information to +the devicetree for use by U-Boot, such as the `/config` node and the tags used +by driver model. Note that the U-Boot in-tree devicetree must be sufficient to +build and boot, so this is not a way to bypass that requirement.
+More specifically, tooling or command-line arguments must provide a way to +add a `/config` node or items within that node, so that U-Boot can receive a +suitable configuration. It must provide a way of adding `u-boot,dm-...` tags for +correct operation of driver model. These options can then be used as part of the +build process, which puts the firmware image together. For binman, a way must be +provided to add the binman definition into the devicetree in the same way.
+One way to do this is to allow a .dtsi file to be merged in with the generated +devicetree.
+Note that the burden goes both ways. If a new feature is added to U-Boot which +needs support in another project, then the author of the U-Boot patch must add +any required support to the other project.
+Passing the devicetree through to Linux +---------------------------------------
+Ideally U-Boot and Linux use the same devicetree source, even though it is +hosted in separate projects. U-Boot adds some extra pieces, such as the +`config/` node and tags like `u-boot,dm-spl`. Linux adds some extra pieces, such +as `linux,default-trigger` and `linux,code`. This should not interfere with +each other.
+In principle it is possible for U-Boot's control devicetree to be passed to +Linux. This is, after all, one of the goals of devicetree and the original +Open Firmware project, to have the firmware provide the hardware description to +the Operating System.
+For boards where this approach is used, care must be taken. U-Boot typically +needs to 'fix up' the devicetree before passing it to Linux, e.g. to add +information about the memory map, about which serial console is used, provide +the kernel address space layout randomization (KASLR) seed or select whether the +console should be silenced for a faster boot.
+Fix-ups involve modifying the devicetree. If the control devicetree is used, +that means the control devicetree could be modified, while U-Boot is using it. +Removing a device and reinserting it can cause problems if the devicetree offset +has changed, for example, since the device will be unable to locates its +devicetree properties at the expected devicetree offset, which is a fixed +integer.
+To deal with this, it is recommended to employ one or more of the following +approaches:
+- Make a copy of the devicetree and 'fix up' the copy, leaving the control
- devicetree alone
+- Enable `CONFIG_OF_LIVE` so that U-Boot makes its own copy of the devicetree
- during relocation; fixups then happen on the original flat tree
+- Ensure that fix-ups happen after all loading has happened and U-Boot has
- completed image verification
+In practice,the last point is typically observed, since boot_prep_linux() is +called just before jumping to Linux, long after signature verification, for +example. But it is important to make sure that this line is not blurred, +particularly if untrusted user data is involved.
+Devicetree use cases that must be supported +-------------------------------------------
+Regardless of how the devicetree is provided to U-Boot at runtime, various +U-Boot features must be fully supported. This section describes some of these +features and the implications for other projects.
+If U-Boot uses its own in-tree devicetree these features are supported +automatically.
+Signing with U-Boot devicetree +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+U-Boot supports signing a payload so that it can be verified to have been +created by a party owning a private key. This is called verified boot in U-Boot +(see doc/uImage.FIT/verified-boot.txt).
+Typically this works by creating a FIT and then running the `mkimage` tool to +add signatures for particular images. As part of this process, `mkimage` writes +a public key to the U-Boot devicetree, although this can be done separately. +See fdt_add_pubkey_ for patches for a suitable tool, for example.
+As with all configuration information, if another project is providing the +devicetree to U-Boot, it must provide a way to add this public key into the +devicetree it passes to U-Boot. This could be via a tooling option, making use +of `mkimage`, or allowing a .dtsi file to be merged in with what is generated in +the other project.
+Providing the binman image definition +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+In complex systems U-Boot must locate and make use of other firmware components, +such as images for the user interface, files containing peripheral firmware, +multiple copies of U-Boot for use with A/B boot, etc. U-Boot uses +:doc:`Binman <../package/binman>` as a standard way of putting an image +together.
+Typically this works by running binman with the devicetree as an input, to +create the file image. Binman then outputs an updated devicetree which is +packed in the firmware image, so U-Boot can access the binman definition and +locate all the components.
+As with all configuration information, if another project is providing the +devicetree to U-Boot, it must provide a way to add this binman definition into +the devicetree it passes to U-Boot. This could be via a tooling option, making +use of `binman`, or alowing a .dtsi file to be merged in with what is generated +in the other project.
+Protecting the devicetree +-------------------------
+U-Boot relies heavily on devicetree for correct operation. A corrupt or invalid +device can cause U-Boot to fail to start, behave incorrectly, crash (e.g. if +`CONFIG_OF_LIBFDT_ASSUME_MASK` is adjusted, or fail to boot an Operating System. +Within U-Boot, the devicetree is as important as any other part of the source +code. At ruuntime, the devicetree can be considered to be structured rodata.
+With secure systems, care must be taken that the devicetree is valid:
+- If the code / rodata has a hash or signature, the devicetree should also, if
- they are packaged separately.
+- If the code / rodata is write-protected when running, the devicetree should be
- also. Note that U-Boot relocates its code and devicetree, so this is not as
- simple as it sounds. U-Boot must write-protect these items after relocating.
+Why does U-Boot have its nodes and properties? +----------------------------------------------
+See also :doc:`../devicetree/intro`.
+There has been pushback at the concept that U-Boot dares have its own nodes and +properties in the devicetree.
+Apart from these nodes and properties, U-Boot uses the same bindings as Linux. +A `u-boot.dtsi` file helps to keep U-Boot-specific changes in separate files, +making it easier to keep devicetree source files in U-Boot in sync with Linux.
+As a counter-example, the Zephyr OS project takes a different approach. It uses +entirely different bindings, in general, making no effort to sync devicetree +source files with Linux. U-Boot strives to be compatible with Linux in a number +of ways, such as source code style and common APIs, to aid porting of code +between the projects. Devicetree is another way where U-Boot and Linux follow a +similar approach.
+Fundamentally, the idea that U-Boot cannot have its own tags flies in the face +of the devicetree specification (see dtspec_), which says:
- Nonstandard property names should specify a **unique string prefix**, such as
- a stock ticker symbol, identifying the name of the company **or organization**
- that defined the property. Examples:
- fsl,channel-fifo-len
- ibm,ppc-interrupt-server#s
- **linux**,network-index
+It is also fundamentally unbalanced. Linux has many tags of its own (some 36 in +version 5.13) and at least one Linux-specific node, even if you ignore things +like flash partitions which clearly provide configuration information to Linux.
+Practically speaking there are many reasons why U-Boot has its own nodes and +properties. Some examples:
+- Binding every device before relocation even if it won't be used, consumes time
- and memory: tags on each node can specify which are needed in SPL or before
- relocation. Linux has no such constraints.
+- Requiring the full clock tree to be up and running just to get the debug UART
- running is inefficient. It is also and self-defeating, since if that much
- code is working properly, you probably don't need the debug UART. A devicetree
- property to provide the UART input-clock frequency is a simple solution.
+- U-Boot does not have a user space to provide policy and configuration. It
- cannot do what Linux does and run programs and look up filesystems to figure
- out how to boot.
+Why not have two devicetrees? +-----------------------------
+Setting aside the argument for restricting U-Boot from having its own nodes and +properties, another idea proposed is to have two devicetrees, one for the +U-Boot-specific bits (here called `special`) and one for everything else (here +called `linux`).
+On the positive side, it might quieten the discussion alluded to in the section +above. But there are many negatives to consider and many open questions to +resolve.
+- **Bindings** - Presumably the special devicetree would have its own bindings.
- It would not be necessary to put a `u-boot,` prefix on anything. People coming
- across the devicetree source would wonder how it fits in with the Linux
- devicetree.
+- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This
- would need to be expanded to support two trees. Features which need to access
- both (such as a device driver which reads the special devicetree to get some
- configuration info) could become quite confusing to read and write.
+- **Merging** - Can the two devicetree be merged if a platform desires it? If
- so, how is this managed in tooling? Does it happen during the build, in which
- case they are not really separate at all. Or does U-Boot merge them at
- runtime, in which case this adds time and memory?
+- **Efficiency** - A second device tree adds more code and more code paths. It
- requires that both be made available to the code in U-Boot, e.g. via a
- separate pointer or argument or API. Overall the separation would certainly
- not speed up U-Boot, nor decrease its size.
+- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for
- U-Boot for a particular board. Would we use these same files for the special
- devicetree?
+- **Complexity** - Two devicetrees complicates the build system since it must
- build and package them both. Errors must be reported in such a way that it
- is obvious which one is failing.
+- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model
- are currently placed in the nodes they relate to. How would these tags
- reference a node that is in a separate devicetree? What extra validation would
- be needed?
+- **Storage** - How would the two devicetrees be stored in the image? At present
- we simply concatenate the U-Boot binary and the devicetree. We could add the
- special devicetree before the Linux one, so two are concatenated, but it is
- not pretty. We could use binman to support more complex arrangements, but only
- some boards use this at present, so it would be a big change.
+- **API** - How would another project provide two devicetree files to U-Boot at
- runtime? Presumably this would just be too painful. But if it doesn't, it
- would be unable to configure run-time features of U-Boot during the boot.
+- **Confusion** - No other project has two devicetrees. U-Boot would be in the
- unfortunate position of having to describe this fact to new users, along with
- the (arguably contrived) reason for the arrangement.
False:
- projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes.
Can you provided a link and I can update this.
- STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system
As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT. If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
I have gone to great efforts to document things here, as they work in U-Boot today. As you know, U-Boot supports separate control and active devicetrees. But if you are wanting to change to multiple control trees within U-Boot, I'd say the answer is "no, thank you". If there is a use case for that, please can you be specific about what we cannot do with a combined devicetree?
Regards, Simon
On Tue, 26 Oct 2021 at 17:27, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 08:31, François Ozog francois.ozog@linaro.org wrote:
Hi Simon,
On Tue, 26 Oct 2021 at 02:25, Simon Glass sjg@chromium.org wrote:
At present some of the ideas and techniques behind devicetree in U-Boot are assumed, implied or unsaid. Add some documentation to cover how devicetree is build, how it can be modified and the rules about using the various CONFIG_OF_... options.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Marcel Ziswiler marcel.ziswiler@toradex.com
This patch attracted quite a bit of discussion here:
https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-sjg...
I have not included the text suggested by François. While I agree that it would be useful to have an introduction in this space, I do not agree that we should have two devicetrees or that U-Boot should not have its
own
things in the devicetree, so it is not clear to me what we should
actually
write.
The 'Devicetree Control in U-Boot' docs were recently merged and these provide some base info, for now.
Changes in v5:
- Bring into the OF_BOARD series
- Rebase to master and drop mention of OF_PRIOR_STAGE, since removed
- Refer to the 'control' DTB in the first paragraph
- Use QEMU instead of qemu
Changes in v3:
- Clarify the 'bug' refered to at the top
- Reword 'This means that there' paragraph to explain U-Boot-specific
things
- Move to doc/develop/devicetree now that OF_CONTROL is in the docs
Changes in v2:
- Fix typos per Sean (thank you!) and a few others
- Add a 'Use of U-Boot /config node' section
- Drop mention of dm-verity since that actually uses the kernel cmdline
- Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph)
- Expand a bit on the reason why the 'Current situation' is bad
- Clarify in a second place that Linux and U-Boot use the same
devicetree
in 'To be clear, while U-Boot...'
- Expand on why we should have rules for other projects in 'Devicetree in another project'
- Add a comment as to why devicetree in U-Boot is not 'bad design'
- Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
- Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1
- Add 'Why does U-Boot have its nodes and properties?'
- Add 'Why not have two devicetrees?'
doc/develop/devicetree/dt_update.rst | 556 +++++++++++++++++++++++++++ doc/develop/devicetree/index.rst | 1 + 2 files changed, 557 insertions(+) create mode 100644 doc/develop/devicetree/dt_update.rst
diff --git a/doc/develop/devicetree/dt_update.rst
b/doc/develop/devicetree/dt_update.rst
new file mode 100644 index 00000000000..3d4902e3592 --- /dev/null +++ b/doc/develop/devicetree/dt_update.rst @@ -0,0 +1,556 @@ +.. SPDX-License-Identifier: GPL-2.0+
+Updating the devicetree +=======================
+U-Boot uses devicetree for runtime configuration and storing required
blobs or
+any other information it needs to operate. This is called the 'control' +devicetree since it controls U-Boot. It is possible to update the
control
+devicetree separately from actually building U-Boot. This provides a
good degree
+of control and flexibility for firmware that uses U-Boot in
conjunction with
+other project.
+There are many reasons why it is useful to modify the devicetree after
building
+it:
+- Configuration can be changed, e.g. which UART to use +- A serial number can be added +- Public keys can be added to allow image verification +- Console output can be changed (e.g. to select serial or vidconsole)
+This section describes how to work with devicetree to accomplish your
goals.
+See also :doc:`../devicetree/control` for a basic summary of the
available
+features.
+Devicetree source +-----------------
+Every board in U-Boot must include a devicetree sufficient to build
and boot
+that board on suitable hardware (or emulation). This is specified
using the
+`CONFIG DEFAULT_DEVICE_TREE` option.
+Current situation (October 2021) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to
be empty,
+e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an
enormous
+amount of confusion and some wasted effort. This was not intended.
Support for
+an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon.
+Some of the problems created are:
+- It is not obvious that the devicetree is coming from another project
+- There is no way to see even a sample devicetree for these platform
in U-Boot,
- so it is hard to know what is going on, e.g. which devices are
typically
- present
+- The other project may not provide a way to support U-Boot's
requirements for
- devicetree, such as the /config node. Note: On the U-Boot mailing
linst, this
- was only discovered after weeks of discussion and confusion
+- For QEMU specifically, consulting two QEMU source files is required,
for which
- there are no references in U-Boot documentation. The code is
generating a
- devicetree, but it is not clear what controls affect this generation.
+Specifically on the changes in U-Bootm `CONFIG_OF_BOARD` was added in +rpi_patch_ for Raspberry Pi, which does have an in-tree devicetree,
but this
+feature has since been used for boards that don't
+Once this bug is fixed, CONFIG_OF_BOARD will override (at runtime) the +evicetree suppled with U-Boot, but will otherwise use
CONFIG_OF_SEPARATE for the
+in-tree build. So these two will become options, moving out of the
'choice' in
+`dts/Kconfig`.
+This means that there is a basic devicetree build in the U-Boot tree,
for
+build-testing, consistency and documentation purposes, but at runtime
U-Boot can
+accept its devicetree from another source. The in-tree devicetree may
contain
+U-Boot-specific features (in u-boot*.dtsi files) and this may prove
useful for
+the other project, so it can ensure that U-Boot functions correctly
and supports
+all its expected features.
+To be clear, while U-Boot has its own copy of the devicetree source
for each
+board, this must match the Linux source, perhaps with some u-boot.dtsi +additions. The intent here is not to create a separate binding, just
to provide
+a representative devicetree in U-Boot.
+Offending boards are:
+- rpi_4 and rpi_4_32b (other rpi boards do have an in-tree devicetree) +- qemu_arm64 +- qemu_arm +- qemu-ppce500 +- qemu-riscv32 +- qemu-riscv32_smode +- qemu-riscv64 +- qemu-riscv64_smode
+All of these need to have a devicetree added in-tree. This is targeted
to be
+fixed in the 2022.01 release.
+Building the devicetree +-----------------------
+U-Boot automatically builds the devicetree for a board, from the +`arch/<arch>/dts` directory. The Makefile in those directories has
rules for
+building devicetree files. It is preferable to avoid target-specific
rules in
+those files: i.e. all boards for a particular SoC should be built at
once,
+where practical. Apart from simplifying the Makefile, this helps to
efficiently
+(and immediately) ensure that changes in one board's DT do not break
others that
+are related. Building devicetrees is fast, so performance is seldom a
concern
+here.
+Overriding the default devicetree +---------------------------------
+When building U-Boot, the `DEVICE_TREE` environment variable allows the +default devicetree file to be overridden at build time. This can be
useful if
+modifications have to be made to the in-tree devicetree file, for the
benefit
+of a downstream build system. Note that the in-tree devicetree must be +sufficient to build and boot, so this is not a way to bypass that
requirement.
+Modifying the devicetree after building +---------------------------------------
+While it is generally painful and hacky to modify the code or rodata
of a
+program after it is built, in many cases it is useful to do so, e.g.
to add
+configuration information like serial numbers, enabling/disabling
features, etc.
+Devicetree provides a very nice solution to these problems since it is +structured data and it is relatively easy to change it, even in binary
form
+(see fdtput).
+U-Boot takes care that the devicetree is easily accessible after the
build
+process. In fact it is placed in a separate file called `u-boot.dtb`.
If the
+build system wants to modify or replace that file, it can do so. Then
all that
+is needed is to run `binman update` to update the file inside the
image. If
+binman is not used, then `u-boot-nodtb.bin` and the new `u-boot.dtb`
can simply
+be concatenated to achieve the desired result. U-Boot happily copes
with the
+devicetree growing or shrinking.
+The `u-boot.bin` image contains both pieces. While it is possible to
locate the
+devicetree within the image using the signature at the start of the
file, this
+is a bit messy.
+This is why `CONFIG_OF_SEPARATE` should always be used when building
U-Boot.
+The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the
U-Boot ELF
+image as rodata, meaning that it is hard to find it and it cannot
increase in
+size.
+When modifying the devicetree, the different cases to consider are as
follows:
+- CONFIG_OF_SEPARATE
- This is easy, described above. Just change, replace or rebuild the
- devicetree so it suits your needs, then rerun binman or redo the
`cat`
- operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb`
+- CONFIG_OF_EMBED
- This is tricky, since the devicetree cannot easily be located. If
the EFL
- file is available, then the _dtb_dt_begin and __dtb_dt_end symbols
can be
- examined to find it. While it is possible to contract the file, it
is not
- possible to expand the file since that would involve re-linking
+- CONFIG_OF_BOARD
- This is a board-specific situation, so needs to be considered on a
- case-by-case base. The devicetree must be modified so that the
correct
- one is provided to U-Boot. How this is done depends entirely on the
- implementation of this option for the board. It might require
injecting the
- changes into a different project somehow using tooling available
there, or
- it might involve merging an overlay file at runtime to obtain the
desired
- result.
+Use of U-Boot /config node +--------------------------
+A common problem with firmware is that many builds are needed to deal
with the
+slight variations between different, related models. For example, one
model may
+have a TPM and another may not. Devicetree provides an excellent
solution to
+this problem, in that the devicetree to actually use on a platform can
be
+injected in the factory based on which model is being manufactured at
the time.
+A related problem causing build proliferation is dealing with the
differences
+between development firmware, developer-friendly firmware (e.g. with
all
+security features present but with the ability to access the command
line),
+test firmware (which runs tests used in the factory), final production
firmware
+(before signing), signed firmware (where the signatures have been
inserted) and
+the like. Ideally all or most of these should use the same U-Boot
build, with
+just some options to determine the features available. For example,
being able
+to control whether the UART console or JTAG are available, on any
image, is a
+great debugging aid.
+When the firmware consists of multiple parts, it is helpful that all
operate
+the same way at runtime, regardless of how they were built. This can
be achieved
+by passing the runtime configuration (e.g. 'enable UART console) along
the chain
+through each firmware stage. It is frustrating to have to replicate a
bug on
+production firmware which does happen on developer firmware, because
they are
+completely different builds.
+The /config node provides useful functionality for this. It allows the
different
+controls to be 'factored out' of the U-Boot binary, so they can be
controlled
+separately from the initial source-code build. The node can be easily
updated by
+a build or factory tool and can control various features in U-Boot. It
is
+similar in concept to a Kconfig option, except that it can be changed
after
+U-Boot is built.
+The /config node is similar in concept to the `/chosen node`_ except
that it is
+for passing information *into* firmware instead of from firmware to the +Operating System. Also, while Linux has a (sometimes extremely long)
command
+line, U-Boot does not support this. The devicetree provides a more
structured
+approach in any case.
+Devicetree in another project +-----------------------------
+In some cases U-Boot receive its devicetree at runtime from a program
that calls
+it. For example ARM's Trusted Firmware A (`TF-A`_) may have a
devicetree that it
+passes to U-Boot. This overrides any devicetree build by U-Boot. When
packaging
+the firmware, the U-Boot devicetree may in fact be left out if it can
be
+guaranteed that it will receive one from another project.
+In this case, the devicetree in the other project must track U-Boot's
use of
+device tree, for the following reasons:
+- U-Boot only has one devicetree. See `Why not have two devicetrees?`_. +- For a consistent firmware build, decisions made in early stages
should be
- communicated to later ones at runtime. For example, if the serial
console is
- enabled in an early stage, it should be enabled in U-Boot too.
+- U-Boot is quite capable of managing its own copy of the devicetree.
If
- another project wants to bypass this (often for good reason), it is
reasonable
- that it should take on the (fairly small) requirements that U-Boot
features
- that rely on devicetree are still available
+- The point here is not that *U-Boot needs this extra node*, or
*U-Boot needs
- to have this public key*. These features are present in U-Boot in
service of
- the entire firmware system. If the U-Boot features are used, but
cannot be
- supported in the normal way, then there is pressure to implement
these
- features in other ways. In the end, we would have a different
mechanism for
- every other project that uses U-Boot. This introduces duplicate ways
of doing
- the same thing, needlessly increases the complexity of the U-Boot
source code,
- forces authors to consider parallel implementations when writing new
features,
- makes U-Boot harder to test, complicates documentation and confuses
the
- runtime flow of U-Boot. If every board did things its own way rather
than
- contributing to the common code, U-Boot would lose a lot of its
cross-platform
- value.
+The above does not indicate *bad design* within U-Boot. Devicetree is
a core
+component of U-Boot and U-Boot makes use of it to the full. It solves
a myriad
+of problems that would otherwise need their own special C struct,
binary format,
+special property, tooling for viewing and updating, etc.
+Specifically, the other project must provide a way to add
configuration and
+other information to the devicetree for use by U-Boot, such as the
/config node.
+Note that the U-Boot in-tree devicetree source must be sufficient to
build and
+boot, so this is not a way to bypass that requirement.
+If binman is used, the devicetree source in U-Boot must contain the
binman
+definition so that a valid image can be build. This helps people
discover what
+other firmware components are needed and seek out appropriate
documentation.
+If verified boot is used, the project must provide a way to inject a
public key,
+certificate or other material into the U-Boot devicetree so that it is
available
+to U-Boot at runtime. See `Signing with U-Boot devicetree`_. This may
be
+through tooling in the project itself or by making use of U-Boot's
tooling.
+Devicetree generated on-the-fly in another project +--------------------------------------------------
+In some rare cases, another project may wish to create a devicetree
for U-Boot
+entirely on-the-fly, then pass it to U-Boot at runtime. The only known
example
+of this at the time of writing (2021) is QEMU, for ARM (`QEMU ARM`_)
and
+RISC-V (`QEMU RISC-V`_).
+In effect, when the board boots, U-Boot is *downstream* of the other
project.
+It is entirely reliant on that project for its correct operation.
+This does not mean to imply that the other project is creating its own, +incompatible devicetree. In fact QEMU generates a valid devicetree
which is
+suitable for both U-Boot and Linux. It is quite normal for a
devicetree to be
+present in flash and be made available to U-Boot at runtime. What
matters is
+where the devicetree comes from. If the other project builds a
devicetree for
+U-Boot then it needs to support adding the things needed by U-Boot
features.
+Without them, for example:
+- U-Boot may not boot because too many devices are enabled before
relocation
+- U-Boot may not have access to the developer or production public
keys used for
- signing
+- U-Boot may not support controlling whether the console is enabled +- U-Boot may not be know which MMC device to boot from +- U-Boot may not be able to find other firmware components that it
needs to load
+Normally, supporting U-Boot's features is trivial, since the
devicetree compiler
+(dtc) can compile the source, including any U-Boot pieces. So the
burden is
+extremely low.
+In this case, the devicetree in the other project must track U-Boot's
use of
+device tree, so that it remains compatible. See `Devicetree in another
project`_
+for reasons why.
+If a particular version of the project is needed for a particular
version of
+U-Boot, that must be documented in both projects.
+Further, it must provide a way to add configuration and other
information to
+the devicetree for use by U-Boot, such as the `/config` node and the
tags used
+by driver model. Note that the U-Boot in-tree devicetree must be
sufficient to
+build and boot, so this is not a way to bypass that requirement.
+More specifically, tooling or command-line arguments must provide a
way to
+add a `/config` node or items within that node, so that U-Boot can
receive a
+suitable configuration. It must provide a way of adding
`u-boot,dm-...` tags for
+correct operation of driver model. These options can then be used as
part of the
+build process, which puts the firmware image together. For binman, a
way must be
+provided to add the binman definition into the devicetree in the same
way.
+One way to do this is to allow a .dtsi file to be merged in with the
generated
+devicetree.
+Note that the burden goes both ways. If a new feature is added to
U-Boot which
+needs support in another project, then the author of the U-Boot patch
must add
+any required support to the other project.
+Passing the devicetree through to Linux +---------------------------------------
+Ideally U-Boot and Linux use the same devicetree source, even though
it is
+hosted in separate projects. U-Boot adds some extra pieces, such as the +`config/` node and tags like `u-boot,dm-spl`. Linux adds some extra
pieces, such
+as `linux,default-trigger` and `linux,code`. This should not interfere
with
+each other.
+In principle it is possible for U-Boot's control devicetree to be
passed to
+Linux. This is, after all, one of the goals of devicetree and the
original
+Open Firmware project, to have the firmware provide the hardware
description to
+the Operating System.
+For boards where this approach is used, care must be taken. U-Boot
typically
+needs to 'fix up' the devicetree before passing it to Linux, e.g. to
add
+information about the memory map, about which serial console is used,
provide
+the kernel address space layout randomization (KASLR) seed or select
whether the
+console should be silenced for a faster boot.
+Fix-ups involve modifying the devicetree. If the control devicetree is
used,
+that means the control devicetree could be modified, while U-Boot is
using it.
+Removing a device and reinserting it can cause problems if the
devicetree offset
+has changed, for example, since the device will be unable to locates
its
+devicetree properties at the expected devicetree offset, which is a
fixed
+integer.
+To deal with this, it is recommended to employ one or more of the
following
+approaches:
+- Make a copy of the devicetree and 'fix up' the copy, leaving the
control
- devicetree alone
+- Enable `CONFIG_OF_LIVE` so that U-Boot makes its own copy of the
devicetree
- during relocation; fixups then happen on the original flat tree
+- Ensure that fix-ups happen after all loading has happened and U-Boot
has
- completed image verification
+In practice,the last point is typically observed, since
boot_prep_linux() is
+called just before jumping to Linux, long after signature
verification, for
+example. But it is important to make sure that this line is not
blurred,
+particularly if untrusted user data is involved.
+Devicetree use cases that must be supported +-------------------------------------------
+Regardless of how the devicetree is provided to U-Boot at runtime,
various
+U-Boot features must be fully supported. This section describes some
of these
+features and the implications for other projects.
+If U-Boot uses its own in-tree devicetree these features are supported +automatically.
+Signing with U-Boot devicetree +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+U-Boot supports signing a payload so that it can be verified to have
been
+created by a party owning a private key. This is called verified boot
in U-Boot
+(see doc/uImage.FIT/verified-boot.txt).
+Typically this works by creating a FIT and then running the `mkimage`
tool to
+add signatures for particular images. As part of this process,
`mkimage` writes
+a public key to the U-Boot devicetree, although this can be done
separately.
+See fdt_add_pubkey_ for patches for a suitable tool, for example.
+As with all configuration information, if another project is providing
the
+devicetree to U-Boot, it must provide a way to add this public key
into the
+devicetree it passes to U-Boot. This could be via a tooling option,
making use
+of `mkimage`, or allowing a .dtsi file to be merged in with what is
generated in
+the other project.
+Providing the binman image definition +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+In complex systems U-Boot must locate and make use of other firmware
components,
+such as images for the user interface, files containing peripheral
firmware,
+multiple copies of U-Boot for use with A/B boot, etc. U-Boot uses +:doc:`Binman <../package/binman>` as a standard way of putting an image +together.
+Typically this works by running binman with the devicetree as an
input, to
+create the file image. Binman then outputs an updated devicetree which
is
+packed in the firmware image, so U-Boot can access the binman
definition and
+locate all the components.
+As with all configuration information, if another project is providing
the
+devicetree to U-Boot, it must provide a way to add this binman
definition into
+the devicetree it passes to U-Boot. This could be via a tooling
option, making
+use of `binman`, or alowing a .dtsi file to be merged in with what is
generated
+in the other project.
+Protecting the devicetree +-------------------------
+U-Boot relies heavily on devicetree for correct operation. A corrupt
or invalid
+device can cause U-Boot to fail to start, behave incorrectly, crash
(e.g. if
+`CONFIG_OF_LIBFDT_ASSUME_MASK` is adjusted, or fail to boot an
Operating System.
+Within U-Boot, the devicetree is as important as any other part of the
source
+code. At ruuntime, the devicetree can be considered to be structured
rodata.
+With secure systems, care must be taken that the devicetree is valid:
+- If the code / rodata has a hash or signature, the devicetree should
also, if
- they are packaged separately.
+- If the code / rodata is write-protected when running, the devicetree
should be
- also. Note that U-Boot relocates its code and devicetree, so this is
not as
- simple as it sounds. U-Boot must write-protect these items after
relocating.
+Why does U-Boot have its nodes and properties? +----------------------------------------------
+See also :doc:`../devicetree/intro`.
+There has been pushback at the concept that U-Boot dares have its own
nodes and
+properties in the devicetree.
+Apart from these nodes and properties, U-Boot uses the same bindings
as Linux.
+A `u-boot.dtsi` file helps to keep U-Boot-specific changes in separate
files,
+making it easier to keep devicetree source files in U-Boot in sync
with Linux.
+As a counter-example, the Zephyr OS project takes a different
approach. It uses
+entirely different bindings, in general, making no effort to sync
devicetree
+source files with Linux. U-Boot strives to be compatible with Linux in
a number
+of ways, such as source code style and common APIs, to aid porting of
code
+between the projects. Devicetree is another way where U-Boot and Linux
follow a
+similar approach.
+Fundamentally, the idea that U-Boot cannot have its own tags flies in
the face
+of the devicetree specification (see dtspec_), which says:
- Nonstandard property names should specify a **unique string
prefix**, such as
- a stock ticker symbol, identifying the name of the company **or
organization**
- that defined the property. Examples:
- fsl,channel-fifo-len
- ibm,ppc-interrupt-server#s
- **linux**,network-index
+It is also fundamentally unbalanced. Linux has many tags of its own
(some 36 in
+version 5.13) and at least one Linux-specific node, even if you ignore
things
+like flash partitions which clearly provide configuration information
to Linux.
+Practically speaking there are many reasons why U-Boot has its own
nodes and
+properties. Some examples:
+- Binding every device before relocation even if it won't be used,
consumes time
- and memory: tags on each node can specify which are needed in SPL or
before
- relocation. Linux has no such constraints.
+- Requiring the full clock tree to be up and running just to get the
debug UART
- running is inefficient. It is also and self-defeating, since if that
much
- code is working properly, you probably don't need the debug UART. A
devicetree
- property to provide the UART input-clock frequency is a simple
solution.
+- U-Boot does not have a user space to provide policy and
configuration. It
- cannot do what Linux does and run programs and look up filesystems
to figure
- out how to boot.
+Why not have two devicetrees? +-----------------------------
+Setting aside the argument for restricting U-Boot from having its own
nodes and
+properties, another idea proposed is to have two devicetrees, one for
the
+U-Boot-specific bits (here called `special`) and one for everything
else (here
+called `linux`).
+On the positive side, it might quieten the discussion alluded to in
the section
+above. But there are many negatives to consider and many open
questions to
+resolve.
+- **Bindings** - Presumably the special devicetree would have its own
bindings.
- It would not be necessary to put a `u-boot,` prefix on anything.
People coming
- across the devicetree source would wonder how it fits in with the
Linux
- devicetree.
+- **Access** - U-Boot has a nice `ofnode` API for accessing the
devicetree. This
- would need to be expanded to support two trees. Features which need
to access
- both (such as a device driver which reads the special devicetree to
get some
- configuration info) could become quite confusing to read and write.
+- **Merging** - Can the two devicetree be merged if a platform desires
it? If
- so, how is this managed in tooling? Does it happen during the build,
in which
- case they are not really separate at all. Or does U-Boot merge them
at
- runtime, in which case this adds time and memory?
+- **Efficiency** - A second device tree adds more code and more code
paths. It
- requires that both be made available to the code in U-Boot, e.g. via
a
- separate pointer or argument or API. Overall the separation would
certainly
- not speed up U-Boot, nor decrease its size.
+- **Source code** - At present `u-boot.dtsi` files provide the pieces
needed for
- U-Boot for a particular board. Would we use these same files for the
special
- devicetree?
+- **Complexity** - Two devicetrees complicates the build system since
it must
- build and package them both. Errors must be reported in such a way
that it
- is obvious which one is failing.
+- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver
model
- are currently placed in the nodes they relate to. How would these
tags
- reference a node that is in a separate devicetree? What extra
validation would
- be needed?
+- **Storage** - How would the two devicetrees be stored in the image?
At present
- we simply concatenate the U-Boot binary and the devicetree. We could
add the
- special devicetree before the Linux one, so two are concatenated,
but it is
- not pretty. We could use binman to support more complex
arrangements, but only
- some boards use this at present, so it would be a big change.
+- **API** - How would another project provide two devicetree files to
U-Boot at
- runtime? Presumably this would just be too painful. But if it
doesn't, it
- would be unable to configure run-time features of U-Boot during the
boot.
+- **Confusion** - No other project has two devicetrees. U-Boot would
be in the
- unfortunate position of having to describe this fact to new users,
along with
- the (arguably contrived) reason for the arrangement.
False:
- projects in trustedfirmware.org are built to have multiple FDT
objects, some for "dynamic" configuration purposes.
Can you provided a link and I can update this.
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.ht... Bindings: for FCONF: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_pr... for FF-A: https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-b... For chain-of-trust: https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.ht...
For some code: https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fipto...
From there you can wander and see how dynamic config sections of the FIP
can contain component specific DTs. U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
- STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in
addition to operating system
As Ilias said, this is not about documentation about the current use of
DT in U-Boot, but justification of your views on DT.
If taken by the letter, I feel (may be wrong though) that your views
prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
I have gone to great efforts to document things here, as they work in U-Boot today. As you know, U-Boot supports separate control and active devicetrees.
I don't know what is an active device tree. Is it the device tree to be passed to OS?
But if you are wanting to change to multiple control trees within U-Boot, I'd say the answer is "no, thank you".
I see only one control DT. There is a possibility to store it securely in NT_FW_CONFIG section of a FIP. it also has associated signature plus hash mechanisms to attest authenticity of it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes). You can certain have a similar mechanism for binman.
If there is a use case for that, please can you be specific about what we cannot do with a combined devicetree?
Regards, Simon
Hi François,
On Tue, 26 Oct 2021 at 09:57, François Ozog francois.ozog@linaro.org wrote:
On Tue, 26 Oct 2021 at 17:27, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 08:31, François Ozog francois.ozog@linaro.org wrote:
Hi Simon,
On Tue, 26 Oct 2021 at 02:25, Simon Glass sjg@chromium.org wrote:
At present some of the ideas and techniques behind devicetree in U-Boot are assumed, implied or unsaid. Add some documentation to cover how devicetree is build, how it can be modified and the rules about using the various CONFIG_OF_... options.
[..]
+Why not have two devicetrees? +-----------------------------
+Setting aside the argument for restricting U-Boot from having its own nodes and +properties, another idea proposed is to have two devicetrees, one for the +U-Boot-specific bits (here called `special`) and one for everything else (here +called `linux`).
+On the positive side, it might quieten the discussion alluded to in the section +above. But there are many negatives to consider and many open questions to +resolve.
+- **Bindings** - Presumably the special devicetree would have its own bindings.
- It would not be necessary to put a `u-boot,` prefix on anything. People coming
- across the devicetree source would wonder how it fits in with the Linux
- devicetree.
+- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This
- would need to be expanded to support two trees. Features which need to access
- both (such as a device driver which reads the special devicetree to get some
- configuration info) could become quite confusing to read and write.
+- **Merging** - Can the two devicetree be merged if a platform desires it? If
- so, how is this managed in tooling? Does it happen during the build, in which
- case they are not really separate at all. Or does U-Boot merge them at
- runtime, in which case this adds time and memory?
+- **Efficiency** - A second device tree adds more code and more code paths. It
- requires that both be made available to the code in U-Boot, e.g. via a
- separate pointer or argument or API. Overall the separation would certainly
- not speed up U-Boot, nor decrease its size.
+- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for
- U-Boot for a particular board. Would we use these same files for the special
- devicetree?
+- **Complexity** - Two devicetrees complicates the build system since it must
- build and package them both. Errors must be reported in such a way that it
- is obvious which one is failing.
+- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model
- are currently placed in the nodes they relate to. How would these tags
- reference a node that is in a separate devicetree? What extra validation would
- be needed?
+- **Storage** - How would the two devicetrees be stored in the image? At present
- we simply concatenate the U-Boot binary and the devicetree. We could add the
- special devicetree before the Linux one, so two are concatenated, but it is
- not pretty. We could use binman to support more complex arrangements, but only
- some boards use this at present, so it would be a big change.
+- **API** - How would another project provide two devicetree files to U-Boot at
- runtime? Presumably this would just be too painful. But if it doesn't, it
- would be unable to configure run-time features of U-Boot during the boot.
+- **Confusion** - No other project has two devicetrees. U-Boot would be in the
- unfortunate position of having to describe this fact to new users, along with
- the (arguably contrived) reason for the arrangement.
False:
- projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes.
Can you provided a link and I can update this.
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.ht... Bindings: for FCONF: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_pr... for FF-A: https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-b... For chain-of-trust: https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.ht...
For some code: https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fipto... From there you can wander and see how dynamic config sections of the FIP can contain component specific DTs. U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
OK I can mention that TF-A supports multiple devicetrees if you like, but I'm not sure we are talking about the same thing.
U-Boot also supports multiple devicetrees in the build - e.g. SPL and U-Boot proper. With binman you can create several copies of them for use with A/B boot, for example. But only one is used as a control DTB by a particular U-Boot phase at a time. Do you see what I mean?
- STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system
As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT. If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
I have gone to great efforts to document things here, as they work in U-Boot today. As you know, U-Boot supports separate control and active devicetrees.
I don't know what is an active device tree. Is it the device tree to be passed to OS?
Yes that's right.
But if you are wanting to change to multiple control trees within U-Boot, I'd say the answer is "no, thank you".
I see only one control DT.
OK good.
There is a possibility to store it securely in NT_FW_CONFIG section of a FIP. it also has associated signature plus hash mechanisms to attest authenticity of it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes).
What does NT mean? I suppose FW means firmware.
It doesn't really matter where it is stored, so long as U-Boot can access it.
You can certain have a similar mechanism for binman.
Note that binman is a packaging tool. Perhaps you should add FIP support to it if FIP is going to be required too now?
What I would like, to package up the firmware for ANY board, after all the building is done in various projects:
binman -b <board>
If there is a use case for that, please can you be specific about what we cannot do with a combined devicetree?
Regards, SImon
Hi Simon,
On Wed, 27 Oct 2021 at 16:13, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 09:57, François Ozog francois.ozog@linaro.org wrote:
On Tue, 26 Oct 2021 at 17:27, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 08:31, François Ozog francois.ozog@linaro.org
wrote:
Hi Simon,
On Tue, 26 Oct 2021 at 02:25, Simon Glass sjg@chromium.org wrote:
At present some of the ideas and techniques behind devicetree in
U-Boot
are assumed, implied or unsaid. Add some documentation to cover how devicetree is build, how it can be modified and the rules about using the various CONFIG_OF_... options.
[..]
+Why not have two devicetrees? +-----------------------------
+Setting aside the argument for restricting U-Boot from having its
own nodes and
+properties, another idea proposed is to have two devicetrees, one
for the
+U-Boot-specific bits (here called `special`) and one for everything
else (here
+called `linux`).
+On the positive side, it might quieten the discussion alluded to in
the section
+above. But there are many negatives to consider and many open
questions to
+resolve.
+- **Bindings** - Presumably the special devicetree would have its
own bindings.
- It would not be necessary to put a `u-boot,` prefix on anything.
People coming
- across the devicetree source would wonder how it fits in with the
Linux
- devicetree.
+- **Access** - U-Boot has a nice `ofnode` API for accessing the
devicetree. This
- would need to be expanded to support two trees. Features which
need to access
- both (such as a device driver which reads the special devicetree
to get some
- configuration info) could become quite confusing to read and
write.
+- **Merging** - Can the two devicetree be merged if a platform
desires it? If
- so, how is this managed in tooling? Does it happen during the
build, in which
- case they are not really separate at all. Or does U-Boot merge
them at
- runtime, in which case this adds time and memory?
+- **Efficiency** - A second device tree adds more code and more
code paths. It
- requires that both be made available to the code in U-Boot, e.g.
via a
- separate pointer or argument or API. Overall the separation would
certainly
- not speed up U-Boot, nor decrease its size.
+- **Source code** - At present `u-boot.dtsi` files provide the
pieces needed for
- U-Boot for a particular board. Would we use these same files for
the special
- devicetree?
+- **Complexity** - Two devicetrees complicates the build system
since it must
- build and package them both. Errors must be reported in such a
way that it
- is obvious which one is failing.
+- **Referencing each other** - The `u-boot,dm-xxx` tags used by
driver model
- are currently placed in the nodes they relate to. How would these
tags
- reference a node that is in a separate devicetree? What extra
validation would
- be needed?
+- **Storage** - How would the two devicetrees be stored in the
image? At present
- we simply concatenate the U-Boot binary and the devicetree. We
could add the
- special devicetree before the Linux one, so two are concatenated,
but it is
- not pretty. We could use binman to support more complex
arrangements, but only
- some boards use this at present, so it would be a big change.
+- **API** - How would another project provide two devicetree files
to U-Boot at
- runtime? Presumably this would just be too painful. But if it
doesn't, it
- would be unable to configure run-time features of U-Boot during
the boot.
+- **Confusion** - No other project has two devicetrees. U-Boot
would be in the
- unfortunate position of having to describe this fact to new
users, along with
- the (arguably contrived) reason for the arrangement.
False:
- projects in trustedfirmware.org are built to have multiple FDT
objects, some for "dynamic" configuration purposes.
Can you provided a link and I can update this.
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.ht...
Bindings: for FCONF:
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_pr...
for FF-A:
https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-b...
For chain-of-trust:
https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.ht...
For some code:
https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fipto...
From there you can wander and see how dynamic config sections of the FIP
can contain component specific DTs.
U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
OK I can mention that TF-A supports multiple devicetrees if you like, but I'm not sure we are talking about the same thing.
If I take a possible scenario: OP-TEE to deal with 3 different device
trees: - the one that will be passed to the OS and for which it may want to do some fixups - the one that it is using to run (it may have secure devices that are entirely not visible to any normal world OS) - the one that it gets from the FIP and contains runtime configuration parameters, accessed through FCONF library)
U-Boot also supports multiple devicetrees in the build - e.g. SPL and U-Boot proper. With binman you can create several copies of them for use with A/B boot, for example. But only one is used as a control DTB by a particular U-Boot phase at a time. Do you see what I mean?
- STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in
addition to operating system
As Ilias said, this is not about documentation about the current use
of DT in U-Boot, but justification of your views on DT.
If taken by the letter, I feel (may be wrong though) that your views
prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
I have gone to great efforts to document things here, as they work in U-Boot today. As you know, U-Boot supports separate control and active devicetrees.
I don't know what is an active device tree. Is it the device tree to be
passed to OS?
Yes that's right.
But if you are wanting to change to multiple control trees within U-Boot, I'd say the answer is "no, thank you".
I see only one control DT.
OK good.
There is a possibility to store it securely in NT_FW_CONFIG section of a
FIP. it also has associated signature plus hash mechanisms to attest authenticity of it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes).
What does NT mean? I suppose FW means firmware.
Non Trusted; it means normal world as opposed to secure world. It feels unfortunate to say non trusted while it is trusted but running outside secure world ;-)
It doesn't really matter where it is stored, so long as U-Boot can access it.
You can certain have a similar mechanism for binman.
Note that binman is a packaging tool. Perhaps you should add FIP support to it if FIP is going to be required too now?
There may be a need for a FIP explanation. I'll check with other guys to
propose text.
What I would like, to package up the firmware for ANY board, after all the building is done in various projects:
binman -b <board>
FIP deals with a number of firmwares like the SCP and MCP ones running on
other micro-controllers of a board. So in a sense it is an arm targeted tool. If you want to package firmware for arm boards with binman you will have to deal with those firmwares as well as secure world and its trusted services as secure partitions that are being developed (including when virtualization is in operation in the secure world). So in a word, trying to do this is a big undertaking, but you can try. In a short term future (see Alibaba and Marvell announcements) you will have to deal with Arm v9 realms and associated firmware.
If there is a use case for that, please can you be specific about what we cannot do with a combined devicetree?
Regards, SImon
Hi François,
On Wed, 27 Oct 2021 at 09:38, François Ozog francois.ozog@linaro.org wrote:
Hi Simon,
On Wed, 27 Oct 2021 at 16:13, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 09:57, François Ozog francois.ozog@linaro.org wrote:
On Tue, 26 Oct 2021 at 17:27, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 08:31, François Ozog francois.ozog@linaro.org wrote:
Hi Simon,
On Tue, 26 Oct 2021 at 02:25, Simon Glass sjg@chromium.org wrote:
At present some of the ideas and techniques behind devicetree in U-Boot are assumed, implied or unsaid. Add some documentation to cover how devicetree is build, how it can be modified and the rules about using the various CONFIG_OF_... options.
[..]
+Why not have two devicetrees? +-----------------------------
+Setting aside the argument for restricting U-Boot from having its own nodes and +properties, another idea proposed is to have two devicetrees, one for the +U-Boot-specific bits (here called `special`) and one for everything else (here +called `linux`).
+On the positive side, it might quieten the discussion alluded to in the section +above. But there are many negatives to consider and many open questions to +resolve.
+- **Bindings** - Presumably the special devicetree would have its own bindings.
- It would not be necessary to put a `u-boot,` prefix on anything. People coming
- across the devicetree source would wonder how it fits in with the Linux
- devicetree.
+- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This
- would need to be expanded to support two trees. Features which need to access
- both (such as a device driver which reads the special devicetree to get some
- configuration info) could become quite confusing to read and write.
+- **Merging** - Can the two devicetree be merged if a platform desires it? If
- so, how is this managed in tooling? Does it happen during the build, in which
- case they are not really separate at all. Or does U-Boot merge them at
- runtime, in which case this adds time and memory?
+- **Efficiency** - A second device tree adds more code and more code paths. It
- requires that both be made available to the code in U-Boot, e.g. via a
- separate pointer or argument or API. Overall the separation would certainly
- not speed up U-Boot, nor decrease its size.
+- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for
- U-Boot for a particular board. Would we use these same files for the special
- devicetree?
+- **Complexity** - Two devicetrees complicates the build system since it must
- build and package them both. Errors must be reported in such a way that it
- is obvious which one is failing.
+- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model
- are currently placed in the nodes they relate to. How would these tags
- reference a node that is in a separate devicetree? What extra validation would
- be needed?
+- **Storage** - How would the two devicetrees be stored in the image? At present
- we simply concatenate the U-Boot binary and the devicetree. We could add the
- special devicetree before the Linux one, so two are concatenated, but it is
- not pretty. We could use binman to support more complex arrangements, but only
- some boards use this at present, so it would be a big change.
+- **API** - How would another project provide two devicetree files to U-Boot at
- runtime? Presumably this would just be too painful. But if it doesn't, it
- would be unable to configure run-time features of U-Boot during the boot.
+- **Confusion** - No other project has two devicetrees. U-Boot would be in the
- unfortunate position of having to describe this fact to new users, along with
- the (arguably contrived) reason for the arrangement.
False:
- projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes.
Can you provided a link and I can update this.
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.ht... Bindings: for FCONF: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_pr... for FF-A: https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-b... For chain-of-trust: https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.ht...
For some code: https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fipto... From there you can wander and see how dynamic config sections of the FIP can contain component specific DTs. U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
OK I can mention that TF-A supports multiple devicetrees if you like, but I'm not sure we are talking about the same thing.
If I take a possible scenario: OP-TEE to deal with 3 different device trees:
- the one that will be passed to the OS and for which it may want to do some fixups
- the one that it is using to run (it may have secure devices that are entirely not visible to any normal world OS)
- the one that it gets from the FIP and contains runtime configuration parameters, accessed through FCONF library)
U-Boot also supports multiple devicetrees in the build - e.g. SPL and U-Boot proper. With binman you can create several copies of them for use with A/B boot, for example. But only one is used as a control DTB by a particular U-Boot phase at a time. Do you see what I mean?
- STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system
As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT. If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
I have gone to great efforts to document things here, as they work in U-Boot today. As you know, U-Boot supports separate control and active devicetrees.
I don't know what is an active device tree. Is it the device tree to be passed to OS?
Yes that's right.
But if you are wanting to change to multiple control trees within U-Boot, I'd say the answer is "no, thank you".
I see only one control DT.
OK good.
There is a possibility to store it securely in NT_FW_CONFIG section of a FIP. it also has associated signature plus hash mechanisms to attest authenticity of it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes).
What does NT mean? I suppose FW means firmware.
Non Trusted; it means normal world as opposed to secure world. It feels unfortunate to say non trusted while it is trusted but running outside secure world ;-)
OK, good, so long as it doesn't mean Windows NT I am happy.
It doesn't really matter where it is stored, so long as U-Boot can access it.
You can certain have a similar mechanism for binman.
Note that binman is a packaging tool. Perhaps you should add FIP support to it if FIP is going to be required too now?
There may be a need for a FIP explanation. I'll check with other guys to propose text.
I mean add an entry type to binman for FIP. It supports CBFS already, for example.
What I would like, to package up the firmware for ANY board, after all the building is done in various projects:
binman -b <board>
FIP deals with a number of firmwares like the SCP and MCP ones running on other micro-controllers of a board. So in a sense it is an arm targeted tool. If you want to package firmware for arm boards with binman you will have to deal with those firmwares as well as secure world and its trusted services as secure partitions that are being developed (including when virtualization is in operation in the secure world). So in a word, trying to do this is a big undertaking, but you can try.
Binman supports adding firmware for microcontrollers. For example, see here:
https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/dts/flashmap-16mb-x86...
That is a Chrome OS EC binary, one of three in the image.
This is not ARM-specific. That image is actually for x86 Apollo Lake.
In a short term future (see Alibaba and Marvell announcements) you will have to deal with Arm v9 realms and associated firmware.
Why me? Perhaps Linaro could take this on instead of working in a separate tool and domain? You guys could really pull things together and reduce the fragmentation, if you took it on.
Honestly it is hard enough to even get Linaro people to write a test for code they have written. What gives?
If there is a use case for that, please can you be specific about what we cannot do with a combined devicetree?
Regards, SImon
On Wed, 27 Oct 2021 at 21:33, Simon Glass sjg@chromium.org wrote:
Hi François,
On Wed, 27 Oct 2021 at 09:38, François Ozog francois.ozog@linaro.org wrote:
Hi Simon,
On Wed, 27 Oct 2021 at 16:13, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 09:57, François Ozog francois.ozog@linaro.org wrote:
On Tue, 26 Oct 2021 at 17:27, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 08:31, François Ozog francois.ozog@linaro.org wrote:
Hi Simon,
On Tue, 26 Oct 2021 at 02:25, Simon Glass sjg@chromium.org wrote: > > At present some of the ideas and techniques behind devicetree in U-Boot > are assumed, implied or unsaid. Add some documentation to cover how > devicetree is build, how it can be modified and the rules about using > the various CONFIG_OF_... options. >
[..]
> +Why not have two devicetrees? > +----------------------------- > + > +Setting aside the argument for restricting U-Boot from having its own nodes and > +properties, another idea proposed is to have two devicetrees, one for the > +U-Boot-specific bits (here called `special`) and one for everything else (here > +called `linux`). > + > +On the positive side, it might quieten the discussion alluded to in the section > +above. But there are many negatives to consider and many open questions to > +resolve. > + > +- **Bindings** - Presumably the special devicetree would have its own bindings. > + It would not be necessary to put a `u-boot,` prefix on anything. People coming > + across the devicetree source would wonder how it fits in with the Linux > + devicetree. > + > +- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This > + would need to be expanded to support two trees. Features which need to access > + both (such as a device driver which reads the special devicetree to get some > + configuration info) could become quite confusing to read and write. > + > +- **Merging** - Can the two devicetree be merged if a platform desires it? If > + so, how is this managed in tooling? Does it happen during the build, in which > + case they are not really separate at all. Or does U-Boot merge them at > + runtime, in which case this adds time and memory? > + > +- **Efficiency** - A second device tree adds more code and more code paths. It > + requires that both be made available to the code in U-Boot, e.g. via a > + separate pointer or argument or API. Overall the separation would certainly > + not speed up U-Boot, nor decrease its size. > + > +- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for > + U-Boot for a particular board. Would we use these same files for the special > + devicetree? > + > +- **Complexity** - Two devicetrees complicates the build system since it must > + build and package them both. Errors must be reported in such a way that it > + is obvious which one is failing. > + > +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model > + are currently placed in the nodes they relate to. How would these tags > + reference a node that is in a separate devicetree? What extra validation would > + be needed? > + > +- **Storage** - How would the two devicetrees be stored in the image? At present > + we simply concatenate the U-Boot binary and the devicetree. We could add the > + special devicetree before the Linux one, so two are concatenated, but it is > + not pretty. We could use binman to support more complex arrangements, but only > + some boards use this at present, so it would be a big change. > + > +- **API** - How would another project provide two devicetree files to U-Boot at > + runtime? Presumably this would just be too painful. But if it doesn't, it > + would be unable to configure run-time features of U-Boot during the boot. > + > +- **Confusion** - No other project has two devicetrees. U-Boot would be in the > + unfortunate position of having to describe this fact to new users, along with > + the (arguably contrived) reason for the arrangement. > +
False:
- projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes.
Can you provided a link and I can update this.
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.ht... Bindings: for FCONF: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_pr... for FF-A: https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-b... For chain-of-trust: https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.ht...
For some code: https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fipto... From there you can wander and see how dynamic config sections of the FIP can contain component specific DTs. U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
OK I can mention that TF-A supports multiple devicetrees if you like, but I'm not sure we are talking about the same thing.
If I take a possible scenario: OP-TEE to deal with 3 different device trees:
- the one that will be passed to the OS and for which it may want to do some fixups
- the one that it is using to run (it may have secure devices that are entirely not visible to any normal world OS)
- the one that it gets from the FIP and contains runtime configuration parameters, accessed through FCONF library)
U-Boot also supports multiple devicetrees in the build - e.g. SPL and U-Boot proper. With binman you can create several copies of them for use with A/B boot, for example. But only one is used as a control DTB by a particular U-Boot phase at a time. Do you see what I mean?
- STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system
As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT. If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
I have gone to great efforts to document things here, as they work in U-Boot today. As you know, U-Boot supports separate control and active devicetrees.
I don't know what is an active device tree. Is it the device tree to be passed to OS?
Yes that's right.
But if you are wanting to change to multiple control trees within U-Boot, I'd say the answer is "no, thank you".
I see only one control DT.
OK good.
There is a possibility to store it securely in NT_FW_CONFIG section of a FIP. it also has associated signature plus hash mechanisms to attest authenticity of it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes).
What does NT mean? I suppose FW means firmware.
Non Trusted; it means normal world as opposed to secure world. It feels unfortunate to say non trusted while it is trusted but running outside secure world ;-)
OK, good, so long as it doesn't mean Windows NT I am happy.
It doesn't really matter where it is stored, so long as U-Boot can access it.
You can certain have a similar mechanism for binman.
Note that binman is a packaging tool. Perhaps you should add FIP support to it if FIP is going to be required too now?
There may be a need for a FIP explanation. I'll check with other guys to propose text.
I mean add an entry type to binman for FIP. It supports CBFS already, for example.
What I would like, to package up the firmware for ANY board, after all the building is done in various projects:
binman -b <board>
FIP deals with a number of firmwares like the SCP and MCP ones running on other micro-controllers of a board. So in a sense it is an arm targeted tool. If you want to package firmware for arm boards with binman you will have to deal with those firmwares as well as secure world and its trusted services as secure partitions that are being developed (including when virtualization is in operation in the secure world). So in a word, trying to do this is a big undertaking, but you can try.
Binman supports adding firmware for microcontrollers. For example, see here:
https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/dts/flashmap-16mb-x86...
That is a Chrome OS EC binary, one of three in the image.
This is not ARM-specific. That image is actually for x86 Apollo Lake.
In a short term future (see Alibaba and Marvell announcements) you will have to deal with Arm v9 realms and associated firmware.
Why me? Perhaps Linaro could take this on instead of working in a separate tool and domain? You guys could really pull things together and reduce the fragmentation, if you took it on.
Honestly it is hard enough to even get Linaro people to write a test for code they have written. What gives?
That's completely inaccurate. We've added selftests for *every* single feature we've sent for EFI up to now. Functionality wise the past 2 years we've added - EFI variables - EFI secure boot - capsule updates - initrd loading - efi TCG protocol - ESRT tables - RNG protocol
5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() ce62b0f8f45f1 test/py: Fix efidebug related tests 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule de489d82e3189 test: test the ESRT creation 57be8cdce35 test/py: efi_secboot: small rework for adding a new test e1174c566a61c test/py: efi_secboot: add test for intermediate certificates 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
and I am pretty sure I am forgetting more on functionality and selftests.
So basically we've either contributed new selftests for *everything* we've or fixed the existing ones. The only thing that's not merged is the TCG selftests which are on upstream review.
Regards /Ilias
Hi Ilias,
On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Wed, 27 Oct 2021 at 21:33, Simon Glass sjg@chromium.org wrote:
Hi François,
On Wed, 27 Oct 2021 at 09:38, François Ozog francois.ozog@linaro.org wrote:
Hi Simon,
On Wed, 27 Oct 2021 at 16:13, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 09:57, François Ozog francois.ozog@linaro.org wrote:
On Tue, 26 Oct 2021 at 17:27, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 08:31, François Ozog francois.ozog@linaro.org wrote: > > Hi Simon, > > On Tue, 26 Oct 2021 at 02:25, Simon Glass sjg@chromium.org wrote: >> >> At present some of the ideas and techniques behind devicetree in U-Boot >> are assumed, implied or unsaid. Add some documentation to cover how >> devicetree is build, how it can be modified and the rules about using >> the various CONFIG_OF_... options. >>
[..]
>> +Why not have two devicetrees? >> +----------------------------- >> + >> +Setting aside the argument for restricting U-Boot from having its own nodes and >> +properties, another idea proposed is to have two devicetrees, one for the >> +U-Boot-specific bits (here called `special`) and one for everything else (here >> +called `linux`). >> + >> +On the positive side, it might quieten the discussion alluded to in the section >> +above. But there are many negatives to consider and many open questions to >> +resolve. >> + >> +- **Bindings** - Presumably the special devicetree would have its own bindings. >> + It would not be necessary to put a `u-boot,` prefix on anything. People coming >> + across the devicetree source would wonder how it fits in with the Linux >> + devicetree. >> + >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This >> + would need to be expanded to support two trees. Features which need to access >> + both (such as a device driver which reads the special devicetree to get some >> + configuration info) could become quite confusing to read and write. >> + >> +- **Merging** - Can the two devicetree be merged if a platform desires it? If >> + so, how is this managed in tooling? Does it happen during the build, in which >> + case they are not really separate at all. Or does U-Boot merge them at >> + runtime, in which case this adds time and memory? >> + >> +- **Efficiency** - A second device tree adds more code and more code paths. It >> + requires that both be made available to the code in U-Boot, e.g. via a >> + separate pointer or argument or API. Overall the separation would certainly >> + not speed up U-Boot, nor decrease its size. >> + >> +- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for >> + U-Boot for a particular board. Would we use these same files for the special >> + devicetree? >> + >> +- **Complexity** - Two devicetrees complicates the build system since it must >> + build and package them both. Errors must be reported in such a way that it >> + is obvious which one is failing. >> + >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model >> + are currently placed in the nodes they relate to. How would these tags >> + reference a node that is in a separate devicetree? What extra validation would >> + be needed? >> + >> +- **Storage** - How would the two devicetrees be stored in the image? At present >> + we simply concatenate the U-Boot binary and the devicetree. We could add the >> + special devicetree before the Linux one, so two are concatenated, but it is >> + not pretty. We could use binman to support more complex arrangements, but only >> + some boards use this at present, so it would be a big change. >> + >> +- **API** - How would another project provide two devicetree files to U-Boot at >> + runtime? Presumably this would just be too painful. But if it doesn't, it >> + would be unable to configure run-time features of U-Boot during the boot. >> + >> +- **Confusion** - No other project has two devicetrees. U-Boot would be in the >> + unfortunate position of having to describe this fact to new users, along with >> + the (arguably contrived) reason for the arrangement. >> + > > False: > 1) projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes.
Can you provided a link and I can update this.
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.ht... Bindings: for FCONF: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_pr... for FF-A: https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-b... For chain-of-trust: https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.ht...
For some code: https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fipto... From there you can wander and see how dynamic config sections of the FIP can contain component specific DTs. U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
OK I can mention that TF-A supports multiple devicetrees if you like, but I'm not sure we are talking about the same thing.
If I take a possible scenario: OP-TEE to deal with 3 different device trees:
- the one that will be passed to the OS and for which it may want to do some fixups
- the one that it is using to run (it may have secure devices that are entirely not visible to any normal world OS)
- the one that it gets from the FIP and contains runtime configuration parameters, accessed through FCONF library)
U-Boot also supports multiple devicetrees in the build - e.g. SPL and U-Boot proper. With binman you can create several copies of them for use with A/B boot, for example. But only one is used as a control DTB by a particular U-Boot phase at a time. Do you see what I mean?
> 2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system > As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT. > If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
I have gone to great efforts to document things here, as they work in U-Boot today. As you know, U-Boot supports separate control and active devicetrees.
I don't know what is an active device tree. Is it the device tree to be passed to OS?
Yes that's right.
But if you are wanting to change to multiple control trees within U-Boot, I'd say the answer is "no, thank you".
I see only one control DT.
OK good.
There is a possibility to store it securely in NT_FW_CONFIG section of a FIP. it also has associated signature plus hash mechanisms to attest authenticity of it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes).
What does NT mean? I suppose FW means firmware.
Non Trusted; it means normal world as opposed to secure world. It feels unfortunate to say non trusted while it is trusted but running outside secure world ;-)
OK, good, so long as it doesn't mean Windows NT I am happy.
It doesn't really matter where it is stored, so long as U-Boot can access it.
You can certain have a similar mechanism for binman.
Note that binman is a packaging tool. Perhaps you should add FIP support to it if FIP is going to be required too now?
There may be a need for a FIP explanation. I'll check with other guys to propose text.
I mean add an entry type to binman for FIP. It supports CBFS already, for example.
What I would like, to package up the firmware for ANY board, after all the building is done in various projects:
binman -b <board>
FIP deals with a number of firmwares like the SCP and MCP ones running on other micro-controllers of a board. So in a sense it is an arm targeted tool. If you want to package firmware for arm boards with binman you will have to deal with those firmwares as well as secure world and its trusted services as secure partitions that are being developed (including when virtualization is in operation in the secure world). So in a word, trying to do this is a big undertaking, but you can try.
Binman supports adding firmware for microcontrollers. For example, see here:
https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/dts/flashmap-16mb-x86...
That is a Chrome OS EC binary, one of three in the image.
This is not ARM-specific. That image is actually for x86 Apollo Lake.
In a short term future (see Alibaba and Marvell announcements) you will have to deal with Arm v9 realms and associated firmware.
Why me? Perhaps Linaro could take this on instead of working in a separate tool and domain? You guys could really pull things together and reduce the fragmentation, if you took it on.
Honestly it is hard enough to even get Linaro people to write a test for code they have written. What gives?
That's completely inaccurate. We've added selftests for *every* single feature we've sent for EFI up to now. Functionality wise the past 2 years we've added
- EFI variables
- EFI secure boot
- capsule updates
- initrd loading
- efi TCG protocol
- ESRT tables
- RNG protocol
5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() ce62b0f8f45f1 test/py: Fix efidebug related tests 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule de489d82e3189 test: test the ESRT creation 57be8cdce35 test/py: efi_secboot: small rework for adding a new test e1174c566a61c test/py: efi_secboot: add test for intermediate certificates 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
and I am pretty sure I am forgetting more on functionality and selftests.
So basically we've either contributed new selftests for *everything* we've or fixed the existing ones. The only thing that's not merged is the TCG selftests which are on upstream review.
Er, I didn't say or mean that no tests were written, just that there is too much push-back on it. Heinrich put a huge amount of effort into the tests and basically created a strong base for it. Congrats and huge kudos to him. As to Linaro, no offence intended, and it is great that all these tests have been added. Thank you for your efforts and it is very helpful. But I think you miss my point. Or perhaps you don't even agree with it? I sent an email about this on one patch just a day or two ago.
As to the leadership side (my bigger point), Linaro is leading us all down this fragmented path, with TF-A, FIP, more and more binaries and larger firmware diagrams. Or do you disagree with that too?
I'm sorry if you find this a bit sharp. But someone needs to be pointing these things out. I don't know who else is doing so. ARM firmware has got noticeably more complicated and fragmented in the last five years, hasn't it? What can Linaro do to address that? I am very happy to help and provide part of the solution, but it needs a shared vision.
It's not even just a Linaro/ARM problem. On the x86 side it is fast becoming a living nightmare.
Perhaps the problem here is just the pandemic response and the inability for people to get into a room and brainstorm / collaborate / hack on ideas? I know you have made big efforts to engage, Ilias. We have spoken many times and I'm sure f2f would be easier.
Regards, Simon
Hi Simon,
[...]
Why me? Perhaps Linaro could take this on instead of working in a separate tool and domain? You guys could really pull things together and reduce the fragmentation, if you took it on.
Honestly it is hard enough to even get Linaro people to write a test for code they have written. What gives?
That's completely inaccurate. We've added selftests for *every* single feature we've sent for EFI up to now. Functionality wise the past 2 years we've added
- EFI variables
- EFI secure boot
- capsule updates
- initrd loading
- efi TCG protocol
- ESRT tables
- RNG protocol
5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() ce62b0f8f45f1 test/py: Fix efidebug related tests 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule de489d82e3189 test: test the ESRT creation 57be8cdce35 test/py: efi_secboot: small rework for adding a new test e1174c566a61c test/py: efi_secboot: add test for intermediate certificates 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
and I am pretty sure I am forgetting more on functionality and selftests.
So basically we've either contributed new selftests for *everything* we've or fixed the existing ones. The only thing that's not merged is the TCG selftests which are on upstream review.
Er, I didn't say or mean that no tests were written, just that there is too much push-back on it. Heinrich put a huge amount of effort into
There's no pushback at all, apart from the TPM one. (and for a very good reason I've explained over and over again). In fact we add the sefltests as part of our patchsets.
the tests and basically created a strong base for it. Congrats and huge kudos to him. As to Linaro, no offence intended, and it is great that all these tests have been added. Thank you for your efforts and it is very helpful. But I think you miss my point. Or perhaps you don't even agree with it? I sent an email about this on one patch just a day or two ago.
I guess you mean [1]. I've lost count of how many times I responded to this. Threads [2], [3] and [4] are just a few examples, so I just got tired or replying the same thing over and over.
So bottom line, we are contributing selftests as always, we just don't agree with the way *you* want this specific TPM test, trying to force us into sandbox. So instead of respecting what we have (which btw is acceptable from u-boot's perspective and cleans up a lot of the TPM crud along the way), you went ahead making misleading statements on the selftests we contribute, in general. What's even more annoying is that, as I showed you, we pretty much add a selftest for *every* feature we add. Excellent ... that's certainly ... encouraging ... and very productive.
As to the leadership side (my bigger point), Linaro is leading us all down this fragmented path, with TF-A, FIP, more and more binaries and larger firmware diagrams. Or do you disagree with that too?
Of course I disagree. People decided not to use SPL for their own reasons. I am certainly not qualified to answer why Arm choose to do that, but it seems to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure U-Boot is compatible and remains the de-facto choice for embedded boot loaders playing nicely with all the new FSBLs come up with. If you cosinder SPL and U-Boot the center of the known universe, we certainly view things differently. FWIW it's *our* work mostly that made U-Boot SystemReady compliant, which is something Arm pushes for [5].
I'm sorry if you find this a bit sharp.
Which part? The first one wrt to selftests is not sharp. It's manipulative and utterly unacceptable for me, not to mention entirely fabricated.
The latter on bootloading fragmentation, I am always happy to discuss.
But someone needs to be pointing these things out. I don't know who else is doing so. ARM firmware has got noticeably more complicated and fragmented in the last five years, hasn't it? What can Linaro do to address that? I am very happy to help and provide part of the solution, but it needs a shared vision.
There's a TF-A mailing list, we can certainly engage there and try to align our ideas/designs.
It's not even just a Linaro/ARM problem. On the x86 side it is fast becoming a living nightmare.
Perhaps the problem here is just the pandemic response and the inability for people to get into a room and brainstorm / collaborate / hack on ideas? I know you have made big efforts to engage, Ilias. We have spoken many times and I'm sure f2f would be easier.
It's not even just a Linaro/ARM problem. On the x86 side it is fast becoming a living nightmare.
Perhaps the problem here is just the pandemic response and the inability for people to get into a room and brainstorm / collaborate / hack on ideas? I know you have made big efforts to engage, Ilias. We have spoken many times and I'm sure f2f would be easier.
Maybe, hopefully travelling will restart soon.
[1] https://lore.kernel.org/u-boot/CAPnjgZ2mmcUKz0v=ysSvf17c6ab++-hEpO4rc0OeeAEz... [2] https://lore.kernel.org/u-boot/YVdlvpThuqr8jksL@apalos.home/ [3] https://lore.kernel.org/u-boot/CAC_iWjLWxPyEwPpG7v=1U1sxLOD4LXF+Vm+cGTHom9Mp... [4] https://lore.kernel.org/u-boot/YVGGRqgVAiHvd1aR@apalos.home/ [5] https://www.arm.com/why-arm/architecture/systems/systemready-certification-p...
Regards /Ilias
On Fri, Oct 29, 2021 at 01:20:52PM +0300, Ilias Apalodimas wrote:
Hi Simon,
[...]
Why me? Perhaps Linaro could take this on instead of working in a separate tool and domain? You guys could really pull things together and reduce the fragmentation, if you took it on.
Honestly it is hard enough to even get Linaro people to write a test for code they have written. What gives?
That's completely inaccurate. We've added selftests for *every* single feature we've sent for EFI up to now. Functionality wise the past 2 years we've added
- EFI variables
- EFI secure boot
- capsule updates
- initrd loading
- efi TCG protocol
- ESRT tables
- RNG protocol
5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() ce62b0f8f45f1 test/py: Fix efidebug related tests 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule de489d82e3189 test: test the ESRT creation 57be8cdce35 test/py: efi_secboot: small rework for adding a new test e1174c566a61c test/py: efi_secboot: add test for intermediate certificates 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
and I am pretty sure I am forgetting more on functionality and selftests.
So basically we've either contributed new selftests for *everything* we've or fixed the existing ones. The only thing that's not merged is the TCG selftests which are on upstream review.
Er, I didn't say or mean that no tests were written, just that there is too much push-back on it. Heinrich put a huge amount of effort into
There's no pushback at all, apart from the TPM one. (and for a very good reason I've explained over and over again). In fact we add the sefltests as part of our patchsets.
And, for that set of TPM things, I agree with NOT making sandbox the requirement there. As QEMU is able to provide a TPM that will see real world usage, that's what we need to validate against primarily.
the tests and basically created a strong base for it. Congrats and huge kudos to him. As to Linaro, no offence intended, and it is great that all these tests have been added. Thank you for your efforts and it is very helpful. But I think you miss my point. Or perhaps you don't even agree with it? I sent an email about this on one patch just a day or two ago.
I guess you mean [1]. I've lost count of how many times I responded to this. Threads [2], [3] and [4] are just a few examples, so I just got tired or replying the same thing over and over.
So bottom line, we are contributing selftests as always, we just don't agree with the way *you* want this specific TPM test, trying to force us into sandbox. So instead of respecting what we have (which btw is acceptable from u-boot's perspective and cleans up a lot of the TPM crud along the way), you went ahead making misleading statements on the selftests we contribute, in general. What's even more annoying is that, as I showed you, we pretty much add a selftest for *every* feature we add. Excellent ... that's certainly ... encouraging ... and very productive.
As to the leadership side (my bigger point), Linaro is leading us all down this fragmented path, with TF-A, FIP, more and more binaries and larger firmware diagrams. Or do you disagree with that too?
Of course I disagree. People decided not to use SPL for their own reasons. I am certainly not qualified to answer why Arm choose to do that, but it seems to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure U-Boot is compatible and remains the de-facto choice for embedded boot loaders playing nicely with all the new FSBLs come up with. If you cosinder SPL and U-Boot the center of the known universe, we certainly view things differently. FWIW it's *our* work mostly that made U-Boot SystemReady compliant, which is something Arm pushes for [5].
Let me say for the record that I am appreciative of the fact the Linaro has been putting so much effort in to U-Boot, both in terms of tests and also in general SystemReady compliance work.
Hi Ilias,
On Fri, 29 Oct 2021 at 04:20, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
[...]
Why me? Perhaps Linaro could take this on instead of working in a separate tool and domain? You guys could really pull things together and reduce the fragmentation, if you took it on.
Honestly it is hard enough to even get Linaro people to write a test for code they have written. What gives?
That's completely inaccurate. We've added selftests for *every* single feature we've sent for EFI up to now. Functionality wise the past 2 years we've added
- EFI variables
- EFI secure boot
- capsule updates
- initrd loading
- efi TCG protocol
- ESRT tables
- RNG protocol
5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() ce62b0f8f45f1 test/py: Fix efidebug related tests 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule de489d82e3189 test: test the ESRT creation 57be8cdce35 test/py: efi_secboot: small rework for adding a new test e1174c566a61c test/py: efi_secboot: add test for intermediate certificates 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
and I am pretty sure I am forgetting more on functionality and selftests.
So basically we've either contributed new selftests for *everything* we've or fixed the existing ones. The only thing that's not merged is the TCG selftests which are on upstream review.
Er, I didn't say or mean that no tests were written, just that there is too much push-back on it. Heinrich put a huge amount of effort into
There's no pushback at all, apart from the TPM one. (and for a very good reason I've explained over and over again). In fact we add the sefltests as part of our patchsets.
the tests and basically created a strong base for it. Congrats and huge kudos to him. As to Linaro, no offence intended, and it is great that all these tests have been added. Thank you for your efforts and it is very helpful. But I think you miss my point. Or perhaps you don't even agree with it? I sent an email about this on one patch just a day or two ago.
I guess you mean [1]. I've lost count of how many times I responded to this. Threads [2], [3] and [4] are just a few examples, so I just got tired or replying the same thing over and over.
So bottom line, we are contributing selftests as always, we just don't agree with the way *you* want this specific TPM test, trying to force us into sandbox. So instead of respecting what we have (which btw is acceptable from u-boot's perspective and cleans up a lot of the TPM crud along the way), you went ahead making misleading statements on the selftests we contribute, in general. What's even more annoying is that, as I showed you, we pretty much add a selftest for *every* feature we add. Excellent ... that's certainly ... encouraging ... and very productive.
As to the leadership side (my bigger point), Linaro is leading us all down this fragmented path, with TF-A, FIP, more and more binaries and larger firmware diagrams. Or do you disagree with that too?
Of course I disagree. People decided not to use SPL for their own reasons. I am certainly not qualified to answer why Arm choose to do that, but it seems to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure U-Boot is compatible and remains the de-facto choice for embedded boot loaders playing nicely with all the new FSBLs come up with. If you cosinder SPL and U-Boot the center of the known universe, we certainly view things differently. FWIW it's *our* work mostly that made U-Boot SystemReady compliant, which is something Arm pushes for [5].
I'm sorry if you find this a bit sharp.
Which part? The first one wrt to selftests is not sharp. It's manipulative and utterly unacceptable for me, not to mention entirely fabricated.
The latter on bootloading fragmentation, I am always happy to discuss.
My comment was about the push-back I feel I have received when requesting tests. It was a poor choice of words since it suggests this is an ongoing problem when in fact many tests have been written. So I would like to withdraw that and I am sorry for saying that and for upsetting you. I certainly agree that Linaro has written lots of tests and this is great. Thank you to you and Linaro for that. The business of how the tests are written can be handled in other threads.
But someone needs to be pointing these things out. I don't know who else is doing so. ARM firmware has got noticeably more complicated and fragmented in the last five years, hasn't it? What can Linaro do to address that? I am very happy to help and provide part of the solution, but it needs a shared vision.
There's a TF-A mailing list, we can certainly engage there and try to align our ideas/designs.
It's not even just a Linaro/ARM problem. On the x86 side it is fast becoming a living nightmare.
Perhaps the problem here is just the pandemic response and the inability for people to get into a room and brainstorm / collaborate / hack on ideas? I know you have made big efforts to engage, Ilias. We have spoken many times and I'm sure f2f would be easier.
It's not even just a Linaro/ARM problem. On the x86 side it is fast becoming a living nightmare.
Perhaps the problem here is just the pandemic response and the inability for people to get into a room and brainstorm / collaborate / hack on ideas? I know you have made big efforts to engage, Ilias. We have spoken many times and I'm sure f2f would be easier.
Maybe, hopefully travelling will restart soon.
I think the whole issue in this thread comes down to a matter of alignment.
As you can tell, I am frustrated with where things are headed and hope we can course-correct at some point.
Regards, Simon
[1] https://lore.kernel.org/u-boot/CAPnjgZ2mmcUKz0v=ysSvf17c6ab++-hEpO4rc0OeeAEz... [2] https://lore.kernel.org/u-boot/YVdlvpThuqr8jksL@apalos.home/ [3] https://lore.kernel.org/u-boot/CAC_iWjLWxPyEwPpG7v=1U1sxLOD4LXF+Vm+cGTHom9Mp... [4] https://lore.kernel.org/u-boot/YVGGRqgVAiHvd1aR@apalos.home/ [5] https://www.arm.com/why-arm/architecture/systems/systemready-certification-p...
Regards /Ilias
Hi Simon,
[...]
Why me? Perhaps Linaro could take this on instead of working in a separate tool and domain? You guys could really pull things together and reduce the fragmentation, if you took it on.
Honestly it is hard enough to even get Linaro people to write a test for code they have written. What gives?
That's completely inaccurate. We've added selftests for *every* single feature we've sent for EFI up to now. Functionality wise the past 2 years we've added
- EFI variables
- EFI secure boot
- capsule updates
- initrd loading
- efi TCG protocol
- ESRT tables
- RNG protocol
5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() ce62b0f8f45f1 test/py: Fix efidebug related tests 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule de489d82e3189 test: test the ESRT creation 57be8cdce35 test/py: efi_secboot: small rework for adding a new test e1174c566a61c test/py: efi_secboot: add test for intermediate certificates 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
and I am pretty sure I am forgetting more on functionality and selftests.
So basically we've either contributed new selftests for *everything* we've or fixed the existing ones. The only thing that's not merged is the TCG selftests which are on upstream review.
Er, I didn't say or mean that no tests were written, just that there is too much push-back on it. Heinrich put a huge amount of effort into
There's no pushback at all, apart from the TPM one. (and for a very good reason I've explained over and over again). In fact we add the sefltests as part of our patchsets.
the tests and basically created a strong base for it. Congrats and huge kudos to him. As to Linaro, no offence intended, and it is great that all these tests have been added. Thank you for your efforts and it is very helpful. But I think you miss my point. Or perhaps you don't even agree with it? I sent an email about this on one patch just a day or two ago.
I guess you mean [1]. I've lost count of how many times I responded to this. Threads [2], [3] and [4] are just a few examples, so I just got tired or replying the same thing over and over.
So bottom line, we are contributing selftests as always, we just don't agree with the way *you* want this specific TPM test, trying to force us into sandbox. So instead of respecting what we have (which btw is acceptable from u-boot's perspective and cleans up a lot of the TPM crud along the way), you went ahead making misleading statements on the selftests we contribute, in general. What's even more annoying is that, as I showed you, we pretty much add a selftest for *every* feature we add. Excellent ... that's certainly ... encouraging ... and very productive.
As to the leadership side (my bigger point), Linaro is leading us all down this fragmented path, with TF-A, FIP, more and more binaries and larger firmware diagrams. Or do you disagree with that too?
Of course I disagree. People decided not to use SPL for their own reasons. I am certainly not qualified to answer why Arm choose to do that, but it seems to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure U-Boot is compatible and remains the de-facto choice for embedded boot loaders playing nicely with all the new FSBLs come up with. If you cosinder SPL and U-Boot the center of the known universe, we certainly view things differently. FWIW it's *our* work mostly that made U-Boot SystemReady compliant, which is something Arm pushes for [5].
I'm sorry if you find this a bit sharp.
Which part? The first one wrt to selftests is not sharp. It's manipulative and utterly unacceptable for me, not to mention entirely fabricated.
The latter on bootloading fragmentation, I am always happy to discuss.
My comment was about the push-back I feel I have received when requesting tests. It was a poor choice of words since it suggests this is an ongoing problem when in fact many tests have been written. So I would like to withdraw that and I am sorry for saying that and for upsetting you. I certainly agree that Linaro has written lots of tests and this is great. Thank you to you and Linaro for that. The business of how the tests are written can be handled in other threads.
Thanks, I appreciate this. Let's just forget this ever happened. The discussions are usually constructive and I am happy with the general progress, despite of the differences of opinion.
But someone needs to be pointing these things out. I don't know who else is doing so. ARM firmware has got noticeably more complicated and fragmented in the last five years, hasn't it? What can Linaro do to address that? I am very happy to help and provide part of the solution, but it needs a shared vision.
There's a TF-A mailing list, we can certainly engage there and try to align our ideas/designs.
It's not even just a Linaro/ARM problem. On the x86 side it is fast becoming a living nightmare.
Perhaps the problem here is just the pandemic response and the inability for people to get into a room and brainstorm / collaborate / hack on ideas? I know you have made big efforts to engage, Ilias. We have spoken many times and I'm sure f2f would be easier.
It's not even just a Linaro/ARM problem. On the x86 side it is fast becoming a living nightmare.
Perhaps the problem here is just the pandemic response and the inability for people to get into a room and brainstorm / collaborate / hack on ideas? I know you have made big efforts to engage, Ilias. We have spoken many times and I'm sure f2f would be easier.
Maybe, hopefully travelling will restart soon.
I think the whole issue in this thread comes down to a matter of alignment.
As you can tell, I am frustrated with where things are headed and hope we can course-correct at some point.
This is a matter of perspective to me. I've accepted the fact that firmware gets more complex. Whether I personally like it or not is a different story. One thing that's clear to me though is that we either have to adapt, or slowly become irrelevant.
Thanks /Ilias
Regards, Simon
[1] https://lore.kernel.org/u-boot/CAPnjgZ2mmcUKz0v=ysSvf17c6ab++-hEpO4rc0OeeAEz... [2] https://lore.kernel.org/u-boot/YVdlvpThuqr8jksL@apalos.home/ [3] https://lore.kernel.org/u-boot/CAC_iWjLWxPyEwPpG7v=1U1sxLOD4LXF+Vm+cGTHom9Mp... [4] https://lore.kernel.org/u-boot/YVGGRqgVAiHvd1aR@apalos.home/ [5] https://www.arm.com/why-arm/architecture/systems/systemready-certification-p...
Regards /Ilias
Hi Ilias,
On Tue, 2 Nov 2021 at 09:38, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
[...]
Why me? Perhaps Linaro could take this on instead of working in a separate tool and domain? You guys could really pull things together and reduce the fragmentation, if you took it on.
Honestly it is hard enough to even get Linaro people to write a test for code they have written. What gives?
That's completely inaccurate. We've added selftests for *every* single feature we've sent for EFI up to now. Functionality wise the past 2 years we've added
- EFI variables
- EFI secure boot
- capsule updates
- initrd loading
- efi TCG protocol
- ESRT tables
- RNG protocol
5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() ce62b0f8f45f1 test/py: Fix efidebug related tests 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule de489d82e3189 test: test the ESRT creation 57be8cdce35 test/py: efi_secboot: small rework for adding a new test e1174c566a61c test/py: efi_secboot: add test for intermediate certificates 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
and I am pretty sure I am forgetting more on functionality and selftests.
So basically we've either contributed new selftests for *everything* we've or fixed the existing ones. The only thing that's not merged is the TCG selftests which are on upstream review.
Er, I didn't say or mean that no tests were written, just that there is too much push-back on it. Heinrich put a huge amount of effort into
There's no pushback at all, apart from the TPM one. (and for a very good reason I've explained over and over again). In fact we add the sefltests as part of our patchsets.
the tests and basically created a strong base for it. Congrats and huge kudos to him. As to Linaro, no offence intended, and it is great that all these tests have been added. Thank you for your efforts and it is very helpful. But I think you miss my point. Or perhaps you don't even agree with it? I sent an email about this on one patch just a day or two ago.
I guess you mean [1]. I've lost count of how many times I responded to this. Threads [2], [3] and [4] are just a few examples, so I just got tired or replying the same thing over and over.
So bottom line, we are contributing selftests as always, we just don't agree with the way *you* want this specific TPM test, trying to force us into sandbox. So instead of respecting what we have (which btw is acceptable from u-boot's perspective and cleans up a lot of the TPM crud along the way), you went ahead making misleading statements on the selftests we contribute, in general. What's even more annoying is that, as I showed you, we pretty much add a selftest for *every* feature we add. Excellent ... that's certainly ... encouraging ... and very productive.
As to the leadership side (my bigger point), Linaro is leading us all down this fragmented path, with TF-A, FIP, more and more binaries and larger firmware diagrams. Or do you disagree with that too?
Of course I disagree. People decided not to use SPL for their own reasons. I am certainly not qualified to answer why Arm choose to do that, but it seems to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure U-Boot is compatible and remains the de-facto choice for embedded boot loaders playing nicely with all the new FSBLs come up with. If you cosinder SPL and U-Boot the center of the known universe, we certainly view things differently. FWIW it's *our* work mostly that made U-Boot SystemReady compliant, which is something Arm pushes for [5].
I'm sorry if you find this a bit sharp.
Which part? The first one wrt to selftests is not sharp. It's manipulative and utterly unacceptable for me, not to mention entirely fabricated.
The latter on bootloading fragmentation, I am always happy to discuss.
My comment was about the push-back I feel I have received when requesting tests. It was a poor choice of words since it suggests this is an ongoing problem when in fact many tests have been written. So I would like to withdraw that and I am sorry for saying that and for upsetting you. I certainly agree that Linaro has written lots of tests and this is great. Thank you to you and Linaro for that. The business of how the tests are written can be handled in other threads.
Thanks, I appreciate this. Let's just forget this ever happened. The discussions are usually constructive and I am happy with the general progress, despite of the differences of opinion.
OK thank you. Yes I agree.
But someone needs to be pointing these things out. I don't know who else is doing so. ARM firmware has got noticeably more complicated and fragmented in the last five years, hasn't it? What can Linaro do to address that? I am very happy to help and provide part of the solution, but it needs a shared vision.
There's a TF-A mailing list, we can certainly engage there and try to align our ideas/designs.
It's not even just a Linaro/ARM problem. On the x86 side it is fast becoming a living nightmare.
Perhaps the problem here is just the pandemic response and the inability for people to get into a room and brainstorm / collaborate / hack on ideas? I know you have made big efforts to engage, Ilias. We have spoken many times and I'm sure f2f would be easier.
It's not even just a Linaro/ARM problem. On the x86 side it is fast becoming a living nightmare.
Perhaps the problem here is just the pandemic response and the inability for people to get into a room and brainstorm / collaborate / hack on ideas? I know you have made big efforts to engage, Ilias. We have spoken many times and I'm sure f2f would be easier.
Maybe, hopefully travelling will restart soon.
I think the whole issue in this thread comes down to a matter of alignment.
As you can tell, I am frustrated with where things are headed and hope we can course-correct at some point.
This is a matter of perspective to me. I've accepted the fact that firmware gets more complex. Whether I personally like it or not is a different story. One thing that's clear to me though is that we either have to adapt, or slowly become irrelevant.
I have a lot of ideas here and I think we can do much better, not just on ARM but Intel/AMD also.
I can't imagine how we could discuss these except in-person for a day or two with a whiteboard, so for now I will just let things ride.
Regards, Simon
Hi Simon
(I keep getting messages about delivery problems so I don't know what went through or not)
On Wed, 27 Oct 2021 at 21:52, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Wed, 27 Oct 2021 at 21:33, Simon Glass sjg@chromium.org wrote:
Hi François,
On Wed, 27 Oct 2021 at 09:38, François Ozog francois.ozog@linaro.org wrote:
Hi Simon,
On Wed, 27 Oct 2021 at 16:13, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 09:57, François Ozog francois.ozog@linaro.org wrote:
On Tue, 26 Oct 2021 at 17:27, Simon Glass sjg@chromium.org wrote: > > Hi François, > > On Tue, 26 Oct 2021 at 08:31, François Ozog francois.ozog@linaro.org wrote: > > > > Hi Simon, > > > > On Tue, 26 Oct 2021 at 02:25, Simon Glass sjg@chromium.org wrote: > >> > >> At present some of the ideas and techniques behind devicetree in U-Boot > >> are assumed, implied or unsaid. Add some documentation to cover how > >> devicetree is build, how it can be modified and the rules about using > >> the various CONFIG_OF_... options. > >>
[..]
> >> +Why not have two devicetrees? > >> +----------------------------- > >> + > >> +Setting aside the argument for restricting U-Boot from having its own nodes and > >> +properties, another idea proposed is to have two devicetrees, one for the > >> +U-Boot-specific bits (here called `special`) and one for everything else (here > >> +called `linux`). > >> + > >> +On the positive side, it might quieten the discussion alluded to in the section > >> +above. But there are many negatives to consider and many open questions to > >> +resolve. > >> + > >> +- **Bindings** - Presumably the special devicetree would have its own bindings. > >> + It would not be necessary to put a `u-boot,` prefix on anything. People coming > >> + across the devicetree source would wonder how it fits in with the Linux > >> + devicetree. > >> + > >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This > >> + would need to be expanded to support two trees. Features which need to access > >> + both (such as a device driver which reads the special devicetree to get some > >> + configuration info) could become quite confusing to read and write. > >> + > >> +- **Merging** - Can the two devicetree be merged if a platform desires it? If > >> + so, how is this managed in tooling? Does it happen during the build, in which > >> + case they are not really separate at all. Or does U-Boot merge them at > >> + runtime, in which case this adds time and memory? > >> + > >> +- **Efficiency** - A second device tree adds more code and more code paths. It > >> + requires that both be made available to the code in U-Boot, e.g. via a > >> + separate pointer or argument or API. Overall the separation would certainly > >> + not speed up U-Boot, nor decrease its size. > >> + > >> +- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for > >> + U-Boot for a particular board. Would we use these same files for the special > >> + devicetree? > >> + > >> +- **Complexity** - Two devicetrees complicates the build system since it must > >> + build and package them both. Errors must be reported in such a way that it > >> + is obvious which one is failing. > >> + > >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model > >> + are currently placed in the nodes they relate to. How would these tags > >> + reference a node that is in a separate devicetree? What extra validation would > >> + be needed? > >> + > >> +- **Storage** - How would the two devicetrees be stored in the image? At present > >> + we simply concatenate the U-Boot binary and the devicetree. We could add the > >> + special devicetree before the Linux one, so two are concatenated, but it is > >> + not pretty. We could use binman to support more complex arrangements, but only > >> + some boards use this at present, so it would be a big change. > >> + > >> +- **API** - How would another project provide two devicetree files to U-Boot at > >> + runtime? Presumably this would just be too painful. But if it doesn't, it > >> + would be unable to configure run-time features of U-Boot during the boot. > >> + > >> +- **Confusion** - No other project has two devicetrees. U-Boot would be in the > >> + unfortunate position of having to describe this fact to new users, along with > >> + the (arguably contrived) reason for the arrangement. > >> + > > > > False: > > 1) projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes. > > Can you provided a link and I can update this.
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.ht... Bindings: for FCONF: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_pr... for FF-A: https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-b... For chain-of-trust: https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.ht...
For some code: https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fipto... From there you can wander and see how dynamic config sections of the FIP can contain component specific DTs. U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
OK I can mention that TF-A supports multiple devicetrees if you like, but I'm not sure we are talking about the same thing.
If I take a possible scenario: OP-TEE to deal with 3 different device trees:
- the one that will be passed to the OS and for which it may want to do some fixups
- the one that it is using to run (it may have secure devices that are entirely not visible to any normal world OS)
- the one that it gets from the FIP and contains runtime configuration parameters, accessed through FCONF library)
U-Boot also supports multiple devicetrees in the build - e.g. SPL and U-Boot proper. With binman you can create several copies of them for use with A/B boot, for example. But only one is used as a control DTB by a particular U-Boot phase at a time. Do you see what I mean?
> > > 2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system > > As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT. > > If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards. > > I have gone to great efforts to document things here, as they work in > U-Boot today. As you know, U-Boot supports separate control and active > devicetrees.
I don't know what is an active device tree. Is it the device tree to be passed to OS?
Yes that's right.
> > But if you are wanting to change to multiple control > trees within U-Boot, I'd say the answer is "no, thank you".
I see only one control DT.
OK good.
There is a possibility to store it securely in NT_FW_CONFIG section of a FIP. it also has associated signature plus hash mechanisms to attest authenticity of it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes).
What does NT mean? I suppose FW means firmware.
Non Trusted; it means normal world as opposed to secure world. It feels unfortunate to say non trusted while it is trusted but running outside secure world ;-)
OK, good, so long as it doesn't mean Windows NT I am happy.
It doesn't really matter where it is stored, so long as U-Boot can access it.
You can certain have a similar mechanism for binman.
Note that binman is a packaging tool. Perhaps you should add FIP support to it if FIP is going to be required too now?
There may be a need for a FIP explanation. I'll check with other guys to propose text.
I mean add an entry type to binman for FIP. It supports CBFS already, for example.
What I would like, to package up the firmware for ANY board, after all the building is done in various projects:
binman -b <board>
FIP deals with a number of firmwares like the SCP and MCP ones running on other micro-controllers of a board. So in a sense it is an arm targeted tool. If you want to package firmware for arm boards with binman you will have to deal with those firmwares as well as secure world and its trusted services as secure partitions that are being developed (including when virtualization is in operation in the secure world). So in a word, trying to do this is a big undertaking, but you can try.
Binman supports adding firmware for microcontrollers. For example, see here:
https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/dts/flashmap-16mb-x86...
That is a Chrome OS EC binary, one of three in the image.
This is not ARM-specific. That image is actually for x86 Apollo Lake.
In a short term future (see Alibaba and Marvell announcements) you will have to deal with Arm v9 realms and associated firmware.
Why me? Perhaps Linaro could take this on instead of working in a separate tool and domain? You guys could really pull things together and reduce the fragmentation, if you took it on.
Honestly it is hard enough to even get Linaro people to write a test for code they have written. What gives?
That's completely inaccurate. We've added selftests for *every* single feature we've sent for EFI up to now. Functionality wise the past 2 years we've added
- EFI variables
- EFI secure boot
- capsule updates
- initrd loading
- efi TCG protocol
- ESRT tables
- RNG protocol
5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() ce62b0f8f45f1 test/py: Fix efidebug related tests 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule de489d82e3189 test: test the ESRT creation 57be8cdce35 test/py: efi_secboot: small rework for adding a new test e1174c566a61c test/py: efi_secboot: add test for intermediate certificates 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
and I am pretty sure I am forgetting more on functionality and selftests.
So basically we've either contributed new selftests for *everything* we've or fixed the existing ones. The only thing that's not merged is the TCG selftests which are on upstream review.
Er, I didn't say or mean that no tests were written, just that there is too much push-back on it. Heinrich put a huge amount of effort into the tests and basically created a strong base for it. Congrats and huge kudos to him. As to Linaro, no offence intended, and it is great that all these tests have been added. Thank you for your efforts and it is very helpful. But I think you miss my point. Or perhaps you don't even agree with it? I sent an email about this on one patch just a day or two ago.
As to the leadership side (my bigger point), Linaro is leading us all down this fragmented path, with TF-A, FIP, more and more binaries and larger firmware diagrams. Or do you disagree with that too?
You seem to picture the role of the firmware to *only* to boot an operating system. I would be surprised to teach you that secure world is a world of its own that need to be orchestrated and hosts business related applications that stay available after U-Boot has disappeared from memory (OK with UEFI runtime services it stills occupies some space but it should be mostly inactive as Linux own devices - let's not comment on this particular aspect). As U-Boot has no code for that world, creating another code base would actually create fragmentation. The mindset I sense from your comments reminds me when relational databases reached the market. People wanted to fit their business as "relational", killing other flavors of databases. It took at least a decade to get back to reason and think that more than one technology is needed with columnar databases, unstructured databases, KV databases... U-Boot is a "jewel" for what it does. Let's not try to expand it in areas where it is not meant to be and create fragmentation.
I'm sorry if you find this a bit sharp. But someone needs to be pointing these things out. I don't know who else is doing so. ARM firmware has got noticeably more complicated and fragmented in the last five years, hasn't it? What can Linaro do to address that?
Linaro very creation was to avoid fragmentation in the arm ecosystem and I think we can be proud of what has been accomplished from Linus Torvalds comment on the state of kernel for arm. We are on a journey to do the same for the firmware. The first part was on the secure world firmware (that, again, do a lot of stuff for the secure world and happen to also load U-Boot). The second part is on the contract between U-Boot and the OS, hence our contributions in U-Boot. I am
very happy to help and provide part of the solution, but it needs a shared vision.
This vision is entirely explained in Arm Cassini project with more firmware related details in SystemReady and further more details for embedded world in EBBR. You asked me what was the problem we are trying to solve: <session from FOSDEM 2021> "“A BSP is a badly-patched fork of an ancient U-Boot, a badly-patched fork of an ancient Linux, and a badly-patched fork of an ancient Yocto” “… that, plus often a prehistoric compiler” </session from FOSDEM 2021> Adding features in U-Boot is only part of the solution: we need to have a process to keep boards bootable over time and that simplifies the firmware supply chain. I understand you don't like the choices, but that is an ecosystem choice, not my choice, not Linaro choice, and hopefully you will join us in making it happen.
It's not even just a Linaro/ARM problem. On the x86 side it is fast becoming a living nightmare.
Perhaps the problem here is just the pandemic response and the inability for people to get into a room and brainstorm / collaborate / hack on ideas?
I could not agree more. Mail exchanges tend to self inflate... I remember a BoF in a Connect with 20 people around the table talking about firmware update and finding a way to make anti-bricking standard across boards (see yet another effort of defragmentation:-) People started the session with "impossible" in mind, and we came out with a plan. Now we are close to have it. If we could be on the drawing board, I am sure you would immediately understand and make a better version of our authentication scheme for those updates.. ..and pull the relevant patchset ;-) (sorry I could not resist pulling your leg at the end) I know you have made big efforts to engage, Ilias. We
have spoken many times and I'm sure f2f would be easier.
Regards, Simon
-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
Hi François,
On Fri, 29 Oct 2021 at 11:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
(I keep getting messages about delivery problems so I don't know what went through or not)
I got this one, anyway.
On Wed, 27 Oct 2021 at 21:52, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Wed, 27 Oct 2021 at 21:33, Simon Glass sjg@chromium.org wrote:
Hi François,
On Wed, 27 Oct 2021 at 09:38, François Ozog francois.ozog@linaro.org wrote:
Hi Simon,
On Wed, 27 Oct 2021 at 16:13, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 09:57, François Ozog francois.ozog@linaro.org wrote: > > > > On Tue, 26 Oct 2021 at 17:27, Simon Glass sjg@chromium.org wrote: >> >> Hi François, >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog francois.ozog@linaro.org wrote: >> > >> > Hi Simon, >> > >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass sjg@chromium.org wrote: >> >> >> >> At present some of the ideas and techniques behind devicetree in U-Boot >> >> are assumed, implied or unsaid. Add some documentation to cover how >> >> devicetree is build, how it can be modified and the rules about using >> >> the various CONFIG_OF_... options. >> >>
[..]
>> >> +Why not have two devicetrees? >> >> +----------------------------- >> >> + >> >> +Setting aside the argument for restricting U-Boot from having its own nodes and >> >> +properties, another idea proposed is to have two devicetrees, one for the >> >> +U-Boot-specific bits (here called `special`) and one for everything else (here >> >> +called `linux`). >> >> + >> >> +On the positive side, it might quieten the discussion alluded to in the section >> >> +above. But there are many negatives to consider and many open questions to >> >> +resolve. >> >> + >> >> +- **Bindings** - Presumably the special devicetree would have its own bindings. >> >> + It would not be necessary to put a `u-boot,` prefix on anything. People coming >> >> + across the devicetree source would wonder how it fits in with the Linux >> >> + devicetree. >> >> + >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This >> >> + would need to be expanded to support two trees. Features which need to access >> >> + both (such as a device driver which reads the special devicetree to get some >> >> + configuration info) could become quite confusing to read and write. >> >> + >> >> +- **Merging** - Can the two devicetree be merged if a platform desires it? If >> >> + so, how is this managed in tooling? Does it happen during the build, in which >> >> + case they are not really separate at all. Or does U-Boot merge them at >> >> + runtime, in which case this adds time and memory? >> >> + >> >> +- **Efficiency** - A second device tree adds more code and more code paths. It >> >> + requires that both be made available to the code in U-Boot, e.g. via a >> >> + separate pointer or argument or API. Overall the separation would certainly >> >> + not speed up U-Boot, nor decrease its size. >> >> + >> >> +- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for >> >> + U-Boot for a particular board. Would we use these same files for the special >> >> + devicetree? >> >> + >> >> +- **Complexity** - Two devicetrees complicates the build system since it must >> >> + build and package them both. Errors must be reported in such a way that it >> >> + is obvious which one is failing. >> >> + >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model >> >> + are currently placed in the nodes they relate to. How would these tags >> >> + reference a node that is in a separate devicetree? What extra validation would >> >> + be needed? >> >> + >> >> +- **Storage** - How would the two devicetrees be stored in the image? At present >> >> + we simply concatenate the U-Boot binary and the devicetree. We could add the >> >> + special devicetree before the Linux one, so two are concatenated, but it is >> >> + not pretty. We could use binman to support more complex arrangements, but only >> >> + some boards use this at present, so it would be a big change. >> >> + >> >> +- **API** - How would another project provide two devicetree files to U-Boot at >> >> + runtime? Presumably this would just be too painful. But if it doesn't, it >> >> + would be unable to configure run-time features of U-Boot during the boot. >> >> + >> >> +- **Confusion** - No other project has two devicetrees. U-Boot would be in the >> >> + unfortunate position of having to describe this fact to new users, along with >> >> + the (arguably contrived) reason for the arrangement. >> >> + >> > >> > False: >> > 1) projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes. >> >> Can you provided a link and I can update this. > > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.ht... > Bindings: > for FCONF: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_pr... > for FF-A: https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-b... > For chain-of-trust: https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.ht... > > For some code: > https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fipto... > From there you can wander and see how dynamic config sections of the FIP can contain component specific DTs. > U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
OK I can mention that TF-A supports multiple devicetrees if you like, but I'm not sure we are talking about the same thing.
If I take a possible scenario: OP-TEE to deal with 3 different device trees:
- the one that will be passed to the OS and for which it may want to do some fixups
- the one that it is using to run (it may have secure devices that are entirely not visible to any normal world OS)
- the one that it gets from the FIP and contains runtime configuration parameters, accessed through FCONF library)
U-Boot also supports multiple devicetrees in the build - e.g. SPL and U-Boot proper. With binman you can create several copies of them for use with A/B boot, for example. But only one is used as a control DTB by a particular U-Boot phase at a time. Do you see what I mean?
>> >> > 2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system >> > As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT. >> > If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards. >> >> I have gone to great efforts to document things here, as they work in >> U-Boot today. As you know, U-Boot supports separate control and active >> devicetrees. > > I don't know what is an active device tree. Is it the device tree to be passed to OS?
Yes that's right.
>> >> But if you are wanting to change to multiple control >> trees within U-Boot, I'd say the answer is "no, thank you". > > I see only one control DT.
OK good.
> There is a possibility to store it securely in NT_FW_CONFIG section of a FIP. it also has associated signature plus hash mechanisms to attest authenticity of it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes).
What does NT mean? I suppose FW means firmware.
Non Trusted; it means normal world as opposed to secure world. It feels unfortunate to say non trusted while it is trusted but running outside secure world ;-)
OK, good, so long as it doesn't mean Windows NT I am happy.
It doesn't really matter where it is stored, so long as U-Boot can access it.
> You can certain have a similar mechanism for binman.
Note that binman is a packaging tool. Perhaps you should add FIP support to it if FIP is going to be required too now?
There may be a need for a FIP explanation. I'll check with other guys to propose text.
I mean add an entry type to binman for FIP. It supports CBFS already, for example.
What I would like, to package up the firmware for ANY board, after all the building is done in various projects:
binman -b <board>
FIP deals with a number of firmwares like the SCP and MCP ones running on other micro-controllers of a board. So in a sense it is an arm targeted tool. If you want to package firmware for arm boards with binman you will have to deal with those firmwares as well as secure world and its trusted services as secure partitions that are being developed (including when virtualization is in operation in the secure world). So in a word, trying to do this is a big undertaking, but you can try.
Binman supports adding firmware for microcontrollers. For example, see here:
https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/dts/flashmap-16mb-x86...
That is a Chrome OS EC binary, one of three in the image.
This is not ARM-specific. That image is actually for x86 Apollo Lake.
In a short term future (see Alibaba and Marvell announcements) you will have to deal with Arm v9 realms and associated firmware.
Why me? Perhaps Linaro could take this on instead of working in a separate tool and domain? You guys could really pull things together and reduce the fragmentation, if you took it on.
Honestly it is hard enough to even get Linaro people to write a test for code they have written. What gives?
That's completely inaccurate. We've added selftests for *every* single feature we've sent for EFI up to now. Functionality wise the past 2 years we've added
- EFI variables
- EFI secure boot
- capsule updates
- initrd loading
- efi TCG protocol
- ESRT tables
- RNG protocol
5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() ce62b0f8f45f1 test/py: Fix efidebug related tests 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule de489d82e3189 test: test the ESRT creation 57be8cdce35 test/py: efi_secboot: small rework for adding a new test e1174c566a61c test/py: efi_secboot: add test for intermediate certificates 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
and I am pretty sure I am forgetting more on functionality and selftests.
So basically we've either contributed new selftests for *everything* we've or fixed the existing ones. The only thing that's not merged is the TCG selftests which are on upstream review.
Er, I didn't say or mean that no tests were written, just that there is too much push-back on it. Heinrich put a huge amount of effort into the tests and basically created a strong base for it. Congrats and huge kudos to him. As to Linaro, no offence intended, and it is great that all these tests have been added. Thank you for your efforts and it is very helpful. But I think you miss my point. Or perhaps you don't even agree with it? I sent an email about this on one patch just a day or two ago.
As to the leadership side (my bigger point), Linaro is leading us all down this fragmented path, with TF-A, FIP, more and more binaries and larger firmware diagrams. Or do you disagree with that too?
You seem to picture the role of the firmware to *only* to boot an operating system. I would be surprised to teach you that secure world is a world of its own that need to be orchestrated and hosts business related applications that stay available after U-Boot has disappeared from memory (OK with UEFI runtime services it stills occupies some space but it should be mostly inactive as Linux own devices - let's not comment on this particular aspect). As U-Boot has no code for that world, creating another code base would actually create fragmentation. The mindset I sense from your comments reminds me when relational databases reached the market. People wanted to fit their business as "relational", killing other flavors of databases. It took at least a decade to get back to reason and think that more than one technology is needed with columnar databases, unstructured databases, KV databases... U-Boot is a "jewel" for what it does. Let's not try to expand it in areas where it is not meant to be and create fragmentation.
I'm sorry if you find this a bit sharp. But someone needs to be pointing these things out. I don't know who else is doing so. ARM firmware has got noticeably more complicated and fragmented in the last five years, hasn't it? What can Linaro do to address that?
Linaro very creation was to avoid fragmentation in the arm ecosystem and I think we can be proud of what has been accomplished from Linus Torvalds comment on the state of kernel for arm. We are on a journey to do the same for the firmware. The first part was on the secure world firmware (that, again, do a lot of stuff for the secure world and happen to also load U-Boot). The second part is on the contract between U-Boot and the OS, hence our contributions in U-Boot. I am
very happy to help and provide part of the solution, but it needs a shared vision.
This vision is entirely explained in Arm Cassini project with more firmware related details in SystemReady and further more details for embedded world in EBBR. You asked me what was the problem we are trying to solve: <session from FOSDEM 2021> "“A BSP is a badly-patched fork of an ancient U-Boot, a badly-patched fork of an ancient Linux, and a badly-patched fork of an ancient Yocto” “… that, plus often a prehistoric compiler” </session from FOSDEM 2021> Adding features in U-Boot is only part of the solution: we need to have a process to keep boards bootable over time and that simplifies the firmware supply chain. I understand you don't like the choices, but that is an ecosystem choice, not my choice, not Linaro choice, and hopefully you will join us in making it happen.
I believe I am involved, at least. I do make time to engage on a call most weeks. As you say, we don't agree on all the choices. I think the areas of concern I have are devicetree (several issues which I hope we are making progress on), proliferation of binaries and complexity of packaging.
It's not even just a Linaro/ARM problem. On the x86 side it is fast becoming a living nightmare.
Perhaps the problem here is just the pandemic response and the inability for people to get into a room and brainstorm / collaborate / hack on ideas?
I could not agree more. Mail exchanges tend to self inflate... I remember a BoF in a Connect with 20 people around the table talking about firmware update and finding a way to make anti-bricking standard across boards (see yet another effort of defragmentation:-) People started the session with "impossible" in mind, and we came out with a plan. Now we are close to have it. If we could be on the drawing board, I am sure you would immediately understand and make a better version of our authentication scheme for those updates.. ..and pull the relevant patchset ;-) (sorry I could not resist pulling your leg at the end) I know you have made big efforts to engage, Ilias. We
have spoken many times and I'm sure f2f would be easier.
OK, well let's hope it all works out. Rome wasn't built in a day. It is an important goal.
Regards, Simon
Hi Simon,
Le mer. 27 oct. 2021 à 20:33, Simon Glass sjg@chromium.org a écrit :
Hi François,
On Wed, 27 Oct 2021 at 09:38, François Ozog francois.ozog@linaro.org wrote:
Hi Simon,
On Wed, 27 Oct 2021 at 16:13, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 09:57, François Ozog francois.ozog@linaro.org
wrote:
On Tue, 26 Oct 2021 at 17:27, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 08:31, François Ozog <
francois.ozog@linaro.org> wrote:
Hi Simon,
On Tue, 26 Oct 2021 at 02:25, Simon Glass sjg@chromium.org
wrote:
> > At present some of the ideas and techniques behind devicetree in
U-Boot
> are assumed, implied or unsaid. Add some documentation to cover
how
> devicetree is build, how it can be modified and the rules about
using
> the various CONFIG_OF_... options. >
[..]
> +Why not have two devicetrees? > +----------------------------- > + > +Setting aside the argument for restricting U-Boot from having
its own nodes and
> +properties, another idea proposed is to have two devicetrees,
one for the
> +U-Boot-specific bits (here called `special`) and one for
everything else (here
> +called `linux`). > + > +On the positive side, it might quieten the discussion alluded to
in the section
> +above. But there are many negatives to consider and many open
questions to
> +resolve. > + > +- **Bindings** - Presumably the special devicetree would have
its own bindings.
> + It would not be necessary to put a `u-boot,` prefix on
anything. People coming
> + across the devicetree source would wonder how it fits in with
the Linux
> + devicetree. > + > +- **Access** - U-Boot has a nice `ofnode` API for accessing the
devicetree. This
> + would need to be expanded to support two trees. Features which
need to access
> + both (such as a device driver which reads the special
devicetree to get some
> + configuration info) could become quite confusing to read and
write.
> + > +- **Merging** - Can the two devicetree be merged if a platform
desires it? If
> + so, how is this managed in tooling? Does it happen during the
build, in which
> + case they are not really separate at all. Or does U-Boot merge
them at
> + runtime, in which case this adds time and memory? > + > +- **Efficiency** - A second device tree adds more code and more
code paths. It
> + requires that both be made available to the code in U-Boot,
e.g. via a
> + separate pointer or argument or API. Overall the separation
would certainly
> + not speed up U-Boot, nor decrease its size. > + > +- **Source code** - At present `u-boot.dtsi` files provide the
pieces needed for
> + U-Boot for a particular board. Would we use these same files
for the special
> + devicetree? > + > +- **Complexity** - Two devicetrees complicates the build system
since it must
> + build and package them both. Errors must be reported in such a
way that it
> + is obvious which one is failing. > + > +- **Referencing each other** - The `u-boot,dm-xxx` tags used by
driver model
> + are currently placed in the nodes they relate to. How would
these tags
> + reference a node that is in a separate devicetree? What extra
validation would
> + be needed? > + > +- **Storage** - How would the two devicetrees be stored in the
image? At present
> + we simply concatenate the U-Boot binary and the devicetree. We
could add the
> + special devicetree before the Linux one, so two are
concatenated, but it is
> + not pretty. We could use binman to support more complex
arrangements, but only
> + some boards use this at present, so it would be a big change. > + > +- **API** - How would another project provide two devicetree
files to U-Boot at
> + runtime? Presumably this would just be too painful. But if it
doesn't, it
> + would be unable to configure run-time features of U-Boot
during the boot.
> + > +- **Confusion** - No other project has two devicetrees. U-Boot
would be in the
> + unfortunate position of having to describe this fact to new
users, along with
> + the (arguably contrived) reason for the arrangement. > +
False:
- projects in trustedfirmware.org are built to have multiple FDT
objects, some for "dynamic" configuration purposes.
Can you provided a link and I can update this.
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.ht...
Bindings: for FCONF:
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_pr...
for FF-A:
https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-b...
For chain-of-trust:
https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.ht...
For some code:
https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fipto...
From there you can wander and see how dynamic config sections of the
FIP can contain component specific DTs.
U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
OK I can mention that TF-A supports multiple devicetrees if you like, but I'm not sure we are talking about the same thing.
If I take a possible scenario: OP-TEE to deal with 3 different device
trees:
- the one that will be passed to the OS and for which it may want to do
some fixups
- the one that it is using to run (it may have secure devices that are
entirely not visible to any normal world OS)
- the one that it gets from the FIP and contains runtime configuration
parameters, accessed through FCONF library)
U-Boot also supports multiple devicetrees in the build - e.g. SPL and U-Boot proper. With binman you can create several copies of them for use with A/B boot, for example. But only one is used as a control DTB by a particular U-Boot phase at a time. Do you see what I mean?
- STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in
addition to operating system
As Ilias said, this is not about documentation about the current
use of DT in U-Boot, but justification of your views on DT.
If taken by the letter, I feel (may be wrong though) that your
views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
I have gone to great efforts to document things here, as they work in U-Boot today. As you know, U-Boot supports separate control and
active
devicetrees.
I don't know what is an active device tree. Is it the device tree to
be passed to OS?
Yes that's right.
But if you are wanting to change to multiple control trees within U-Boot, I'd say the answer is "no, thank you".
I see only one control DT.
OK good.
There is a possibility to store it securely in NT_FW_CONFIG section
of a FIP. it also has associated signature plus hash mechanisms to attest authenticity of it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes).
What does NT mean? I suppose FW means firmware.
Non Trusted; it means normal world as opposed to secure world. It feels unfortunate to say non trusted while it is trusted but running
outside secure world ;-)
OK, good, so long as it doesn't mean Windows NT I am happy.
It doesn't really matter where it is stored, so long as U-Boot can
access it.
You can certain have a similar mechanism for binman.
Note that binman is a packaging tool. Perhaps you should add FIP support to it if FIP is going to be required too now?
There may be a need for a FIP explanation. I'll check with other guys to
propose text.
I mean add an entry type to binman for FIP. It supports CBFS already, for example.
What I would like, to package up the firmware for ANY board, after all the building is done in various projects:
binman -b <board>
FIP deals with a number of firmwares like the SCP and MCP ones running
on other micro-controllers of a board.
So in a sense it is an arm targeted tool. If you want to package firmware for arm boards with binman you will have
to deal with those firmwares as well as secure world and its trusted services as secure partitions that are being developed (including when virtualization is in operation in the secure world).
So in a word, trying to do this is a big undertaking, but you can try.
Binman supports adding firmware for microcontrollers. For example, see here:
https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/dts/flashmap-16mb-x86...
That is a Chrome OS EC binary, one of three in the image.
This is not ARM-specific. That image is actually for x86 Apollo Lake.
In a short term future (see Alibaba and Marvell announcements) you will
have to deal with Arm v9 realms and associated firmware.
Why me? Perhaps Linaro could take this on instead of working in a separate tool and domain? You guys could really pull things together and reduce the fragmentation, if you took it on.
Well, what happens in the secure world is getting pretty complex. TFA solves it elegantly so there is no incentive in maintaining a separate code base to do the same. If I picture things in different way, I would say that it the past pre U-Boot proper was representing 20 and U-Boot proper 80. In new schemes, pre U-Boot can be said 80 and U-Boot proper 20.
Honestly it is hard enough to even get Linaro people to write a test for code they have written. What gives?
If there is a use case for that, please can you be specific about what we cannot do with a combined devicetree?
Regards, SImon
On Wed, Oct 27, 2021 at 05:38:28PM +0200, François Ozog wrote:
Hi Simon,
On Wed, 27 Oct 2021 at 16:13, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 09:57, François Ozog francois.ozog@linaro.org wrote:
On Tue, 26 Oct 2021 at 17:27, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 08:31, François Ozog francois.ozog@linaro.org
wrote:
Hi Simon,
On Tue, 26 Oct 2021 at 02:25, Simon Glass sjg@chromium.org wrote:
At present some of the ideas and techniques behind devicetree in
U-Boot
are assumed, implied or unsaid. Add some documentation to cover how devicetree is build, how it can be modified and the rules about using the various CONFIG_OF_... options.
[..]
+Why not have two devicetrees? +-----------------------------
+Setting aside the argument for restricting U-Boot from having its
own nodes and
+properties, another idea proposed is to have two devicetrees, one
for the
+U-Boot-specific bits (here called `special`) and one for everything
else (here
+called `linux`).
+On the positive side, it might quieten the discussion alluded to in
the section
+above. But there are many negatives to consider and many open
questions to
+resolve.
+- **Bindings** - Presumably the special devicetree would have its
own bindings.
- It would not be necessary to put a `u-boot,` prefix on anything.
People coming
- across the devicetree source would wonder how it fits in with the
Linux
- devicetree.
+- **Access** - U-Boot has a nice `ofnode` API for accessing the
devicetree. This
- would need to be expanded to support two trees. Features which
need to access
- both (such as a device driver which reads the special devicetree
to get some
- configuration info) could become quite confusing to read and
write.
+- **Merging** - Can the two devicetree be merged if a platform
desires it? If
- so, how is this managed in tooling? Does it happen during the
build, in which
- case they are not really separate at all. Or does U-Boot merge
them at
- runtime, in which case this adds time and memory?
+- **Efficiency** - A second device tree adds more code and more
code paths. It
- requires that both be made available to the code in U-Boot, e.g.
via a
- separate pointer or argument or API. Overall the separation would
certainly
- not speed up U-Boot, nor decrease its size.
+- **Source code** - At present `u-boot.dtsi` files provide the
pieces needed for
- U-Boot for a particular board. Would we use these same files for
the special
- devicetree?
+- **Complexity** - Two devicetrees complicates the build system
since it must
- build and package them both. Errors must be reported in such a
way that it
- is obvious which one is failing.
+- **Referencing each other** - The `u-boot,dm-xxx` tags used by
driver model
- are currently placed in the nodes they relate to. How would these
tags
- reference a node that is in a separate devicetree? What extra
validation would
- be needed?
+- **Storage** - How would the two devicetrees be stored in the
image? At present
- we simply concatenate the U-Boot binary and the devicetree. We
could add the
- special devicetree before the Linux one, so two are concatenated,
but it is
- not pretty. We could use binman to support more complex
arrangements, but only
- some boards use this at present, so it would be a big change.
+- **API** - How would another project provide two devicetree files
to U-Boot at
- runtime? Presumably this would just be too painful. But if it
doesn't, it
- would be unable to configure run-time features of U-Boot during
the boot.
+- **Confusion** - No other project has two devicetrees. U-Boot
would be in the
- unfortunate position of having to describe this fact to new
users, along with
- the (arguably contrived) reason for the arrangement.
False:
- projects in trustedfirmware.org are built to have multiple FDT
objects, some for "dynamic" configuration purposes.
Can you provided a link and I can update this.
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.ht...
Bindings: for FCONF:
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_pr...
for FF-A:
https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-b...
For chain-of-trust:
https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.ht...
For some code:
https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fipto...
From there you can wander and see how dynamic config sections of the FIP
can contain component specific DTs.
U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
OK I can mention that TF-A supports multiple devicetrees if you like, but I'm not sure we are talking about the same thing.
If I take a possible scenario: OP-TEE to deal with 3 different device trees:
- the one that will be passed to the OS and for which it may want to do
some fixups
- the one that it is using to run (it may have secure devices that are
entirely not visible to any normal world OS)
What relationship does this device tree that OP-TEE is using itself bear to the one is will pass to the OS?
Hi Tom
Le mer. 27 oct. 2021 à 21:48, Tom Rini trini@konsulko.com a écrit :
On Wed, Oct 27, 2021 at 05:38:28PM +0200, François Ozog wrote:
Hi Simon,
On Wed, 27 Oct 2021 at 16:13, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 09:57, François Ozog francois.ozog@linaro.org wrote:
On Tue, 26 Oct 2021 at 17:27, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 08:31, François Ozog <
francois.ozog@linaro.org>
wrote:
Hi Simon,
On Tue, 26 Oct 2021 at 02:25, Simon Glass sjg@chromium.org
wrote:
> > At present some of the ideas and techniques behind devicetree in
U-Boot
> are assumed, implied or unsaid. Add some documentation to cover
how
> devicetree is build, how it can be modified and the rules about
using
> the various CONFIG_OF_... options. >
[..]
> +Why not have two devicetrees? > +----------------------------- > + > +Setting aside the argument for restricting U-Boot from having
its
own nodes and
> +properties, another idea proposed is to have two devicetrees,
one
for the
> +U-Boot-specific bits (here called `special`) and one for
everything
else (here
> +called `linux`). > + > +On the positive side, it might quieten the discussion alluded
to in
the section
> +above. But there are many negatives to consider and many open
questions to
> +resolve. > + > +- **Bindings** - Presumably the special devicetree would have
its
own bindings.
> + It would not be necessary to put a `u-boot,` prefix on
anything.
People coming
> + across the devicetree source would wonder how it fits in with
the
Linux
> + devicetree. > + > +- **Access** - U-Boot has a nice `ofnode` API for accessing the
devicetree. This
> + would need to be expanded to support two trees. Features which
need to access
> + both (such as a device driver which reads the special
devicetree
to get some
> + configuration info) could become quite confusing to read and
write.
> + > +- **Merging** - Can the two devicetree be merged if a platform
desires it? If
> + so, how is this managed in tooling? Does it happen during the
build, in which
> + case they are not really separate at all. Or does U-Boot merge
them at
> + runtime, in which case this adds time and memory? > + > +- **Efficiency** - A second device tree adds more code and more
code paths. It
> + requires that both be made available to the code in U-Boot,
e.g.
via a
> + separate pointer or argument or API. Overall the separation
would
certainly
> + not speed up U-Boot, nor decrease its size. > + > +- **Source code** - At present `u-boot.dtsi` files provide the
pieces needed for
> + U-Boot for a particular board. Would we use these same files
for
the special
> + devicetree? > + > +- **Complexity** - Two devicetrees complicates the build system
since it must
> + build and package them both. Errors must be reported in such a
way that it
> + is obvious which one is failing. > + > +- **Referencing each other** - The `u-boot,dm-xxx` tags used by
driver model
> + are currently placed in the nodes they relate to. How would
these
tags
> + reference a node that is in a separate devicetree? What extra
validation would
> + be needed? > + > +- **Storage** - How would the two devicetrees be stored in the
image? At present
> + we simply concatenate the U-Boot binary and the devicetree. We
could add the
> + special devicetree before the Linux one, so two are
concatenated,
but it is
> + not pretty. We could use binman to support more complex
arrangements, but only
> + some boards use this at present, so it would be a big change. > + > +- **API** - How would another project provide two devicetree
files
to U-Boot at
> + runtime? Presumably this would just be too painful. But if it
doesn't, it
> + would be unable to configure run-time features of U-Boot
during
the boot.
> + > +- **Confusion** - No other project has two devicetrees. U-Boot
would be in the
> + unfortunate position of having to describe this fact to new
users, along with
> + the (arguably contrived) reason for the arrangement. > +
False:
- projects in trustedfirmware.org are built to have multiple FDT
objects, some for "dynamic" configuration purposes.
Can you provided a link and I can update this.
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.ht...
Bindings: for FCONF:
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_pr...
for FF-A:
https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-b...
For chain-of-trust:
https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.ht...
For some code:
https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fipto...
From there you can wander and see how dynamic config sections of the
FIP
can contain component specific DTs.
U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
OK I can mention that TF-A supports multiple devicetrees if you like, but I'm not sure we are talking about the same thing.
If I take a possible scenario: OP-TEE to deal with 3 different device trees:
- the one that will be passed to the OS and for which it may want to do
some fixups
- the one that it is using to run (it may have secure devices that are
entirely not visible to any normal world OS)
What relationship does this device tree that OP-TEE is using itself bear to the one is will pass to the OS?
may be none. The DT may contain only secure devices and devices for which there are no Linux drivers (clocks or others). I am not sure “secure device” is clear. This is a device that is separated by hardware methods to be only accessible by EL3, secure ELx. So even if you have secure mmio range you can’t access it from normal world at all.
-- Tom
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 8d7fda10f15..97b6ec64905 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 ---
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 97b6ec64905..a39df046fc3 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
Add this file, generated from qemu, so there is a reference devicetree in the U-Boot tree.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
arch/arm/dts/Makefile | 2 + arch/arm/dts/qemu-arm.dts | 402 +++++++++++++++++++++++++++++++++++++ configs/qemu_arm_defconfig | 1 + 3 files changed, 405 insertions(+) create mode 100644 arch/arm/dts/qemu-arm.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index a88aecc5bd9..7ab8b145f3f 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1153,6 +1153,8 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) += imx8mm-cl-iot-gate-optee.dtb
dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb
+dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb + targets += $(dtb-y)
# Add any required device tree compiler flags here diff --git a/arch/arm/dts/qemu-arm.dts b/arch/arm/dts/qemu-arm.dts new file mode 100644 index 00000000000..fed558ced98 --- /dev/null +++ b/arch/arm/dts/qemu-arm.dts @@ -0,0 +1,402 @@ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +/* + * Sample device tree for qemu_arm + + * Copyright 2021 Google LLC + */ + +/dts-v1/; + +/ { + interrupt-parent = <0x8001>; + #size-cells = <0x02>; + #address-cells = <0x02>; + compatible = "linux,dummy-virt"; + + psci { + migrate = <0x84000005>; + cpu_on = <0x84000003>; + cpu_off = <0x84000002>; + cpu_suspend = <0x84000001>; + method = "hvc"; + compatible = "arm,psci-0.2\0arm,psci"; + }; + + memory@40000000 { + reg = <0x00 0x40000000 0x00 0x8000000>; + device_type = "memory"; + }; + + platform@c000000 { + interrupt-parent = <0x8001>; + ranges = <0x00 0x00 0xc000000 0x2000000>; + #address-cells = <0x01>; + #size-cells = <0x01>; + compatible = "qemu,platform\0simple-bus"; + }; + + fw-cfg@9020000 { + dma-coherent; + reg = <0x00 0x9020000 0x00 0x18>; + compatible = "qemu,fw-cfg-mmio"; + }; + + virtio_mmio@a000000 { + dma-coherent; + interrupts = <0x00 0x10 0x01>; + reg = <0x00 0xa000000 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000200 { + dma-coherent; + interrupts = <0x00 0x11 0x01>; + reg = <0x00 0xa000200 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000400 { + dma-coherent; + interrupts = <0x00 0x12 0x01>; + reg = <0x00 0xa000400 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000600 { + dma-coherent; + interrupts = <0x00 0x13 0x01>; + reg = <0x00 0xa000600 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000800 { + dma-coherent; + interrupts = <0x00 0x14 0x01>; + reg = <0x00 0xa000800 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000a00 { + dma-coherent; + interrupts = <0x00 0x15 0x01>; + reg = <0x00 0xa000a00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000c00 { + dma-coherent; + interrupts = <0x00 0x16 0x01>; + reg = <0x00 0xa000c00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000e00 { + dma-coherent; + interrupts = <0x00 0x17 0x01>; + reg = <0x00 0xa000e00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001000 { + dma-coherent; + interrupts = <0x00 0x18 0x01>; + reg = <0x00 0xa001000 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001200 { + dma-coherent; + interrupts = <0x00 0x19 0x01>; + reg = <0x00 0xa001200 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001400 { + dma-coherent; + interrupts = <0x00 0x1a 0x01>; + reg = <0x00 0xa001400 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001600 { + dma-coherent; + interrupts = <0x00 0x1b 0x01>; + reg = <0x00 0xa001600 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001800 { + dma-coherent; + interrupts = <0x00 0x1c 0x01>; + reg = <0x00 0xa001800 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001a00 { + dma-coherent; + interrupts = <0x00 0x1d 0x01>; + reg = <0x00 0xa001a00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001c00 { + dma-coherent; + interrupts = <0x00 0x1e 0x01>; + reg = <0x00 0xa001c00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001e00 { + dma-coherent; + interrupts = <0x00 0x1f 0x01>; + reg = <0x00 0xa001e00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002000 { + dma-coherent; + interrupts = <0x00 0x20 0x01>; + reg = <0x00 0xa002000 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002200 { + dma-coherent; + interrupts = <0x00 0x21 0x01>; + reg = <0x00 0xa002200 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002400 { + dma-coherent; + interrupts = <0x00 0x22 0x01>; + reg = <0x00 0xa002400 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002600 { + dma-coherent; + interrupts = <0x00 0x23 0x01>; + reg = <0x00 0xa002600 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002800 { + dma-coherent; + interrupts = <0x00 0x24 0x01>; + reg = <0x00 0xa002800 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002a00 { + dma-coherent; + interrupts = <0x00 0x25 0x01>; + reg = <0x00 0xa002a00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002c00 { + dma-coherent; + interrupts = <0x00 0x26 0x01>; + reg = <0x00 0xa002c00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002e00 { + dma-coherent; + interrupts = <0x00 0x27 0x01>; + reg = <0x00 0xa002e00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003000 { + dma-coherent; + interrupts = <0x00 0x28 0x01>; + reg = <0x00 0xa003000 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003200 { + dma-coherent; + interrupts = <0x00 0x29 0x01>; + reg = <0x00 0xa003200 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003400 { + dma-coherent; + interrupts = <0x00 0x2a 0x01>; + reg = <0x00 0xa003400 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003600 { + dma-coherent; + interrupts = <0x00 0x2b 0x01>; + reg = <0x00 0xa003600 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003800 { + dma-coherent; + interrupts = <0x00 0x2c 0x01>; + reg = <0x00 0xa003800 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003a00 { + dma-coherent; + interrupts = <0x00 0x2d 0x01>; + reg = <0x00 0xa003a00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003c00 { + dma-coherent; + interrupts = <0x00 0x2e 0x01>; + reg = <0x00 0xa003c00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003e00 { + dma-coherent; + interrupts = <0x00 0x2f 0x01>; + reg = <0x00 0xa003e00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + gpio-keys { + #address-cells = <0x01>; + #size-cells = <0x00>; + compatible = "gpio-keys"; + + poweroff { + gpios = <0x8003 0x03 0x00>; + linux,code = <0x74>; + label = "GPIO Key Poweroff"; + }; + }; + + pl061@9030000 { + phandle = <0x8003>; + clock-names = "apb_pclk"; + clocks = <0x8000>; + interrupts = <0x00 0x07 0x04>; + gpio-controller; + #gpio-cells = <0x02>; + compatible = "arm,pl061\0arm,primecell"; + reg = <0x00 0x9030000 0x00 0x1000>; + }; + + pcie@10000000 { + interrupt-map-mask = <0x1800 0x00 0x00 0x07>; + interrupt-map = <0x00 0x00 0x00 0x01 0x8001 0x00 0x00 0x00 + 0x03 0x04 0x00 0x00 0x00 0x02 0x8001 0x00 + 0x00 0x00 0x04 0x04 0x00 0x00 0x00 0x03 + 0x8001 0x00 0x00 0x00 0x05 0x04 0x00 0x00 + 0x00 0x04 0x8001 0x00 0x00 0x00 0x06 0x04 + 0x800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00 + 0x04 0x04 0x800 0x00 0x00 0x02 0x8001 0x00 + 0x00 0x00 0x05 0x04 0x800 0x00 0x00 0x03 + 0x8001 0x00 0x00 0x00 0x06 0x04 0x800 0x00 + 0x00 0x04 0x8001 0x00 0x00 0x00 0x03 0x04 + 0x1000 0x00 0x00 0x01 0x8001 0x00 0x00 0x00 + 0x05 0x04 0x1000 0x00 0x00 0x02 0x8001 0x00 + 0x00 0x00 0x06 0x04 0x1000 0x00 0x00 0x03 + 0x8001 0x00 0x00 0x00 0x03 0x04 0x1000 0x00 + 0x00 0x04 0x8001 0x00 0x00 0x00 0x04 0x04 + 0x1800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00 + 0x06 0x04 0x1800 0x00 0x00 0x02 0x8001 0x00 + 0x00 0x00 0x03 0x04 0x1800 0x00 0x00 0x03 + 0x8001 0x00 0x00 0x00 0x04 0x04 0x1800 0x00 + 0x00 0x04 0x8001 0x00 0x00 0x00 0x05 0x04>; + #interrupt-cells = <0x01>; + ranges = <0x1000000 0x00 0x00 0x00 + 0x3eff0000 0x00 0x10000 0x2000000 + 0x00 0x10000000 0x00 0x10000000 + 0x00 0x2eff0000 0x3000000 0x80 + 0x00 0x80 0x00 0x80 + 0x00>; + reg = <0x00000000 0x3f000000 0x00000000 0x01000000>; + msi-parent = <0x8002>; + dma-coherent; + bus-range = <0x00 0x0f>; + linux,pci-domain = <0x00>; + #size-cells = <0x02>; + #address-cells = <0x03>; + device_type = "pci"; + compatible = "pci-host-ecam-generic"; + }; + + pl031@9010000 { + clock-names = "apb_pclk"; + clocks = <0x8000>; + interrupts = <0x00 0x02 0x04>; + reg = <0x00 0x9010000 0x00 0x1000>; + compatible = "arm,pl031\0arm,primecell"; + }; + + pl011@9000000 { + clock-names = "uartclk\0apb_pclk"; + clocks = <0x8000 0x8000>; + interrupts = <0x00 0x01 0x04>; + reg = <0x00 0x9000000 0x00 0x1000>; + compatible = "arm,pl011\0arm,primecell"; + }; + + pmu { + }; + + intc@8000000 { + phandle = <0x8001>; + reg = <0x00 0x8000000 0x00 0x10000 0x00 0x8010000 0x00 0x10000>; + compatible = "arm,cortex-a15-gic"; + ranges; + #size-cells = <0x02>; + #address-cells = <0x02>; + interrupt-controller; + #interrupt-cells = <0x03>; + + v2m@8020000 { + phandle = <0x8002>; + reg = <0x00 0x8020000 0x00 0x1000>; + msi-controller; + compatible = "arm,gic-v2m-frame"; + }; + }; + + flash@0 { + bank-width = <0x04>; + reg = <0x00 0x00 0x00 0x4000000 0x00 0x4000000 0x00 0x4000000>; + compatible = "cfi-flash"; + }; + + cpus { + #size-cells = <0x00>; + #address-cells = <0x01>; + + cpu@0 { + reg = <0x00>; + compatible = "arm,cortex-a15"; + device_type = "cpu"; + }; + }; + + timer { + interrupts = <0x01 0x0d 0x104 0x01 0x0e 0x104 0x01 0x0b 0x104 0x01 0x0a 0x104>; + always-on; + compatible = "arm,armv7-timer"; + }; + + apb-pclk { + phandle = <0x8000>; + clock-output-names = "clk24mhz"; + clock-frequency = <0x16e3600>; + #clock-cells = <0x00>; + compatible = "fixed-clock"; + }; + + chosen { + stdout-path = "/pl011@9000000"; + }; +}; diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig index ded58d387ad..81ca4ca9166 100644 --- a/configs/qemu_arm_defconfig +++ b/configs/qemu_arm_defconfig @@ -5,6 +5,7 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x40000 CONFIG_ENV_SECT_SIZE=0x40000 CONFIG_SYS_MALLOC_LEN=0x1000000 +CONFIG_DEFAULT_DEVICE_TREE="qemu-arm" CONFIG_TARGET_QEMU_ARM_32BIT=y CONFIG_ARMV7_LPAE=y CONFIG_AHCI=y
Add this file, generated from qemu, so there is a reference devicetree in the U-Boot tree.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
arch/arm/dts/Makefile | 2 +- arch/arm/dts/qemu-arm64.dts | 381 +++++++++++++++++++++++++++++++++++ configs/qemu_arm64_defconfig | 1 + 3 files changed, 383 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/qemu-arm64.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 7ab8b145f3f..e70293bb849 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1153,7 +1153,7 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) += imx8mm-cl-iot-gate-optee.dtb
dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb
-dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb +dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb qemu-arm64.dtb
targets += $(dtb-y)
diff --git a/arch/arm/dts/qemu-arm64.dts b/arch/arm/dts/qemu-arm64.dts new file mode 100644 index 00000000000..7590e49cc84 --- /dev/null +++ b/arch/arm/dts/qemu-arm64.dts @@ -0,0 +1,381 @@ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +/* + * Sample device tree for qemu_arm64 + + * Copyright 2021 Google LLC + */ + +/dts-v1/; + +/ { + interrupt-parent = <0x8001>; + #size-cells = <0x02>; + #address-cells = <0x02>; + compatible = "linux,dummy-virt"; + + psci { + migrate = <0xc4000005>; + cpu_on = <0xc4000003>; + cpu_off = <0x84000002>; + cpu_suspend = <0xc4000001>; + method = "hvc"; + compatible = "arm,psci-0.2\0arm,psci"; + }; + + memory@40000000 { + reg = <0x00 0x40000000 0x00 0x8000000>; + device_type = "memory"; + }; + + platform@c000000 { + interrupt-parent = <0x8001>; + ranges = <0x00 0x00 0xc000000 0x2000000>; + #address-cells = <0x01>; + #size-cells = <0x01>; + compatible = "qemu,platform\0simple-bus"; + }; + + fw-cfg@9020000 { + dma-coherent; + reg = <0x00 0x9020000 0x00 0x18>; + compatible = "qemu,fw-cfg-mmio"; + }; + + virtio_mmio@a000000 { + dma-coherent; + interrupts = <0x00 0x10 0x01>; + reg = <0x00 0xa000000 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000200 { + dma-coherent; + interrupts = <0x00 0x11 0x01>; + reg = <0x00 0xa000200 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000400 { + dma-coherent; + interrupts = <0x00 0x12 0x01>; + reg = <0x00 0xa000400 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000600 { + dma-coherent; + interrupts = <0x00 0x13 0x01>; + reg = <0x00 0xa000600 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000800 { + dma-coherent; + interrupts = <0x00 0x14 0x01>; + reg = <0x00 0xa000800 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000a00 { + dma-coherent; + interrupts = <0x00 0x15 0x01>; + reg = <0x00 0xa000a00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000c00 { + dma-coherent; + interrupts = <0x00 0x16 0x01>; + reg = <0x00 0xa000c00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000e00 { + dma-coherent; + interrupts = <0x00 0x17 0x01>; + reg = <0x00 0xa000e00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001000 { + dma-coherent; + interrupts = <0x00 0x18 0x01>; + reg = <0x00 0xa001000 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001200 { + dma-coherent; + interrupts = <0x00 0x19 0x01>; + reg = <0x00 0xa001200 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001400 { + dma-coherent; + interrupts = <0x00 0x1a 0x01>; + reg = <0x00 0xa001400 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001600 { + dma-coherent; + interrupts = <0x00 0x1b 0x01>; + reg = <0x00 0xa001600 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001800 { + dma-coherent; + interrupts = <0x00 0x1c 0x01>; + reg = <0x00 0xa001800 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001a00 { + dma-coherent; + interrupts = <0x00 0x1d 0x01>; + reg = <0x00 0xa001a00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001c00 { + dma-coherent; + interrupts = <0x00 0x1e 0x01>; + reg = <0x00 0xa001c00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001e00 { + dma-coherent; + interrupts = <0x00 0x1f 0x01>; + reg = <0x00 0xa001e00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002000 { + dma-coherent; + interrupts = <0x00 0x20 0x01>; + reg = <0x00 0xa002000 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002200 { + dma-coherent; + interrupts = <0x00 0x21 0x01>; + reg = <0x00 0xa002200 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002400 { + dma-coherent; + interrupts = <0x00 0x22 0x01>; + reg = <0x00 0xa002400 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002600 { + dma-coherent; + interrupts = <0x00 0x23 0x01>; + reg = <0x00 0xa002600 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002800 { + dma-coherent; + interrupts = <0x00 0x24 0x01>; + reg = <0x00 0xa002800 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002a00 { + dma-coherent; + interrupts = <0x00 0x25 0x01>; + reg = <0x00 0xa002a00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002c00 { + dma-coherent; + interrupts = <0x00 0x26 0x01>; + reg = <0x00 0xa002c00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a002e00 { + dma-coherent; + interrupts = <0x00 0x27 0x01>; + reg = <0x00 0xa002e00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003000 { + dma-coherent; + interrupts = <0x00 0x28 0x01>; + reg = <0x00 0xa003000 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003200 { + dma-coherent; + interrupts = <0x00 0x29 0x01>; + reg = <0x00 0xa003200 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003400 { + dma-coherent; + interrupts = <0x00 0x2a 0x01>; + reg = <0x00 0xa003400 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003600 { + dma-coherent; + interrupts = <0x00 0x2b 0x01>; + reg = <0x00 0xa003600 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003800 { + dma-coherent; + interrupts = <0x00 0x2c 0x01>; + reg = <0x00 0xa003800 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003a00 { + dma-coherent; + interrupts = <0x00 0x2d 0x01>; + reg = <0x00 0xa003a00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003c00 { + dma-coherent; + interrupts = <0x00 0x2e 0x01>; + reg = <0x00 0xa003c00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a003e00 { + dma-coherent; + interrupts = <0x00 0x2f 0x01>; + reg = <0x00 0xa003e00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + pcie@10000000 { + interrupt-map-mask = <0x1800 0x00 0x00 0x07>; + interrupt-map = <0x00 0x00 0x00 0x01 0x8001 0x00 0x00 0x00 + 0x03 0x04 0x00 0x00 0x00 0x02 0x8001 0x00 + 0x00 0x00 0x04 0x04 0x00 0x00 0x00 0x03 + 0x8001 0x00 0x00 0x00 0x05 0x04 0x00 0x00 + 0x00 0x04 0x8001 0x00 0x00 0x00 0x06 0x04 + 0x800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00 + 0x04 0x04 0x800 0x00 0x00 0x02 0x8001 0x00 + 0x00 0x00 0x05 0x04 0x800 0x00 0x00 0x03 + 0x8001 0x00 0x00 0x00 0x06 0x04 0x800 0x00 + 0x00 0x04 0x8001 0x00 0x00 0x00 0x03 0x04 + 0x1000 0x00 0x00 0x01 0x8001 0x00 0x00 0x00 + 0x05 0x04 0x1000 0x00 0x00 0x02 0x8001 0x00 + 0x00 0x00 0x06 0x04 0x1000 0x00 0x00 0x03 + 0x8001 0x00 0x00 0x00 0x03 0x04 0x1000 0x00 + 0x00 0x04 0x8001 0x00 0x00 0x00 0x04 0x04 + 0x1800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00 + 0x06 0x04 0x1800 0x00 0x00 0x02 0x8001 0x00 + 0x00 0x00 0x03 0x04 0x1800 0x00 0x00 0x03 + 0x8001 0x00 0x00 0x00 0x04 0x04 0x1800 0x00 + 0x00 0x04 0x8001 0x00 0x00 0x00 0x05 0x04>; + #interrupt-cells = <0x01>; + ranges = <0x1000000 0x00 0x00 0x00 + 0x3eff0000 0x00 0x10000 0x2000000 + 0x00 0x10000000 0x00 0x10000000 + 0x00 0x2eff0000 0x3000000 0x80 + 0x00 0x80 0x00 0x80 + 0x00>; + reg = <0x40 0x10000000 0x00 0x10000000>; + msi-parent = <0x8002>; + dma-coherent; + bus-range = <0x00 0xff>; + linux,pci-domain = <0x00>; + #size-cells = <0x02>; + #address-cells = <0x03>; + device_type = "pci"; + compatible = "pci-host-ecam-generic"; + }; + + pl031@9010000 { + clock-names = "apb_pclk"; + clocks = <0x8000>; + interrupts = <0x00 0x02 0x04>; + reg = <0x00 0x9010000 0x00 0x1000>; + compatible = "arm,pl031\0arm,primecell"; + }; + + pl011@9000000 { + clock-names = "uartclk\0apb_pclk"; + clocks = <0x8000 0x8000>; + interrupts = <0x00 0x01 0x04>; + reg = <0x00 0x9000000 0x00 0x1000>; + compatible = "arm,pl011\0arm,primecell"; + }; + + pmu { + interrupts = <0x01 0x07 0x104>; + compatible = "arm,armv8-pmuv3"; + }; + + intc@8000000 { + phandle = <0x8001>; + reg = <0x00 0x8000000 0x00 0x10000 0x00 0x8010000 0x00 0x10000>; + compatible = "arm,cortex-a15-gic"; + ranges; + #size-cells = <0x02>; + #address-cells = <0x02>; + interrupt-controller; + #interrupt-cells = <0x03>; + + v2m@8020000 { + phandle = <0x8002>; + reg = <0x00 0x8020000 0x00 0x1000>; + msi-controller; + compatible = "arm,gic-v2m-frame"; + }; + }; + + flash@0 { + bank-width = <0x04>; + reg = <0x00 0x00 0x00 0x4000000 0x00 0x4000000 0x00 0x4000000>; + compatible = "cfi-flash"; + }; + + cpus { + #size-cells = <0x00>; + #address-cells = <0x01>; + + cpu@0 { + reg = <0x00>; + compatible = "arm,cortex-a57"; + device_type = "cpu"; + }; + }; + + timer { + interrupts = <0x01 0x0d 0x104 0x01 0x0e 0x104 0x01 0x0b 0x104 0x01 0x0a 0x104>; + always-on; + compatible = "arm,armv8-timer\0arm,armv7-timer"; + }; + + apb-pclk { + phandle = <0x8000>; + clock-output-names = "clk24mhz"; + clock-frequency = <0x16e3600>; + #clock-cells = <0x00>; + compatible = "fixed-clock"; + }; + + chosen { + stdout-path = "/pl011@9000000"; + }; +}; diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig index cf5a03e8a2f..e51ce5c799f 100644 --- a/configs/qemu_arm64_defconfig +++ b/configs/qemu_arm64_defconfig @@ -5,6 +5,7 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x40000 CONFIG_ENV_SECT_SIZE=0x40000 CONFIG_SYS_MALLOC_LEN=0x1000000 +CONFIG_DEFAULT_DEVICE_TREE="qemu-arm64" CONFIG_AHCI=y CONFIG_DISTRO_DEFAULTS=y CONFIG_SYS_LOAD_ADDR=0x40200000
On Tue, 26 Oct 2021 at 01:33, Simon Glass sjg@chromium.org wrote:
Add this file, generated from qemu, so there is a reference devicetree in the U-Boot tree.
Signed-off-by: Simon Glass sjg@chromium.org
Note that the dtb you get from QEMU is only guaranteed to work if: 1) you run it on the exact same QEMU version you generated it with 2) you pass QEMU the exact same command line arguments you used when you generated it
thanks -- PMM
Hi Peter,
On Mon, 1 Nov 2021 at 04:48, Peter Maydell peter.maydell@linaro.org wrote:
On Tue, 26 Oct 2021 at 01:33, Simon Glass sjg@chromium.org wrote:
Add this file, generated from qemu, so there is a reference devicetree in the U-Boot tree.
Signed-off-by: Simon Glass sjg@chromium.org
Note that the dtb you get from QEMU is only guaranteed to work if:
- you run it on the exact same QEMU version you generated it with
- you pass QEMU the exact same command line arguments you used when you generated it
Yes, I certainly understand that. In general this is not safe, but in practice it works well enough for development and CI. I am able to use QEMU versions that differ by two years, partly because I am not trying to do anything clever.
I have sent a patch to add an indication of where the devicetree came from, to help with visibility on this.
Regards, Simon
Hi Simon
Le lun. 1 nov. 2021 à 17:58, Simon Glass sjg@chromium.org a écrit :
Hi Peter,
On Mon, 1 Nov 2021 at 04:48, Peter Maydell peter.maydell@linaro.org wrote:
On Tue, 26 Oct 2021 at 01:33, Simon Glass sjg@chromium.org wrote:
Add this file, generated from qemu, so there is a reference devicetree in the U-Boot tree.
Signed-off-by: Simon Glass sjg@chromium.org
Note that the dtb you get from QEMU is only guaranteed to work if:
- you run it on the exact same QEMU version you generated it with
- you pass QEMU the exact same command line arguments you used when you generated it
Yes, I certainly understand that. In general this is not safe, but in practice it works well enough for development and CI.
You recognize that you hijack a product directory with development hack facility. There is a test directory to keep things clear. There can be a dev-dts or something similar for Dev time tools. I have only seen push back on those fake dts files in the dts directory: I guess that unless someone strongly favors a continuation of the discussion, you may consider re-shaping the proposal to address concerns.
I am able to use QEMU versions that differ by two years, partly because I am not trying to do anything clever.
I have sent a patch to add an indication of where the devicetree came from, to help with visibility on this.
Regards, Simon
On Mon, Nov 01, 2021 at 06:33:35PM +0100, François Ozog wrote:
Hi Simon
Le lun. 1 nov. 2021 à 17:58, Simon Glass sjg@chromium.org a écrit :
Hi Peter,
On Mon, 1 Nov 2021 at 04:48, Peter Maydell peter.maydell@linaro.org wrote:
On Tue, 26 Oct 2021 at 01:33, Simon Glass sjg@chromium.org wrote:
Add this file, generated from qemu, so there is a reference devicetree in the U-Boot tree.
Signed-off-by: Simon Glass sjg@chromium.org
Note that the dtb you get from QEMU is only guaranteed to work if:
- you run it on the exact same QEMU version you generated it with
- you pass QEMU the exact same command line arguments you used when you generated it
Yes, I certainly understand that. In general this is not safe, but in practice it works well enough for development and CI.
You recognize that you hijack a product directory with development hack facility. There is a test directory to keep things clear. There can be a dev-dts or something similar for Dev time tools. I have only seen push back on those fake dts files in the dts directory: I guess that unless someone strongly favors a continuation of the discussion, you may consider re-shaping the proposal to address concerns.
Yes. We need to document how to make development easier. But I'm still not on board with the notion of including DTS files for platforms where the source of truth for the DTB is elsewhere. That's going to bring us a lot more pain.
It is important to make sure our "develop our project" workflow is sane and relatively pain free. But that needs to not come by making sacrifices to the "use our project" outcome. I would hope for example that the new Pi zero platform is just dtb changes, as far as the linux kernel is concerned which means that for rpi_arm64 (which uses run time dtb) it also just works. And that's what we want to see.
Hi Tom,
On Mon, 1 Nov 2021 at 12:07, Tom Rini trini@konsulko.com wrote:
On Mon, Nov 01, 2021 at 06:33:35PM +0100, François Ozog wrote:
Hi Simon
Le lun. 1 nov. 2021 à 17:58, Simon Glass sjg@chromium.org a écrit :
Hi Peter,
On Mon, 1 Nov 2021 at 04:48, Peter Maydell peter.maydell@linaro.org wrote:
On Tue, 26 Oct 2021 at 01:33, Simon Glass sjg@chromium.org wrote:
Add this file, generated from qemu, so there is a reference devicetree in the U-Boot tree.
Signed-off-by: Simon Glass sjg@chromium.org
Note that the dtb you get from QEMU is only guaranteed to work if:
- you run it on the exact same QEMU version you generated it with
- you pass QEMU the exact same command line arguments you used when you generated it
Yes, I certainly understand that. In general this is not safe, but in practice it works well enough for development and CI.
You recognize that you hijack a product directory with development hack facility. There is a test directory to keep things clear. There can be a dev-dts or something similar for Dev time tools. I have only seen push back on those fake dts files in the dts directory: I guess that unless someone strongly favors a continuation of the discussion, you may consider re-shaping the proposal to address concerns.
Yes. We need to document how to make development easier. But I'm still not on board with the notion of including DTS files for platforms where the source of truth for the DTB is elsewhere. That's going to bring us a lot more pain.
Are you talking about QEMU specifically, or Raspberry Pi?
How can we get this resolved? I very much want to get to just having OF_SEPARATE and OF_EMBED as the only available build-time options, with OF_BOARD (and perhaps OF_PASSAGE) as something we can enable for runtime support. I feel that separating the build-time and run-time behaviour is very important. Over time perhaps we will have some success in upstreaming bindings, but for now we have what we have. There is still a lot of pushback on U-Boot having things in the devicetree, although I do see that softening somewhat.
It is important to make sure our "develop our project" workflow is sane and relatively pain free. But that needs to not come by making sacrifices to the "use our project" outcome. I would hope for example that the new Pi zero platform is just dtb changes, as far as the linux kernel is concerned which means that for rpi_arm64 (which uses run time dtb) it also just works. And that's what we want to see.
So long as OF_BOARD is enabled then the flow should work as you expect.
Regards, Simon
On Tue, Nov 02, 2021 at 09:00:53AM -0600, Simon Glass wrote:
Hi Tom,
On Mon, 1 Nov 2021 at 12:07, Tom Rini trini@konsulko.com wrote:
On Mon, Nov 01, 2021 at 06:33:35PM +0100, François Ozog wrote:
Hi Simon
Le lun. 1 nov. 2021 à 17:58, Simon Glass sjg@chromium.org a écrit :
Hi Peter,
On Mon, 1 Nov 2021 at 04:48, Peter Maydell peter.maydell@linaro.org wrote:
On Tue, 26 Oct 2021 at 01:33, Simon Glass sjg@chromium.org wrote:
Add this file, generated from qemu, so there is a reference devicetree in the U-Boot tree.
Signed-off-by: Simon Glass sjg@chromium.org
Note that the dtb you get from QEMU is only guaranteed to work if:
- you run it on the exact same QEMU version you generated it with
- you pass QEMU the exact same command line arguments you used when you generated it
Yes, I certainly understand that. In general this is not safe, but in practice it works well enough for development and CI.
You recognize that you hijack a product directory with development hack facility. There is a test directory to keep things clear. There can be a dev-dts or something similar for Dev time tools. I have only seen push back on those fake dts files in the dts directory: I guess that unless someone strongly favors a continuation of the discussion, you may consider re-shaping the proposal to address concerns.
Yes. We need to document how to make development easier. But I'm still not on board with the notion of including DTS files for platforms where the source of truth for the DTB is elsewhere. That's going to bring us a lot more pain.
Are you talking about QEMU specifically, or Raspberry Pi?
I was using two of the more common and readily available platforms where the source of truth for the DTS/DTB is not (and will not be) U-Boot.
How can we get this resolved? I very much want to get to just having OF_SEPARATE and OF_EMBED as the only available build-time options, with OF_BOARD (and perhaps OF_PASSAGE) as something we can enable for runtime support. I feel that separating the build-time and run-time behaviour is very important. Over time perhaps we will have some success in upstreaming bindings, but for now we have what we have. There is still a lot of pushback on U-Boot having things in the devicetree, although I do see that softening somewhat.
To reiterate, the uniform bit of feedback on this series has been that everyone else disagrees with your notion that we _must_ have a dts in-tree.
It is important to make sure our "develop our project" workflow is sane and relatively pain free. But that needs to not come by making sacrifices to the "use our project" outcome. I would hope for example that the new Pi zero platform is just dtb changes, as far as the linux kernel is concerned which means that for rpi_arm64 (which uses run time dtb) it also just works. And that's what we want to see.
So long as OF_BOARD is enabled then the flow should work as you expect.
Then we need to get things spun such that we can build the platforms where the dtb is given to us, complete and correct, at run time, to not require an in-tree dts that's not going to be used. Documentation (another area we have much improved on these past few years and for which I am grateful for all of the effort behind!) is how we make the developer use-case for those platforms better.
Hi Tom,
On Tue, 2 Nov 2021 at 11:28, Tom Rini trini@konsulko.com wrote:
On Tue, Nov 02, 2021 at 09:00:53AM -0600, Simon Glass wrote:
Hi Tom,
On Mon, 1 Nov 2021 at 12:07, Tom Rini trini@konsulko.com wrote:
On Mon, Nov 01, 2021 at 06:33:35PM +0100, François Ozog wrote:
Hi Simon
Le lun. 1 nov. 2021 à 17:58, Simon Glass sjg@chromium.org a écrit :
Hi Peter,
On Mon, 1 Nov 2021 at 04:48, Peter Maydell peter.maydell@linaro.org wrote:
On Tue, 26 Oct 2021 at 01:33, Simon Glass sjg@chromium.org wrote: > > Add this file, generated from qemu, so there is a reference devicetree > in the U-Boot tree. > > Signed-off-by: Simon Glass sjg@chromium.org
Note that the dtb you get from QEMU is only guaranteed to work if:
- you run it on the exact same QEMU version you generated it with
- you pass QEMU the exact same command line arguments you used when you generated it
Yes, I certainly understand that. In general this is not safe, but in practice it works well enough for development and CI.
You recognize that you hijack a product directory with development hack facility. There is a test directory to keep things clear. There can be a dev-dts or something similar for Dev time tools. I have only seen push back on those fake dts files in the dts directory: I guess that unless someone strongly favors a continuation of the discussion, you may consider re-shaping the proposal to address concerns.
Yes. We need to document how to make development easier. But I'm still not on board with the notion of including DTS files for platforms where the source of truth for the DTB is elsewhere. That's going to bring us a lot more pain.
Are you talking about QEMU specifically, or Raspberry Pi?
I was using two of the more common and readily available platforms where the source of truth for the DTS/DTB is not (and will not be) U-Boot.
How can we get this resolved? I very much want to get to just having OF_SEPARATE and OF_EMBED as the only available build-time options, with OF_BOARD (and perhaps OF_PASSAGE) as something we can enable for runtime support. I feel that separating the build-time and run-time behaviour is very important. Over time perhaps we will have some success in upstreaming bindings, but for now we have what we have. There is still a lot of pushback on U-Boot having things in the devicetree, although I do see that softening somewhat.
To reiterate, the uniform bit of feedback on this series has been that everyone else disagrees with your notion that we _must_ have a dts in-tree.
[I would like everyone to take a deep breath and think about what this actually impacts. I argue the impact outside U-Boot is approximately zero. What are we actually discussing here?]
A few have responded that they can just add the files. I think that is the case for everything except QEMU, right? I think even François agrees with the documentation argument. There is no real burden in adding the files so we can see what is going on, add a binman node, SPL nodes, etc.
So I am going to stand my ground on that one. It affects:
- highbank - qemu-ppce500 - rpi_4 - xilinx_versal_virt - octeontx - xenguest_arm64 - juno
So that is just 7 boards that I want to add devicetree files for. I think that is reasonable and not a burden on these maintainers.
Let me deal with QEMU.
Let's imagine that we were in the state that I am proposing here, which we would be if I were a better devicetree maintainer for U-Boot and had not taken my eye off the ball, basically with my review of [1], where I should have pushed to get a response on the questions before it was applied. That might have triggered me to think about the implications of this at the time.
Anyway, in the state that I am proposing, what problems would we have?
1. QEMU has a DT which only matches the 'standard' invocation as documented at [2]
2. QEMU may get out of date if there is a new release.
I don't think (1) is really a problem. People will have to remove CONFIG_OF_BOARD from configs/qemu_arm_spl_defconfig (or the like) to get into this state, and we have a message now that prints out where the devicetree comes from ("separate" in this case):
Core: 42 devices, 11 uclasses, devicetree: separate
For (2), I tested QEMU 6.1.50 and the only difference from 4.2.1 (a year old) is:
kaslr-seed = <0x2037f53d 0x42c279e8>;
It doesn't affect anything here. It boots the lastest image fine.
Just for interest I went back to 2.5.0 which is nearly 6 years old! There are a few differences like dma-coherent and gpio-keys being added, but again it boots fine.
So in practice that doesn't seem to be a problem from what I can tell.
3. Anything else?
For qemu_arm_spl, it *does not boot* unless the U-Boot SPL properties are present. There is no easy way to fix this. If we merge them into qemu with dumpdtb, etc. we are assuming that the node we want to update is present, so this is not really any better than having the devicetree in U-Boot. Actually I think it is worse, since who knows what changes might happen to the devicetree in QEMU which will stop U-Boot from working.
QEMU cannot make changes that don't follow the bindings. U-Boot uses the bindings, so we are good.
It just seems very clear to me that this approach is far superior to U-Boot to the wonky business that we have today.
It is important to make sure our "develop our project" workflow is sane and relatively pain free. But that needs to not come by making sacrifices to the "use our project" outcome. I would hope for example that the new Pi zero platform is just dtb changes, as far as the linux kernel is concerned which means that for rpi_arm64 (which uses run time dtb) it also just works. And that's what we want to see.
So long as OF_BOARD is enabled then the flow should work as you expect.
Then we need to get things spun such that we can build the platforms where the dtb is given to us, complete and correct, at run time, to not require an in-tree dts that's not going to be used. Documentation (another area we have much improved on these past few years and for which I am grateful for all of the effort behind!) is how we make the developer use-case for those platforms better.
I did not expect everyone to love this; this is how we got into the mess we are in. A few people thinking it would be expedient to just do their own thing. But I have come to this after an enormous amount of thought and much discussion. I think sometimes people imagine that I just throw things over the wall to get a reaction. That is not the case.
We need some way to put U-Boot properties in there, at least until things change upstream and within U-Boot. That envisages tooling that is clearly not going to be in place for the upcoming release.
For the test, how about I create a separate qemu build (which I have done, actually, qemu_arm_spl) and control the QEMU flags so we know it will boot. It is for CI so we can keep it in sync and deal with any breakages if people change things in QEMU (as above, this seems to be a theoretical problem).
Again, please take a deep breath and consider how much this actually affects TF-A, QEMU, etc. I'd argue not at all. We are talking about a build-time devicetree in the U-Boot tree. We are not talking about disabling OF_BOARD or removing that option.
Regards, Simon
[1] http://patchwork.ozlabs.org/project/uboot/patch/20170402082520.32546-1-deymo... [2] https://u-boot.readthedocs.io/en/latest/board/emulation/qemu-arm.html
Hi Simon
Le mer. 3 nov. 2021 à 02:30, Simon Glass sjg@chromium.org a écrit :
Hi Tom,
On Tue, 2 Nov 2021 at 11:28, Tom Rini trini@konsulko.com wrote:
On Tue, Nov 02, 2021 at 09:00:53AM -0600, Simon Glass wrote:
Hi Tom,
On Mon, 1 Nov 2021 at 12:07, Tom Rini trini@konsulko.com wrote:
On Mon, Nov 01, 2021 at 06:33:35PM +0100, François Ozog wrote:
Hi Simon
Le lun. 1 nov. 2021 à 17:58, Simon Glass sjg@chromium.org a
écrit :
Hi Peter,
On Mon, 1 Nov 2021 at 04:48, Peter Maydell <
peter.maydell@linaro.org>
wrote: > > On Tue, 26 Oct 2021 at 01:33, Simon Glass sjg@chromium.org
wrote:
> > > > Add this file, generated from qemu, so there is a reference
devicetree
> > in the U-Boot tree. > > > > Signed-off-by: Simon Glass sjg@chromium.org > > Note that the dtb you get from QEMU is only guaranteed to work
if:
> 1) you run it on the exact same QEMU version you generated it
with
> 2) you pass QEMU the exact same command line arguments you
used
> when you generated it
Yes, I certainly understand that. In general this is not safe,
but in
practice it works well enough for development and CI.
You recognize that you hijack a product directory with development
hack
facility. There is a test directory to keep things clear. There
can be a
dev-dts or something similar for Dev time tools. I have only seen push back on those fake dts files in the dts
directory: I
guess that unless someone strongly favors a continuation of the
discussion,
you may consider re-shaping the proposal to address concerns.
Yes. We need to document how to make development easier. But I'm
still
not on board with the notion of including DTS files for platforms
where
the source of truth for the DTB is elsewhere. That's going to bring
us
a lot more pain.
Are you talking about QEMU specifically, or Raspberry Pi?
I was using two of the more common and readily available platforms where the source of truth for the DTS/DTB is not (and will not be) U-Boot.
How can we get this resolved? I very much want to get to just having OF_SEPARATE and OF_EMBED as the only available build-time options, with OF_BOARD (and perhaps OF_PASSAGE) as something we can enable for runtime support. I feel that separating the build-time and run-time behaviour is very important. Over time perhaps we will have some success in upstreaming bindings, but for now we have what we have. There is still a lot of pushback on U-Boot having things in the devicetree, although I do see that softening somewhat.
To reiterate, the uniform bit of feedback on this series has been that everyone else disagrees with your notion that we _must_ have a dts in-tree.
[I would like everyone to take a deep breath and think about what this actually impacts. I argue the impact outside U-Boot is approximately zero. What are we actually discussing here?]
A few have responded that they can just add the files. I think that is the case for everything except QEMU, right? I think even François agrees with the documentation argument.
I do providing that the sample goes into documentation, not actionable as a build artifact in the dts directory.
There is no real burden in adding the files so we can see what is going on, add a binman node, SPL nodes, etc.
So I am going to stand my ground on that one. It affects:
- highbank
- qemu-ppce500
- rpi_4
- xilinx_versal_virt
- octeontx
- xenguest_arm64
- juno
So that is just 7 boards that I want to add devicetree files for. I think that is reasonable and not a burden on these maintainers.
Let me deal with QEMU.
Let's imagine that we were in the state that I am proposing here, which we would be if I were a better devicetree maintainer for U-Boot and had not taken my eye off the ball, basically with my review of [1], where I should have pushed to get a response on the questions before it was applied. That might have triggered me to think about the implications of this at the time.
Anyway, in the state that I am proposing, what problems would we have?
- QEMU has a DT which only matches the 'standard' invocation as
documented at [2]
- QEMU may get out of date if there is a new release.
I don't think (1) is really a problem. People will have to remove CONFIG_OF_BOARD from configs/qemu_arm_spl_defconfig (or the like) to get into this state, and we have a message now that prints out where the devicetree comes from ("separate" in this case):
Core: 42 devices, 11 uclasses, devicetree: separate
For (2), I tested QEMU 6.1.50 and the only difference from 4.2.1 (a year old) is:
kaslr-seed = <0x2037f53d 0x42c279e8>;
It doesn't affect anything here. It boots the lastest image fine.
Just for interest I went back to 2.5.0 which is nearly 6 years old! There are a few differences like dma-coherent and gpio-keys being added, but again it boots fine.
So in practice that doesn't seem to be a problem from what I can tell.
You are essentially saying “I don’t care about the system design, this DTS simplifies my development work for U-Boot and I checked it works on a useless ‘standard invocation’”
- Anything else?
For qemu_arm_spl, it *does not boot* unless the U-Boot SPL properties are present. There is no easy way to fix this.
one clean and easy way would be to upstream a Qemu change to merge a supplied overlay to the generated one. This the same idea as applying the NT_FW_COnFIG overlay in the TFA world. In both cases previous loaders do their job properly for U-Boot : setting up the stage as needed.
If we merge them into qemu with dumpdtb, etc. we are assuming that the node we want to update is present, so this is not really any better than having the devicetree in U-Boot. Actually I think it is worse, since who knows what changes might happen to the devicetree in QEMU which will stop U-Boot from working.
QEMU cannot make changes that don't follow the bindings. U-Boot uses the bindings, so we are good.
It just seems very clear to me that this approach is far superior to U-Boot to the wonky business that we have today.
It is important to make sure our "develop our project" workflow is
sane
and relatively pain free. But that needs to not come by making sacrifices to the "use our project" outcome. I would hope for
example
that the new Pi zero platform is just dtb changes, as far as the
linux
kernel is concerned which means that for rpi_arm64 (which uses run
time
dtb) it also just works. And that's what we want to see.
So long as OF_BOARD is enabled then the flow should work as you expect.
Then we need to get things spun such that we can build the platforms where the dtb is given to us, complete and correct, at run time, to not require an in-tree dts that's not going to be used. Documentation (another area we have much improved on these past few years and for which I am grateful for all of the effort behind!) is how we make the developer use-case for those platforms better.
I did not expect everyone to love this; this is how we got into the mess we are in. A few people thinking it would be expedient to just do their own thing. But I have come to this after an enormous amount of thought and much discussion. I think sometimes people imagine that I just throw things over the wall to get a reaction. That is not the case.
We need some way to put U-Boot properties in there, at least until things change upstream and within U-Boot. That envisages tooling that is clearly not going to be in place for the upcoming release.
For the test, how about I create a separate qemu build (which I have done, actually, qemu_arm_spl) and control the QEMU flags so we know it will boot. It is for CI so we can keep it in sync and deal with any breakages if people change things in QEMU (as above, this seems to be a theoretical problem).
Again, please take a deep breath and consider how much this actually affects TF-A, QEMU, etc. I'd argue not at all. We are talking about a build-time devicetree in the U-Boot tree. We are not talking about disabling OF_BOARD or removing that option.
It is less about development environnement and respective CIs and more about how we want to deliver products on the market and how the supply chain is organized. U-Boot is a key component of that chain. If something is missing from the previous stages of the chain, don’t try to work around the problem in U-Boot, just propose the change/correction in the relevant project (Qemu, TFA, RPI Videocore…) or ask for help. If nothing can be resolved “the clean way” then we can hack our way out (Qemu fork you proposed). But let’s try the clean path first.
Regards, Simon
[1] http://patchwork.ozlabs.org/project/uboot/patch/20170402082520.32546-1-deymo... [2] https://u-boot.readthedocs.io/en/latest/board/emulation/qemu-arm.html
On Wed, Nov 03, 2021 at 06:29:20AM +0100, François Ozog wrote: [snip]
- Anything else?
For qemu_arm_spl, it *does not boot* unless the U-Boot SPL properties are present. There is no easy way to fix this.
one clean and easy way would be to upstream a Qemu change to merge a supplied overlay to the generated one. This the same idea as applying the NT_FW_COnFIG overlay in the TFA world. In both cases previous loaders do their job properly for U-Boot : setting up the stage as needed.
For the record, I believe Simon did propose this and the QEMU response was that no, you should dumpdtb, combine externally and pass that directly.
On Wed, 3 Nov 2021 at 14:41, Tom Rini trini@konsulko.com wrote:
On Wed, Nov 03, 2021 at 06:29:20AM +0100, François Ozog wrote: [snip]
- Anything else?
For qemu_arm_spl, it *does not boot* unless the U-Boot SPL properties are present. There is no easy way to fix this.
one clean and easy way would be to upstream a Qemu change to merge a supplied overlay to the generated one. This the same idea as applying the NT_FW_COnFIG overlay in the TFA world. In both cases previous loaders do their job properly for U-Boot : setting up the stage as needed.
For the record, I believe Simon did propose this and the QEMU response was that no, you should dumpdtb, combine externally and pass that directly.
Well, our recommendation really was that the ideal thing would be "you take the dtb that QEMU passes you at runtime, and at runtime combine that with whatever extra information you want". The dumpdtb option is primarily intended as a debug feature, so you can have a look at the dtb QEMU created to see why your OS isn't booting; although you can script stuff up that does a dumpdtb-modify-pass-to-QEMU that is pretty clunky given the need to invoke QEMU twice with matching arguments both times.
-- PMM
hi Peter
Le jeu. 4 nov. 2021 à 12:09, Peter Maydell peter.maydell@linaro.org a écrit :
On Wed, 3 Nov 2021 at 14:41, Tom Rini trini@konsulko.com wrote:
On Wed, Nov 03, 2021 at 06:29:20AM +0100, François Ozog wrote: [snip]
- Anything else?
For qemu_arm_spl, it *does not boot* unless the U-Boot SPL properties are present. There is no easy way to fix this.
one clean and easy way would be to upstream a Qemu change to merge a supplied overlay to the generated one. This the same idea as applying
the
NT_FW_COnFIG overlay in the TFA world. In both cases previous loaders
do
their job properly for U-Boot : setting up the stage as needed.
For the record, I believe Simon did propose this and the QEMU response was that no, you should dumpdtb, combine externally and pass that directly.
Well, our recommendation really was that the ideal thing would be "you take the dtb that QEMU passes you at runtime, and at runtime combine that with whatever extra information you want".
That looks just reasonable this way. Runtime merging may need to be done before control is actually transferred. We have that problem on real board where we need to inject a TPM device for measured boot and it is not énumerable and pluggable. With TFA we have the option to add the TPM description in the NT_FW_CONFIG and merge it at run time. So we need a « -mergedtb » option for Qemu to have the same capability. This would merge the QEMU generated one with the command line provided.
The dumpdtb option is primarily intended as a debug feature,
so you can have a look at the dtb QEMU created to see why your OS isn't booting; although you can script stuff up that does a dumpdtb-modify-pass-to-QEMU that is pretty clunky given the need to invoke QEMU twice with matching arguments both times.
-- PMM
On Thu, 4 Nov 2021 at 11:22, François Ozog francois.ozog@linaro.org wrote:
Le jeu. 4 nov. 2021 à 12:09, Peter Maydell peter.maydell@linaro.org a écrit :
Well, our recommendation really was that the ideal thing would be "you take the dtb that QEMU passes you at runtime, and at runtime combine that with whatever extra information you want".
That looks just reasonable this way.
So we need a « -mergedtb » option for Qemu to have the same capability. This would merge the QEMU generated one with the command line provided.
No, I mean that the guest, ie u-boot, should do the merging, not QEMU.
-- PMM
Hi Peter
Le jeu. 4 nov. 2021 à 12:41, Peter Maydell peter.maydell@linaro.org a écrit :
On Thu, 4 Nov 2021 at 11:22, François Ozog francois.ozog@linaro.org wrote:
Le jeu. 4 nov. 2021 à 12:09, Peter Maydell peter.maydell@linaro.org a
écrit :
Well, our recommendation really was that the ideal thing would be "you take the dtb that QEMU passes you at runtime, and at runtime combine that with whatever extra information you want".
That looks just reasonable this way.
So we need a « -mergedtb » option for Qemu to have the same capability. This would merge the QEMU generated one with the command line provided.
No, I mean that the guest, ie u-boot, should do the merging, not QEMU.
for most of the cases it works. But, as I tried to explain some cases need earlier merging hence trying to get QEMU do the same thing as TFA as « prior loaders » in the boot chain. Worst case we can have the behavior by booting TFA then U-Boot then Linux under QEMU, but the best would be to get the facility directly when TFA is not on the path of the boot like with the VBE boot flow.
-- PMM
Hi Simon, and team
On Wed, 3 Nov 2021 at 06:29, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Le mer. 3 nov. 2021 à 02:30, Simon Glass sjg@chromium.org a écrit :
Hi Tom,
On Tue, 2 Nov 2021 at 11:28, Tom Rini trini@konsulko.com wrote:
On Tue, Nov 02, 2021 at 09:00:53AM -0600, Simon Glass wrote:
Hi Tom,
On Mon, 1 Nov 2021 at 12:07, Tom Rini trini@konsulko.com wrote:
On Mon, Nov 01, 2021 at 06:33:35PM +0100, François Ozog wrote:
Hi Simon
Le lun. 1 nov. 2021 à 17:58, Simon Glass sjg@chromium.org a
écrit :
> Hi Peter, > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell <
peter.maydell@linaro.org>
> wrote: > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass sjg@chromium.org
wrote:
> > > > > > Add this file, generated from qemu, so there is a reference
devicetree
> > > in the U-Boot tree. > > > > > > Signed-off-by: Simon Glass sjg@chromium.org > > > > Note that the dtb you get from QEMU is only guaranteed to
work if:
> > 1) you run it on the exact same QEMU version you generated
it with
> > 2) you pass QEMU the exact same command line arguments you
used
> > when you generated it > > Yes, I certainly understand that. In general this is not safe,
but in
> practice it works well enough for development and CI.
You recognize that you hijack a product directory with
development hack
facility. There is a test directory to keep things clear. There
can be a
dev-dts or something similar for Dev time tools. I have only seen push back on those fake dts files in the dts
directory: I
guess that unless someone strongly favors a continuation of the
discussion,
you may consider re-shaping the proposal to address concerns.
Yes. We need to document how to make development easier. But I'm
still
not on board with the notion of including DTS files for platforms
where
the source of truth for the DTB is elsewhere. That's going to
bring us
a lot more pain.
Are you talking about QEMU specifically, or Raspberry Pi?
I was using two of the more common and readily available platforms where the source of truth for the DTS/DTB is not (and will not be) U-Boot.
How can we get this resolved? I very much want to get to just having OF_SEPARATE and OF_EMBED as the only available build-time options, with OF_BOARD (and perhaps OF_PASSAGE) as something we can enable for runtime support. I feel that separating the build-time and run-time behaviour is very important. Over time perhaps we will have some success in upstreaming bindings, but for now we have what we have. There is still a lot of pushback on U-Boot having things in the devicetree, although I do see that softening somewhat.
To reiterate, the uniform bit of feedback on this series has been that everyone else disagrees with your notion that we _must_ have a dts in-tree.
[I would like everyone to take a deep breath and think about what this actually impacts. I argue the impact outside U-Boot is approximately zero. What are we actually discussing here?]
A few have responded that they can just add the files. I think that is the case for everything except QEMU, right? I think even François agrees with the documentation argument.
I do providing that the sample goes into documentation, not actionable as a build artifact in the dts directory.
There is no real burden in adding the files so we can see what is going on, add a binman node, SPL nodes, etc.
So I am going to stand my ground on that one. It affects:
- highbank
- qemu-ppce500
- rpi_4
- xilinx_versal_virt
- octeontx
- xenguest_arm64
- juno
So that is just 7 boards that I want to add devicetree files for. I think that is reasonable and not a burden on these maintainers.
Let me deal with QEMU.
Let's imagine that we were in the state that I am proposing here, which we would be if I were a better devicetree maintainer for U-Boot and had not taken my eye off the ball, basically with my review of [1], where I should have pushed to get a response on the questions before it was applied. That might have triggered me to think about the implications of this at the time.
Anyway, in the state that I am proposing, what problems would we have?
- QEMU has a DT which only matches the 'standard' invocation as
documented at [2]
- QEMU may get out of date if there is a new release.
I don't think (1) is really a problem. People will have to remove CONFIG_OF_BOARD from configs/qemu_arm_spl_defconfig (or the like) to get into this state, and we have a message now that prints out where the devicetree comes from ("separate" in this case):
Core: 42 devices, 11 uclasses, devicetree: separate
For (2), I tested QEMU 6.1.50 and the only difference from 4.2.1 (a year old) is:
kaslr-seed = <0x2037f53d 0x42c279e8>;
It doesn't affect anything here. It boots the lastest image fine.
Just for interest I went back to 2.5.0 which is nearly 6 years old! There are a few differences like dma-coherent and gpio-keys being added, but again it boots fine.
So in practice that doesn't seem to be a problem from what I can tell.
You are essentially saying “I don’t care about the system design, this DTS simplifies my development work for U-Boot and I checked it works on a useless ‘standard invocation’”
- Anything else?
For qemu_arm_spl, it *does not boot* unless the U-Boot SPL properties are present. There is no easy way to fix this.
one clean and easy way would be to upstream a Qemu change to merge a supplied overlay to the generated one. This the same idea as applying the NT_FW_COnFIG overlay in the TFA world. In both cases previous loaders do their job properly for U-Boot : setting up the stage as needed.
I was pointed to your proposal in Qemu mailing list and added my support to it. I could not comment on the exact details of the proposal, but commented on the fact that merging a DT fragment provided to Qemu at runtime makes sense and has some precedent in TFA.
If we merge them into
qemu with dumpdtb, etc. we are assuming that the node we want to update is present, so this is not really any better than having the devicetree in U-Boot. Actually I think it is worse, since who knows what changes might happen to the devicetree in QEMU which will stop U-Boot from working.
QEMU cannot make changes that don't follow the bindings. U-Boot uses the bindings, so we are good.
It just seems very clear to me that this approach is far superior to U-Boot to the wonky business that we have today.
It is important to make sure our "develop our project" workflow is
sane
and relatively pain free. But that needs to not come by making sacrifices to the "use our project" outcome. I would hope for
example
that the new Pi zero platform is just dtb changes, as far as the
linux
kernel is concerned which means that for rpi_arm64 (which uses run
time
dtb) it also just works. And that's what we want to see.
So long as OF_BOARD is enabled then the flow should work as you
expect.
Then we need to get things spun such that we can build the platforms where the dtb is given to us, complete and correct, at run time, to not require an in-tree dts that's not going to be used. Documentation (another area we have much improved on these past few years and for which I am grateful for all of the effort behind!) is how we make the developer use-case for those platforms better.
I did not expect everyone to love this; this is how we got into the mess we are in. A few people thinking it would be expedient to just do their own thing. But I have come to this after an enormous amount of thought and much discussion. I think sometimes people imagine that I just throw things over the wall to get a reaction. That is not the case.
We need some way to put U-Boot properties in there, at least until things change upstream and within U-Boot. That envisages tooling that is clearly not going to be in place for the upcoming release.
For the test, how about I create a separate qemu build (which I have done, actually, qemu_arm_spl) and control the QEMU flags so we know it will boot. It is for CI so we can keep it in sync and deal with any breakages if people change things in QEMU (as above, this seems to be a theoretical problem).
Again, please take a deep breath and consider how much this actually affects TF-A, QEMU, etc. I'd argue not at all. We are talking about a build-time devicetree in the U-Boot tree. We are not talking about disabling OF_BOARD or removing that option.
It is less about development environnement and respective CIs and more about how we want to deliver products on the market and how the supply chain is organized. U-Boot is a key component of that chain. If something is missing from the previous stages of the chain, don’t try to work around the problem in U-Boot, just propose the change/correction in the relevant project (Qemu, TFA, RPI Videocore…) or ask for help. If nothing can be resolved “the clean way” then we can hack our way out (Qemu fork you proposed). But let’s try the clean path first.
Regards, Simon
[1] http://patchwork.ozlabs.org/project/uboot/patch/20170402082520.32546-1-deymo... [2] https://u-boot.readthedocs.io/en/latest/board/emulation/qemu-arm.html
-- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
On Tue, Nov 02, 2021 at 07:29:54PM -0600, Simon Glass wrote:
Hi Tom,
On Tue, 2 Nov 2021 at 11:28, Tom Rini trini@konsulko.com wrote:
On Tue, Nov 02, 2021 at 09:00:53AM -0600, Simon Glass wrote:
Hi Tom,
On Mon, 1 Nov 2021 at 12:07, Tom Rini trini@konsulko.com wrote:
On Mon, Nov 01, 2021 at 06:33:35PM +0100, François Ozog wrote:
Hi Simon
Le lun. 1 nov. 2021 à 17:58, Simon Glass sjg@chromium.org a écrit :
Hi Peter,
On Mon, 1 Nov 2021 at 04:48, Peter Maydell peter.maydell@linaro.org wrote: > > On Tue, 26 Oct 2021 at 01:33, Simon Glass sjg@chromium.org wrote: > > > > Add this file, generated from qemu, so there is a reference devicetree > > in the U-Boot tree. > > > > Signed-off-by: Simon Glass sjg@chromium.org > > Note that the dtb you get from QEMU is only guaranteed to work if: > 1) you run it on the exact same QEMU version you generated it with > 2) you pass QEMU the exact same command line arguments you used > when you generated it
Yes, I certainly understand that. In general this is not safe, but in practice it works well enough for development and CI.
You recognize that you hijack a product directory with development hack facility. There is a test directory to keep things clear. There can be a dev-dts or something similar for Dev time tools. I have only seen push back on those fake dts files in the dts directory: I guess that unless someone strongly favors a continuation of the discussion, you may consider re-shaping the proposal to address concerns.
Yes. We need to document how to make development easier. But I'm still not on board with the notion of including DTS files for platforms where the source of truth for the DTB is elsewhere. That's going to bring us a lot more pain.
Are you talking about QEMU specifically, or Raspberry Pi?
I was using two of the more common and readily available platforms where the source of truth for the DTS/DTB is not (and will not be) U-Boot.
How can we get this resolved? I very much want to get to just having OF_SEPARATE and OF_EMBED as the only available build-time options, with OF_BOARD (and perhaps OF_PASSAGE) as something we can enable for runtime support. I feel that separating the build-time and run-time behaviour is very important. Over time perhaps we will have some success in upstreaming bindings, but for now we have what we have. There is still a lot of pushback on U-Boot having things in the devicetree, although I do see that softening somewhat.
To reiterate, the uniform bit of feedback on this series has been that everyone else disagrees with your notion that we _must_ have a dts in-tree.
[I would like everyone to take a deep breath and think about what this actually impacts. I argue the impact outside U-Boot is approximately zero. What are we actually discussing here?]
We're discussing what the point of these files even is. And ensuring that it doesn't lead to some sort of "feature creep" or similar where they do become required to use.
A few have responded that they can just add the files. I think that is
Yes, you've asked a number of people to do something, and given your position with the community they just said OK.
the case for everything except QEMU, right? I think even François agrees with the documentation argument. There is no real burden in adding the files so we can see what is going on, add a binman node, SPL nodes, etc.
I know François already replied, so I'm replying for myself here. What is the point of these files, if they are not going to ever be used, other than as documentation? So that people that don't have a given platform can more easily browse the device tree for it? That's a documentation fix (doc/board/... should note where to go to find it).
So I am going to stand my ground on that one. It affects:
- highbank
- qemu-ppce500
- rpi_4
- xilinx_versal_virt
- octeontx
- xenguest_arm64
- juno
So that is just 7 boards that I want to add devicetree files for. I think that is reasonable and not a burden on these maintainers.
It effects every board where the source of truth for the DT is not the one we're embedding because the hardware doesn't ship with one on it. That's all of the QEMU targets, all of the Pi targets and a growing list of newer hardware too, due to the push for "the hardware should come with the device tree, not the linux kernel" portion of how DT has been intended to work since forever getting realized more often.
Let me deal with QEMU.
Let's imagine that we were in the state that I am proposing here, which we would be if I were a better devicetree maintainer for U-Boot and had not taken my eye off the ball, basically with my review of [1], where I should have pushed to get a response on the questions before it was applied. That might have triggered me to think about the implications of this at the time.
Anyway, in the state that I am proposing, what problems would we have?
- QEMU has a DT which only matches the 'standard' invocation as
documented at [2]
- QEMU may get out of date if there is a new release.
I don't think (1) is really a problem. People will have to remove CONFIG_OF_BOARD from configs/qemu_arm_spl_defconfig (or the like) to get into this state, and we have a message now that prints out where the devicetree comes from ("separate" in this case):
Core: 42 devices, 11 uclasses, devicetree: separate
For (2), I tested QEMU 6.1.50 and the only difference from 4.2.1 (a year old) is:
kaslr-seed = <0x2037f53d 0x42c279e8>;
It doesn't affect anything here. It boots the lastest image fine.
Just for interest I went back to 2.5.0 which is nearly 6 years old! There are a few differences like dma-coherent and gpio-keys being added, but again it boots fine.
So in practice that doesn't seem to be a problem from what I can tell.
- Anything else?
Yes, a TPM (or not) existing.
For qemu_arm_spl, it *does not boot* unless the U-Boot SPL properties are present. There is no easy way to fix this. If we merge them into qemu with dumpdtb, etc. we are assuming that the node we want to update is present, so this is not really any better than having the devicetree in U-Boot. Actually I think it is worse, since who knows what changes might happen to the devicetree in QEMU which will stop U-Boot from working.
QEMU cannot make changes that don't follow the bindings. U-Boot uses the bindings, so we are good.
It just seems very clear to me that this approach is far superior to U-Boot to the wonky business that we have today.
We also need to be clear what the point of QEMU virtual machine support is. It's to enable testing of features that we also want to test on real hardware, to the extent possible. The follow up to that point is when we use QEMU to emulate real hardware to again test U-Boot to the extent possible. Given the list of hardware on https://qemu.readthedocs.io/en/latest/system/target-arm.html (and to be clear, I've not validated every possible board there) I would be hopeful that we can cover all of the features we need on real hardware by emulating specific targets in CI.
Where the source of truth for the device tree is provided to us at run time when we start executing (so yes, the dtb that the Pi firmware assembles from files on the SD card or the one QEMU passes or the one that exists on SPI flash somewhere or ...) we must use that tree. We must not build a full separate tree because that would never be used at run time.
That may mean that some features are not going to be supported right there (so yes, SPL in QEMU virtual machine on ARM) ever, or without some additional reasoning and work because it's useful to end users (figuring out a good way to generate a .dtbo so that the Pi firmware could still have a flawed but possibly better than nothing verified boot flow).
It is important to make sure our "develop our project" workflow is sane and relatively pain free. But that needs to not come by making sacrifices to the "use our project" outcome. I would hope for example that the new Pi zero platform is just dtb changes, as far as the linux kernel is concerned which means that for rpi_arm64 (which uses run time dtb) it also just works. And that's what we want to see.
So long as OF_BOARD is enabled then the flow should work as you expect.
Then we need to get things spun such that we can build the platforms where the dtb is given to us, complete and correct, at run time, to not require an in-tree dts that's not going to be used. Documentation (another area we have much improved on these past few years and for which I am grateful for all of the effort behind!) is how we make the developer use-case for those platforms better.
I did not expect everyone to love this; this is how we got into the mess we are in. A few people thinking it would be expedient to just do their own thing. But I have come to this after an enormous amount of thought and much discussion. I think sometimes people imagine that I just throw things over the wall to get a reaction. That is not the case.
I don't think anyone thinks you're doing this just to see what everyone else thinks. Especially since the feedback has been consistent and uniform disagreement. I also agree that what we're doing today isn't quite what I'd like to see. But that's because when the source of truth for the device tree is external to us, we are not consistent. And we didn't push hard enough earlier on to get bindings we need upstream. Or pushed back hard enough on ourselves to come up with a way to solve some of the problems without the bindings we added.
We need some way to put U-Boot properties in there, at least until things change upstream and within U-Boot. That envisages tooling that is clearly not going to be in place for the upcoming release.
For the test, how about I create a separate qemu build (which I have done, actually, qemu_arm_spl) and control the QEMU flags so we know it will boot. It is for CI so we can keep it in sync and deal with any breakages if people change things in QEMU (as above, this seems to be a theoretical problem).
Again, please take a deep breath and consider how much this actually affects TF-A, QEMU, etc. I'd argue not at all. We are talking about a build-time devicetree in the U-Boot tree. We are not talking about disabling OF_BOARD or removing that option.
The problem I still have here is that if the source of truth for the device tree on a platform is given to us at run time we must use it. That you've noted the QEMU tree has changed only a little bit isn't super re-assuring. And the Pi platforms show more cases where it's an active problem. And since we should be using the true device tree, not a just for reference tree, why have the copy in tree at all?
Hi François,
On Mon, 1 Nov 2021 at 11:33, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Le lun. 1 nov. 2021 à 17:58, Simon Glass sjg@chromium.org a écrit :
Hi Peter,
On Mon, 1 Nov 2021 at 04:48, Peter Maydell peter.maydell@linaro.org wrote:
On Tue, 26 Oct 2021 at 01:33, Simon Glass sjg@chromium.org wrote:
Add this file, generated from qemu, so there is a reference devicetree in the U-Boot tree.
Signed-off-by: Simon Glass sjg@chromium.org
Note that the dtb you get from QEMU is only guaranteed to work if:
- you run it on the exact same QEMU version you generated it with
- you pass QEMU the exact same command line arguments you used when you generated it
Yes, I certainly understand that. In general this is not safe, but in practice it works well enough for development and CI.
You recognize that you hijack a product directory with development hack facility. There is a test directory to keep things clear. There can be a dev-dts or something similar for Dev time tools. I have only seen push back on those fake dts files in the dts directory: I guess that unless someone strongly favors a continuation of the discussion, you may consider re-shaping the proposal to address concerns.
As stated previously, I would like to have at least a sample DT in-tree for all boards. I cannot see another way to get the Kconfig options in line. If we are able to put these files somewhere else in the future and get them out of U-Boot, with perhaps just an overlay for development purposes, I'd be keen to see it. But for now, this is where we are, I believe.
In this particular case, this is not just a dev hack. It is also for CI tests which need to use a devicetree. See for example here:
https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-s... https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-s...
I am able to use QEMU versions that differ by two years, partly because I am not trying to do anything clever.
I have sent a patch to add an indication of where the devicetree came from, to help with visibility on this.
Regards, Simon
On Tue, Nov 02, 2021 at 08:59:45AM -0600, Simon Glass wrote:
Hi François,
On Mon, 1 Nov 2021 at 11:33, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Le lun. 1 nov. 2021 à 17:58, Simon Glass sjg@chromium.org a écrit :
Hi Peter,
On Mon, 1 Nov 2021 at 04:48, Peter Maydell peter.maydell@linaro.org wrote:
On Tue, 26 Oct 2021 at 01:33, Simon Glass sjg@chromium.org wrote:
Add this file, generated from qemu, so there is a reference devicetree in the U-Boot tree.
Signed-off-by: Simon Glass sjg@chromium.org
Note that the dtb you get from QEMU is only guaranteed to work if:
- you run it on the exact same QEMU version you generated it with
- you pass QEMU the exact same command line arguments you used when you generated it
Yes, I certainly understand that. In general this is not safe, but in practice it works well enough for development and CI.
You recognize that you hijack a product directory with development hack facility. There is a test directory to keep things clear. There can be a dev-dts or something similar for Dev time tools. I have only seen push back on those fake dts files in the dts directory: I guess that unless someone strongly favors a continuation of the discussion, you may consider re-shaping the proposal to address concerns.
As stated previously, I would like to have at least a sample DT in-tree for all boards. I cannot see another way to get the Kconfig
What's the point of having a sample when it's not going to always be correct or may be actively wrong and we can tell interested developers / users how to get the correct DTB/DTS to examine?
options in line. If we are able to put these files somewhere else in the future and get them out of U-Boot, with perhaps just an overlay for development purposes, I'd be keen to see it. But for now, this is where we are, I believe.
In this particular case, this is not just a dev hack. It is also for CI tests which need to use a devicetree. See for example here:
https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-s... https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-s...
This example would probably be better done on vexpress_ca9x4 where we do test in CI via QEMU but do not need to modify a device tree that is passed on to us, we already control the source of truth DTB in this case.
And also yes, I'm behind on reviewing things I need to review.
Hi Tom,
On Tue, 2 Nov 2021 at 10:57, Tom Rini trini@konsulko.com wrote:
On Tue, Nov 02, 2021 at 08:59:45AM -0600, Simon Glass wrote:
Hi François,
On Mon, 1 Nov 2021 at 11:33, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Le lun. 1 nov. 2021 à 17:58, Simon Glass sjg@chromium.org a écrit :
Hi Peter,
On Mon, 1 Nov 2021 at 04:48, Peter Maydell peter.maydell@linaro.org wrote:
On Tue, 26 Oct 2021 at 01:33, Simon Glass sjg@chromium.org wrote:
Add this file, generated from qemu, so there is a reference devicetree in the U-Boot tree.
Signed-off-by: Simon Glass sjg@chromium.org
Note that the dtb you get from QEMU is only guaranteed to work if:
- you run it on the exact same QEMU version you generated it with
- you pass QEMU the exact same command line arguments you used when you generated it
Yes, I certainly understand that. In general this is not safe, but in practice it works well enough for development and CI.
You recognize that you hijack a product directory with development hack facility. There is a test directory to keep things clear. There can be a dev-dts or something similar for Dev time tools. I have only seen push back on those fake dts files in the dts directory: I guess that unless someone strongly favors a continuation of the discussion, you may consider re-shaping the proposal to address concerns.
As stated previously, I would like to have at least a sample DT in-tree for all boards. I cannot see another way to get the Kconfig
What's the point of having a sample when it's not going to always be correct or may be actively wrong and we can tell interested developers / users how to get the correct DTB/DTS to examine?
options in line. If we are able to put these files somewhere else in the future and get them out of U-Boot, with perhaps just an overlay for development purposes, I'd be keen to see it. But for now, this is where we are, I believe.
In this particular case, this is not just a dev hack. It is also for CI tests which need to use a devicetree. See for example here:
https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-s... https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-s...
This example would probably be better done on vexpress_ca9x4 where we do test in CI via QEMU but do not need to modify a device tree that is passed on to us, we already control the source of truth DTB in this case.
But that board:
- uses OF_EMBED, which it should not - does not use SPL, which I need
And also yes, I'm behind on reviewing things I need to review.
Aren't we all...I can't even keep up with these threads.
Regards, Simon
On Tue, Nov 02, 2021 at 07:32:54PM -0600, Simon Glass wrote:
Hi Tom,
On Tue, 2 Nov 2021 at 10:57, Tom Rini trini@konsulko.com wrote:
On Tue, Nov 02, 2021 at 08:59:45AM -0600, Simon Glass wrote:
Hi François,
On Mon, 1 Nov 2021 at 11:33, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Le lun. 1 nov. 2021 à 17:58, Simon Glass sjg@chromium.org a écrit :
Hi Peter,
On Mon, 1 Nov 2021 at 04:48, Peter Maydell peter.maydell@linaro.org wrote:
On Tue, 26 Oct 2021 at 01:33, Simon Glass sjg@chromium.org wrote: > > Add this file, generated from qemu, so there is a reference devicetree > in the U-Boot tree. > > Signed-off-by: Simon Glass sjg@chromium.org
Note that the dtb you get from QEMU is only guaranteed to work if:
- you run it on the exact same QEMU version you generated it with
- you pass QEMU the exact same command line arguments you used when you generated it
Yes, I certainly understand that. In general this is not safe, but in practice it works well enough for development and CI.
You recognize that you hijack a product directory with development hack facility. There is a test directory to keep things clear. There can be a dev-dts or something similar for Dev time tools. I have only seen push back on those fake dts files in the dts directory: I guess that unless someone strongly favors a continuation of the discussion, you may consider re-shaping the proposal to address concerns.
As stated previously, I would like to have at least a sample DT in-tree for all boards. I cannot see another way to get the Kconfig
What's the point of having a sample when it's not going to always be correct or may be actively wrong and we can tell interested developers / users how to get the correct DTB/DTS to examine?
options in line. If we are able to put these files somewhere else in the future and get them out of U-Boot, with perhaps just an overlay for development purposes, I'd be keen to see it. But for now, this is where we are, I believe.
In this particular case, this is not just a dev hack. It is also for CI tests which need to use a devicetree. See for example here:
https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-s... https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-s...
This example would probably be better done on vexpress_ca9x4 where we do test in CI via QEMU but do not need to modify a device tree that is passed on to us, we already control the source of truth DTB in this case.
But that board:
- uses OF_EMBED, which it should not
- does not use SPL, which I need
Check out the other hardware then that we emulate today, and or maybe something off of https://qemu.readthedocs.io/en/latest/system/target-arm.html that we could add. My point is that by picking the QEMU targets for where to test this feature you've gone with "I've introduced this feature so now I need to introduce this other change I've been arguing for too" in an artificial manner as it would only be used like that for testing.
Add these files, generated from qemu, so there is a reference devicetree in the U-Boot tree.
Split the existing qemu-virt into two, since we need a different devicetree for 32- and 64-bit machines.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
arch/riscv/dts/Makefile | 2 +- arch/riscv/dts/qemu-virt.dts | 8 - arch/riscv/dts/qemu-virt32.dts | 217 +++++++++++++++++++++++++++ arch/riscv/dts/qemu-virt64.dts | 217 +++++++++++++++++++++++++++ configs/qemu-riscv32_defconfig | 1 + configs/qemu-riscv32_smode_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 2 +- configs/qemu-riscv64_defconfig | 1 + configs/qemu-riscv64_smode_defconfig | 1 + configs/qemu-riscv64_spl_defconfig | 2 +- 10 files changed, 441 insertions(+), 11 deletions(-) delete mode 100644 arch/riscv/dts/qemu-virt.dts create mode 100644 arch/riscv/dts/qemu-virt32.dts create mode 100644 arch/riscv/dts/qemu-virt64.dts
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile index b6e9166767b..90d3f35e6e3 100644 --- a/arch/riscv/dts/Makefile +++ b/arch/riscv/dts/Makefile @@ -2,7 +2,7 @@
dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb -dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt.dtb +dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt32.dtb qemu-virt64.dtb dtb-$(CONFIG_TARGET_OPENPITON_RISCV64) += openpiton-riscv64.dtb dtb-$(CONFIG_TARGET_SIFIVE_UNLEASHED) += hifive-unleashed-a00.dtb dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-unmatched-a00.dtb diff --git a/arch/riscv/dts/qemu-virt.dts b/arch/riscv/dts/qemu-virt.dts deleted file mode 100644 index fecff542b91..00000000000 --- a/arch/riscv/dts/qemu-virt.dts +++ /dev/null @@ -1,8 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0+ -/* - * Copyright (C) 2021, Bin Meng bmeng.cn@gmail.com - */ - -/dts-v1/; - -#include "binman.dtsi" diff --git a/arch/riscv/dts/qemu-virt32.dts b/arch/riscv/dts/qemu-virt32.dts new file mode 100644 index 00000000000..3c449413523 --- /dev/null +++ b/arch/riscv/dts/qemu-virt32.dts @@ -0,0 +1,217 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2021, Bin Meng bmeng.cn@gmail.com + */ + +/dts-v1/; + +#include "binman.dtsi" + +/ { + #address-cells = <0x02>; + #size-cells = <0x02>; + compatible = "riscv-virtio"; + model = "riscv-virtio,qemu"; + + fw-cfg@10100000 { + dma-coherent; + reg = <0x00 0x10100000 0x00 0x18>; + compatible = "qemu,fw-cfg-mmio"; + }; + + flash@20000000 { + bank-width = <0x04>; + reg = <0x00 0x20000000 0x00 0x2000000 + 0x00 0x22000000 0x00 0x2000000>; + compatible = "cfi-flash"; + }; + + chosen { + bootargs = [00]; + stdout-path = "/soc/uart@10000000"; + }; + + memory@80000000 { + device_type = "memory"; + reg = <0x00 0x80000000 0x00 0x8000000>; + }; + + cpus { + #address-cells = <0x01>; + #size-cells = <0x00>; + timebase-frequency = <0x989680>; + + cpu@0 { + phandle = <0x01>; + device_type = "cpu"; + reg = <0x00>; + status = "okay"; + compatible = "riscv"; + riscv,isa = "rv32imafdcsu"; + mmu-type = "riscv,sv32"; + + interrupt-controller { + #interrupt-cells = <0x01>; + interrupt-controller; + compatible = "riscv,cpu-intc"; + phandle = <0x02>; + }; + }; + + cpu-map { + + cluster0 { + + core0 { + cpu = <0x01>; + }; + }; + }; + }; + + soc { + #address-cells = <0x02>; + #size-cells = <0x02>; + compatible = "simple-bus"; + ranges; + + rtc@101000 { + interrupts = <0x0b>; + interrupt-parent = <0x03>; + reg = <0x00 0x101000 0x00 0x1000>; + compatible = "google,goldfish-rtc"; + }; + + uart@10000000 { + interrupts = <0x0a>; + interrupt-parent = <0x03>; + clock-frequency = <0x384000>; + reg = <0x00 0x10000000 0x00 0x100>; + compatible = "ns16550a"; + }; + + poweroff { + value = <0x5555>; + offset = <0x00>; + regmap = <0x04>; + compatible = "syscon-poweroff"; + }; + + reboot { + value = <0x7777>; + offset = <0x00>; + regmap = <0x04>; + compatible = "syscon-reboot"; + }; + + test@100000 { + phandle = <0x04>; + reg = <0x00 0x100000 0x00 0x1000>; + compatible = "sifive,test1\0sifive,test0\0syscon"; + }; + + pci@30000000 { + interrupt-map-mask = <0x1800 0x00 0x00 0x07>; + interrupt-map = <0x00 0x00 0x00 0x01 0x03 0x20 0x00 0x00 + 0x00 0x02 0x03 0x21 0x00 0x00 0x00 0x03 + 0x03 0x22 0x00 0x00 0x00 0x04 0x03 0x23 + 0x800 0x00 0x00 0x01 0x03 0x21 0x800 0x00 + 0x00 0x02 0x03 0x22 0x800 0x00 0x00 0x03 + 0x03 0x23 0x800 0x00 0x00 0x04 0x03 0x20 + 0x1000 0x00 0x00 0x01 0x03 0x22 0x1000 0x00 + 0x00 0x02 0x03 0x23 0x1000 0x00 0x00 0x03 + 0x03 0x20 0x1000 0x00 0x00 0x04 0x03 0x21 + 0x1800 0x00 0x00 0x01 0x03 0x23 0x1800 0x00 + 0x00 0x02 0x03 0x20 0x1800 0x00 0x00 0x03 + 0x03 0x21 0x1800 0x00 0x00 0x04 0x03 0x22>; + ranges = <0x1000000 0x00 0x00 0x00 + 0x3000000 0x00 0x10000 0x2000000 + 0x00 0x40000000 0x00 0x40000000 + 0x00 0x40000000 0x3000000 0x03 + 0x00 0x03 0x00 0x01 + 0x00>; + reg = <0x00 0x30000000 0x00 0x10000000>; + dma-coherent; + bus-range = <0x00 0xff>; + linux,pci-domain = <0x00>; + device_type = "pci"; + compatible = "pci-host-ecam-generic"; + #size-cells = <0x02>; + #interrupt-cells = <0x01>; + #address-cells = <0x03>; + }; + + virtio_mmio@10008000 { + interrupts = <0x08>; + interrupt-parent = <0x03>; + reg = <0x00 0x10008000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@10007000 { + interrupts = <0x07>; + interrupt-parent = <0x03>; + reg = <0x00 0x10007000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@10006000 { + interrupts = <0x06>; + interrupt-parent = <0x03>; + reg = <0x00 0x10006000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@10005000 { + interrupts = <0x05>; + interrupt-parent = <0x03>; + reg = <0x00 0x10005000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@10004000 { + interrupts = <0x04>; + interrupt-parent = <0x03>; + reg = <0x00 0x10004000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@10003000 { + interrupts = <0x03>; + interrupt-parent = <0x03>; + reg = <0x00 0x10003000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@10002000 { + interrupts = <0x02>; + interrupt-parent = <0x03>; + reg = <0x00 0x10002000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@10001000 { + interrupts = <0x01>; + interrupt-parent = <0x03>; + reg = <0x00 0x10001000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + plic@c000000 { + phandle = <0x03>; + riscv,ndev = <0x35>; + reg = <0x00 0xc000000 0x00 0x210000>; + interrupts-extended = <0x02 0x0b 0x02 0x09>; + interrupt-controller; + compatible = "sifive,plic-1.0.0\0riscv,plic0"; + #interrupt-cells = <0x01>; + #address-cells = <0x00>; + }; + + clint@2000000 { + interrupts-extended = <0x02 0x03 0x02 0x07>; + reg = <0x00 0x2000000 0x00 0x10000>; + compatible = "sifive,clint0\0riscv,clint0"; + }; + }; +}; diff --git a/arch/riscv/dts/qemu-virt64.dts b/arch/riscv/dts/qemu-virt64.dts new file mode 100644 index 00000000000..61bc084e280 --- /dev/null +++ b/arch/riscv/dts/qemu-virt64.dts @@ -0,0 +1,217 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2021, Bin Meng bmeng.cn@gmail.com + */ + +/dts-v1/; + +#include "binman.dtsi" + +/ { + #address-cells = <0x02>; + #size-cells = <0x02>; + compatible = "riscv-virtio"; + model = "riscv-virtio,qemu"; + + fw-cfg@10100000 { + dma-coherent; + reg = <0x00 0x10100000 0x00 0x18>; + compatible = "qemu,fw-cfg-mmio"; + }; + + flash@20000000 { + bank-width = <0x04>; + reg = <0x00 0x20000000 0x00 0x2000000 + 0x00 0x22000000 0x00 0x2000000>; + compatible = "cfi-flash"; + }; + + chosen { + bootargs = [00]; + stdout-path = "/soc/uart@10000000"; + }; + + memory@80000000 { + device_type = "memory"; + reg = <0x00 0x80000000 0x00 0x8000000>; + }; + + cpus { + #address-cells = <0x01>; + #size-cells = <0x00>; + timebase-frequency = <0x989680>; + + cpu@0 { + phandle = <0x01>; + device_type = "cpu"; + reg = <0x00>; + status = "okay"; + compatible = "riscv"; + riscv,isa = "rv64imafdcsu"; + mmu-type = "riscv,sv48"; + + interrupt-controller { + #interrupt-cells = <0x01>; + interrupt-controller; + compatible = "riscv,cpu-intc"; + phandle = <0x02>; + }; + }; + + cpu-map { + + cluster0 { + + core0 { + cpu = <0x01>; + }; + }; + }; + }; + + soc { + #address-cells = <0x02>; + #size-cells = <0x02>; + compatible = "simple-bus"; + ranges; + + rtc@101000 { + interrupts = <0x0b>; + interrupt-parent = <0x03>; + reg = <0x00 0x101000 0x00 0x1000>; + compatible = "google,goldfish-rtc"; + }; + + uart@10000000 { + interrupts = <0x0a>; + interrupt-parent = <0x03>; + clock-frequency = <0x384000>; + reg = <0x00 0x10000000 0x00 0x100>; + compatible = "ns16550a"; + }; + + poweroff { + value = <0x5555>; + offset = <0x00>; + regmap = <0x04>; + compatible = "syscon-poweroff"; + }; + + reboot { + value = <0x7777>; + offset = <0x00>; + regmap = <0x04>; + compatible = "syscon-reboot"; + }; + + test@100000 { + phandle = <0x04>; + reg = <0x00 0x100000 0x00 0x1000>; + compatible = "sifive,test1\0sifive,test0\0syscon"; + }; + + pci@30000000 { + interrupt-map-mask = <0x1800 0x00 0x00 0x07>; + interrupt-map = <0x00 0x00 0x00 0x01 0x03 0x20 0x00 0x00 + 0x00 0x02 0x03 0x21 0x00 0x00 0x00 0x03 + 0x03 0x22 0x00 0x00 0x00 0x04 0x03 0x23 + 0x800 0x00 0x00 0x01 0x03 0x21 0x800 0x00 + 0x00 0x02 0x03 0x22 0x800 0x00 0x00 0x03 + 0x03 0x23 0x800 0x00 0x00 0x04 0x03 0x20 + 0x1000 0x00 0x00 0x01 0x03 0x22 0x1000 0x00 + 0x00 0x02 0x03 0x23 0x1000 0x00 0x00 0x03 + 0x03 0x20 0x1000 0x00 0x00 0x04 0x03 0x21 + 0x1800 0x00 0x00 0x01 0x03 0x23 0x1800 0x00 + 0x00 0x02 0x03 0x20 0x1800 0x00 0x00 0x03 + 0x03 0x21 0x1800 0x00 0x00 0x04 0x03 0x22>; + ranges = <0x1000000 0x00 0x00 0x00 + 0x3000000 0x00 0x10000 0x2000000 + 0x00 0x40000000 0x00 0x40000000 + 0x00 0x40000000 0x3000000 0x03 + 0x00 0x03 0x00 0x01 + 0x00>; + reg = <0x00 0x30000000 0x00 0x10000000>; + dma-coherent; + bus-range = <0x00 0xff>; + linux,pci-domain = <0x00>; + device_type = "pci"; + compatible = "pci-host-ecam-generic"; + #size-cells = <0x02>; + #interrupt-cells = <0x01>; + #address-cells = <0x03>; + }; + + virtio_mmio@10008000 { + interrupts = <0x08>; + interrupt-parent = <0x03>; + reg = <0x00 0x10008000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@10007000 { + interrupts = <0x07>; + interrupt-parent = <0x03>; + reg = <0x00 0x10007000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@10006000 { + interrupts = <0x06>; + interrupt-parent = <0x03>; + reg = <0x00 0x10006000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@10005000 { + interrupts = <0x05>; + interrupt-parent = <0x03>; + reg = <0x00 0x10005000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@10004000 { + interrupts = <0x04>; + interrupt-parent = <0x03>; + reg = <0x00 0x10004000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@10003000 { + interrupts = <0x03>; + interrupt-parent = <0x03>; + reg = <0x00 0x10003000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@10002000 { + interrupts = <0x02>; + interrupt-parent = <0x03>; + reg = <0x00 0x10002000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@10001000 { + interrupts = <0x01>; + interrupt-parent = <0x03>; + reg = <0x00 0x10001000 0x00 0x1000>; + compatible = "virtio,mmio"; + }; + + plic@c000000 { + phandle = <0x03>; + riscv,ndev = <0x35>; + reg = <0x00 0xc000000 0x00 0x210000>; + interrupts-extended = <0x02 0x0b 0x02 0x09>; + interrupt-controller; + compatible = "sifive,plic-1.0.0\0riscv,plic0"; + #interrupt-cells = <0x01>; + #address-cells = <0x00>; + }; + + clint@2000000 { + interrupts-extended = <0x02 0x03 0x02 0x07>; + reg = <0x00 0x2000000 0x00 0x10000>; + compatible = "sifive,clint0\0riscv,clint0"; + }; + }; +}; diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig index e77e3ed53a0..54953cd347b 100644 --- a/configs/qemu-riscv32_defconfig +++ b/configs/qemu-riscv32_defconfig @@ -2,6 +2,7 @@ CONFIG_RISCV=y CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x20000 CONFIG_SYS_MALLOC_LEN=0x800000 +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32" CONFIG_TARGET_QEMU_VIRT=y CONFIG_DISTRO_DEFAULTS=y CONFIG_SYS_LOAD_ADDR=0x80200000 diff --git a/configs/qemu-riscv32_smode_defconfig b/configs/qemu-riscv32_smode_defconfig index 03787416f10..21ee08a643e 100644 --- a/configs/qemu-riscv32_smode_defconfig +++ b/configs/qemu-riscv32_smode_defconfig @@ -2,6 +2,7 @@ CONFIG_RISCV=y CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x20000 CONFIG_SYS_MALLOC_LEN=0x800000 +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32" CONFIG_TARGET_QEMU_VIRT=y CONFIG_RISCV_SMODE=y CONFIG_DISTRO_DEFAULTS=y diff --git a/configs/qemu-riscv32_spl_defconfig b/configs/qemu-riscv32_spl_defconfig index b0e655be416..3909c9a15ad 100644 --- a/configs/qemu-riscv32_spl_defconfig +++ b/configs/qemu-riscv32_spl_defconfig @@ -2,7 +2,7 @@ CONFIG_RISCV=y CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x20000 CONFIG_SYS_MALLOC_LEN=0x800000 -CONFIG_DEFAULT_DEVICE_TREE="qemu-virt" +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32" CONFIG_SPL=y CONFIG_TARGET_QEMU_VIRT=y CONFIG_RISCV_SMODE=y diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig index 1f8dc2d2053..303ad2d5f39 100644 --- a/configs/qemu-riscv64_defconfig +++ b/configs/qemu-riscv64_defconfig @@ -2,6 +2,7 @@ CONFIG_RISCV=y CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x20000 CONFIG_SYS_MALLOC_LEN=0x800000 +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64" CONFIG_TARGET_QEMU_VIRT=y CONFIG_ARCH_RV64I=y CONFIG_DISTRO_DEFAULTS=y diff --git a/configs/qemu-riscv64_smode_defconfig b/configs/qemu-riscv64_smode_defconfig index bdcec1fdaba..62cdf91699f 100644 --- a/configs/qemu-riscv64_smode_defconfig +++ b/configs/qemu-riscv64_smode_defconfig @@ -2,6 +2,7 @@ CONFIG_RISCV=y CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x20000 CONFIG_SYS_MALLOC_LEN=0x800000 +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64" CONFIG_TARGET_QEMU_VIRT=y CONFIG_ARCH_RV64I=y CONFIG_RISCV_SMODE=y diff --git a/configs/qemu-riscv64_spl_defconfig b/configs/qemu-riscv64_spl_defconfig index 9745c1a586a..34d88da41b0 100644 --- a/configs/qemu-riscv64_spl_defconfig +++ b/configs/qemu-riscv64_spl_defconfig @@ -2,7 +2,7 @@ CONFIG_RISCV=y CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x20000 CONFIG_SYS_MALLOC_LEN=0x800000 -CONFIG_DEFAULT_DEVICE_TREE="qemu-virt" +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64" CONFIG_SPL=y CONFIG_TARGET_QEMU_VIRT=y CONFIG_ARCH_RV64I=y
Add this file, obtained from the Raspbian boot disk, so there is a reference devicetree in the U-Boot tree. The same one is used for 32- and 64-bit variants.
Note that U-Boot does not normally need this at runtime, since CONFIG_OF_BOARD is enabled. The previous firmware stage provides a devicetree at runtime.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
arch/arm/dts/Makefile | 3 +- arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++++++++ configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + 5 files changed, 1963 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index e70293bb849..f5a02bec4e1 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1068,7 +1068,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \ bcm2837-rpi-3-a-plus.dtb \ bcm2837-rpi-3-b.dtb \ bcm2837-rpi-3-b-plus.dtb \ - bcm2837-rpi-cm3-io3.dtb + bcm2837-rpi-cm3-io3.dtb \ + bcm2711-rpi-4-b.dtb
dtb-$(CONFIG_ARCH_BCM63158) += \ bcm963158.dtb diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts b/arch/arm/dts/bcm2711-rpi-4-b.dts new file mode 100644 index 00000000000..425e9fb91c4 --- /dev/null +++ b/arch/arm/dts/bcm2711-rpi-4-b.dts @@ -0,0 +1,1958 @@ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +/* + * Sample device tree for rpi_4 + + * Copyright 2021 Google LLC + */ + +/dts-v1/; + +/memreserve/ 0x0000000000000000 0x0000000000001000; +/ { + compatible = "raspberrypi,4-model-b\0brcm,bcm2838\0brcm,bcm2837"; + model = "Raspberry Pi 4 Model B"; + interrupt-parent = <0x01>; + #address-cells = <0x02>; + #size-cells = <0x01>; + + aliases { + serial0 = "/soc/serial@7e215040"; + serial1 = "/soc/serial@7e201000"; + audio = "/soc/audio"; + aux = "/soc/aux@7e215000"; + sound = "/soc/sound"; + soc = "/soc"; + dma = "/soc/dma@7e007000"; + watchdog = "/soc/watchdog@7e100000"; + random = "/soc/rng@7e104000"; + mailbox = "/soc/mailbox@7e00b880"; + gpio = "/soc/gpio@7e200000"; + uart0 = "/soc/serial@7e201000"; + sdhost = "/soc/mmc@7e202000"; + mmc0 = "/soc/emmc2@7e340000"; + i2s = "/soc/i2s@7e203000"; + spi0 = "/soc/spi@7e204000"; + i2c0 = "/soc/i2c@7e205000"; + uart1 = "/soc/serial@7e215040"; + spi1 = "/soc/spi@7e215080"; + spi2 = "/soc/spi@7e2150c0"; + mmc = "/soc/mmc@7e300000"; + mmc1 = "/soc/mmcnr@7e300000"; + i2c1 = "/soc/i2c@7e804000"; + i2c2 = "/soc/i2c@7e805000"; + usb = "/soc/usb@7e980000"; + leds = "/leds"; + fb = "/soc/fb"; + thermal = "/soc/thermal@7d5d2200"; + axiperf = "/soc/axiperf"; + mmc2 = "/soc/mmc@7e202000"; + ethernet0 = "/scb/genet@7d580000"; + }; + + chosen { + bootargs = "8250.nr_uarts=1 cma=64M"; + }; + + thermal-zones { + + cpu-thermal { + polling-delay-passive = <0x00>; + polling-delay = <0x3e8>; + thermal-sensors = <0x02>; + coefficients = <0xfffffe19 0x641b8>; + phandle = <0x2f>; + + cooling-maps { + }; + }; + }; + + soc { + compatible = "simple-bus"; + #address-cells = <0x01>; + #size-cells = <0x01>; + ranges = <0x7e000000 0x00 0xfe000000 0x1800000 + 0x7c000000 0x00 0xfc000000 0x2000000 + 0x40000000 0x00 0xff800000 0x800000>; + dma-ranges = <0xc0000000 0x00 0x00 0x3c000000>; + phandle = <0x30>; + + txp@7e004000 { + compatible = "brcm,bcm2835-txp"; + reg = <0x7e004000 0x20>; + interrupts = <0x00 0x4b 0x04>; + status = "disabled"; + phandle = <0x31>; + }; + + dma@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xb00>; + interrupts = <0x00 0x50 0x04 0x00 0x51 0x04 0x00 0x52 + 0x04 0x00 0x53 0x04 0x00 0x54 0x04 0x00 + 0x55 0x04 0x00 0x56 0x04 0x00 0x57 0x04 + 0x00 0x57 0x04 0x00 0x58 0x04 0x00 0x58 + 0x04>; + interrupt-names = "dma0\0dma1\0dma2\0dma3\0dma4\0dma5\0dma6\0dma7\0dma8\0dma9\0dma10"; + #dma-cells = <0x01>; + brcm,dma-channel-mask = <0x7ef5>; + phandle = <0x0a>; + }; + + watchdog@7e100000 { + compatible = "brcm,bcm2835-pm\0brcm,bcm2835-pm-wdt"; + #power-domain-cells = <0x01>; + #reset-cells = <0x01>; + reg = <0x7e100000 0x114 0x7e00a000 0x24 0x7ec11000 0x20>; + clocks = <0x03 0x15 0x03 0x1d 0x03 0x17 0x03 0x16>; + clock-names = "v3d\0peri_image\0h264\0isp"; + system-power-controller; + phandle = <0x1c>; + }; + + cprman@7e101000 { + compatible = "brcm,bcm2838-cprman"; + #clock-cells = <0x01>; + reg = <0x7e101000 0x2000>; + clocks = <0x04 0x05 0x00 0x05 0x01 0x05 0x02 0x06 + 0x00 0x06 0x01 0x06 0x02>; + firmware = <0x07>; + phandle = <0x03>; + }; + + rng@7e104000 { + compatible = "brcm,bcm2838-rng200"; + reg = <0x7e104000 0x10>; + interrupts = <0x00 0x7d 0x04>; + phandle = <0x26>; + }; + + mailbox@7e00b880 { + compatible = "brcm,bcm2835-mbox"; + reg = <0x7e00b880 0x40>; + interrupts = <0x00 0x21 0x04>; + #mbox-cells = <0x00>; + phandle = <0x1a>; + }; + + gpio: gpio@7e200000 { + compatible = "brcm,bcm2835-gpio"; + reg = <0x7e200000 0xb4>; + interrupts = <0x00 0x71 0x04 0x00 0x72 0x04>; + gpio-controller; + #gpio-cells = <0x02>; + interrupt-controller; + #interrupt-cells = <0x02>; + phandle = <0x0f>; + + dpi_gpio0 { + brcm,pins = <0x00 0x01 0x02 0x03 0x04 + 0x05 0x06 0x07 0x08 0x09 + 0x0a 0x0b 0x0c 0x0d 0x0e + 0x0f 0x10 0x11 0x12 0x13 + 0x14 0x15 0x16 0x17 0x18 + 0x19 0x1a 0x1b>; + brcm,function = <0x06>; + phandle = <0x32>; + }; + + emmc_gpio22 { + brcm,pins = <0x16 0x17 0x18 0x19 0x1a 0x1b>; + brcm,function = <0x07>; + phandle = <0x33>; + }; + + emmc_gpio34 { + brcm,pins = <0x22 0x23 0x24 0x25 0x26 0x27>; + brcm,function = <0x07>; + brcm,pull = <0x00 0x02 0x02 0x02 0x02 0x02>; + phandle = <0x34>; + }; + + emmc_gpio48 { + brcm,pins = <0x30 0x31 0x32 0x33 0x34 0x35>; + brcm,function = <0x07>; + phandle = <0x35>; + }; + + gpclk0_gpio4 { + brcm,pins = <0x04>; + brcm,function = <0x04>; + phandle = <0x36>; + }; + + gpclk1_gpio5 { + brcm,pins = <0x05>; + brcm,function = <0x04>; + phandle = <0x37>; + }; + + gpclk1_gpio42 { + brcm,pins = <0x2a>; + brcm,function = <0x04>; + phandle = <0x38>; + }; + + gpclk1_gpio44 { + brcm,pins = <0x2c>; + brcm,function = <0x04>; + phandle = <0x39>; + }; + + gpclk2_gpio6 { + brcm,pins = <0x06>; + brcm,function = <0x04>; + phandle = <0x3a>; + }; + + gpclk2_gpio43 { + brcm,pins = <0x2b>; + brcm,function = <0x04>; + brcm,pull = <0x00>; + phandle = <0x3b>; + }; + + i2c0_gpio0 { + brcm,pins = <0x00 0x01>; + brcm,function = <0x04>; + phandle = <0x3c>; + }; + + i2c0_gpio28 { + brcm,pins = <0x1c 0x1d>; + brcm,function = <0x04>; + phandle = <0x3d>; + }; + + i2c0_gpio44 { + brcm,pins = <0x2c 0x2d>; + brcm,function = <0x05>; + phandle = <0x3e>; + }; + + i2c1_gpio2 { + brcm,pins = <0x02 0x03>; + brcm,function = <0x04>; + phandle = <0x3f>; + }; + + i2c1_gpio44 { + brcm,pins = <0x2c 0x2d>; + brcm,function = <0x06>; + phandle = <0x40>; + }; + + jtag_gpio22 { + brcm,pins = <0x16 0x17 0x18 0x19 0x1a 0x1b>; + brcm,function = <0x03>; + phandle = <0x41>; + }; + + pcm_gpio18 { + brcm,pins = <0x12 0x13 0x14 0x15>; + brcm,function = <0x04>; + phandle = <0x42>; + }; + + pcm_gpio28 { + brcm,pins = <0x1c 0x1d 0x1e 0x1f>; + brcm,function = <0x06>; + phandle = <0x43>; + }; + + pwm0_gpio12 { + brcm,pins = <0x0c>; + brcm,function = <0x04>; + phandle = <0x44>; + }; + + pwm0_gpio18 { + brcm,pins = <0x12>; + brcm,function = <0x02>; + phandle = <0x45>; + }; + + pwm0_gpio40 { + brcm,pins = <0x28>; + brcm,function = <0x04>; + phandle = <0x46>; + }; + + pwm1_gpio13 { + brcm,pins = <0x0d>; + brcm,function = <0x04>; + phandle = <0x47>; + }; + + pwm1_gpio19 { + brcm,pins = <0x13>; + brcm,function = <0x02>; + phandle = <0x48>; + }; + + pwm1_gpio41 { + brcm,pins = <0x29>; + brcm,function = <0x04>; + phandle = <0x49>; + }; + + pwm1_gpio45 { + brcm,pins = <0x2d>; + brcm,function = <0x04>; + phandle = <0x4a>; + }; + + sdhost_gpio48 { + brcm,pins = <0x16 0x17 0x18 0x19 0x1a 0x1b>; + brcm,function = <0x04>; + phandle = <0x0b>; + }; + + spi0_gpio7 { + brcm,pins = <0x07 0x08 0x09 0x0a 0x0b>; + brcm,function = <0x04>; + phandle = <0x4b>; + }; + + spi0_gpio35 { + brcm,pins = <0x23 0x24 0x25 0x26 0x27>; + brcm,function = <0x04>; + phandle = <0x4c>; + }; + + spi1_gpio16 { + brcm,pins = <0x10 0x11 0x12 0x13 0x14 0x15>; + brcm,function = <0x03>; + phandle = <0x4d>; + }; + + spi2_gpio40 { + brcm,pins = <0x28 0x29 0x2a 0x2b 0x2c 0x2d>; + brcm,function = <0x03>; + phandle = <0x4e>; + }; + + uart0_gpio14: uart0_gpio14 { + brcm,pins = <0x0e 0x0f>; + brcm,function = <0x04>; + phandle = <0x4f>; + }; + + uart0: uart0_ctsrts_gpio16 { + brcm,pins = <0x10 0x11>; + brcm,function = <0x07>; + phandle = <0x50>; + }; + + uart0_ctsrts_gpio30 { + brcm,pins = <0x1e 0x1f>; + brcm,function = <0x07>; + brcm,pull = <0x02 0x00>; + phandle = <0x51>; + }; + + uart0_gpio32 { + brcm,pins = <0x20 0x21>; + brcm,function = <0x07>; + brcm,pull = <0x00 0x02>; + phandle = <0x52>; + }; + + uart0_gpio36 { + brcm,pins = <0x24 0x25>; + brcm,function = <0x06>; + phandle = <0x53>; + }; + + uart0_ctsrts_gpio38 { + brcm,pins = <0x26 0x27>; + brcm,function = <0x06>; + phandle = <0x54>; + }; + + uart1_gpio14: uart1_gpio14 { + brcm,pins = <0x0e 0x0f>; + brcm,function = <0x02>; + phandle = <0x55>; + }; + + uart1: uart1_ctsrts_gpio16 { + brcm,pins = <0x10 0x11>; + brcm,function = <0x02>; + phandle = <0x56>; + }; + + uart1_gpio32 { + brcm,pins = <0x20 0x21>; + brcm,function = <0x02>; + phandle = <0x57>; + }; + + uart1_ctsrts_gpio30 { + brcm,pins = <0x1e 0x1f>; + brcm,function = <0x02>; + phandle = <0x58>; + }; + + uart1_gpio40 { + brcm,pins = <0x28 0x29>; + brcm,function = <0x02>; + phandle = <0x59>; + }; + + uart1_ctsrts_gpio42 { + brcm,pins = <0x2a 0x2b>; + brcm,function = <0x02>; + phandle = <0x5a>; + }; + + gpclk0_gpio49 { + brcm,pins = <0x31>; + brcm,function = <0x05>; + brcm,pull = <0x00>; + phandle = <0x5b>; + }; + + gpclk1_gpio50 { + brcm,pins = <0x32>; + brcm,function = <0x05>; + brcm,pull = <0x00>; + phandle = <0x5c>; + }; + + gpclk2_gpio51 { + brcm,pins = <0x33>; + brcm,function = <0x05>; + brcm,pull = <0x00>; + phandle = <0x5d>; + }; + + i2c0_gpio46 { + brcm,pins = <0x2e 0x2f>; + brcm,function = <0x04>; + phandle = <0x5e>; + }; + + i2c1_gpio46 { + brcm,pins = <0x2e 0x2f>; + brcm,function = <0x05>; + phandle = <0x5f>; + }; + + i2c3_gpio2 { + brcm,pins = <0x02 0x03>; + brcm,function = <0x02>; + phandle = <0x60>; + }; + + i2c3_gpio4 { + brcm,pins = <0x04 0x05>; + brcm,function = <0x02>; + phandle = <0x61>; + }; + + i2c4_gpio6 { + brcm,pins = <0x06 0x07>; + brcm,function = <0x02>; + phandle = <0x62>; + }; + + i2c4_gpio8 { + brcm,pins = <0x08 0x09>; + brcm,function = <0x02>; + phandle = <0x63>; + }; + + i2c5_gpio10 { + brcm,pins = <0x0a 0x0b>; + brcm,function = <0x02>; + phandle = <0x64>; + }; + + i2c5_gpio12 { + brcm,pins = <0x0c 0x0d>; + brcm,function = <0x02>; + phandle = <0x65>; + }; + + i2c6_gpio0 { + brcm,pins = <0x00 0x01>; + brcm,function = <0x02>; + phandle = <0x66>; + }; + + i2c6_gpio22 { + brcm,pins = <0x16 0x17>; + brcm,function = <0x02>; + phandle = <0x67>; + }; + + i2c_slave_gpio8 { + brcm,pins = <0x08 0x09 0x0a 0x0b>; + brcm,function = <0x07>; + phandle = <0x68>; + }; + + jtag_gpio48 { + brcm,pins = <0x30 0x31 0x32 0x33 0x34 0x35>; + brcm,function = <0x03>; + phandle = <0x69>; + }; + + mii_gpio28 { + brcm,pins = <0x1c 0x1d 0x1e 0x1f>; + brcm,function = <0x03>; + phandle = <0x6a>; + }; + + mii_gpio36 { + brcm,pins = <0x24 0x25 0x26 0x27>; + brcm,function = <0x02>; + phandle = <0x6b>; + }; + + pcm_gpio50 { + brcm,pins = <0x32 0x33 0x34 0x35>; + brcm,function = <0x06>; + phandle = <0x6c>; + }; + + pwm0_gpio52 { + brcm,pins = <0x34>; + brcm,function = <0x05>; + brcm,pull = <0x00>; + phandle = <0x6d>; + }; + + pwm1_gpio53 { + brcm,pins = <0x35>; + brcm,function = <0x05>; + brcm,pull = <0x00>; + phandle = <0x6e>; + }; + + rgmii_gpio35 { + brcm,pins = <0x23 0x24>; + brcm,function = <0x03>; + phandle = <0x6f>; + }; + + rgmii_irq_gpio34 { + brcm,pins = <0x22>; + brcm,function = <0x02>; + phandle = <0x70>; + }; + + rgmii_irq_gpio39 { + brcm,pins = <0x27>; + brcm,function = <0x03>; + phandle = <0x71>; + }; + + rgmii_mdio_gpio28 { + brcm,pins = <0x1c 0x1d>; + brcm,function = <0x02>; + phandle = <0x72>; + }; + + rgmii_mdio_gpio37 { + brcm,pins = <0x25 0x26>; + brcm,function = <0x03>; + phandle = <0x73>; + }; + + spi0_gpio46 { + brcm,pins = <0x2e 0x2f 0x30 0x31>; + brcm,function = <0x06>; + phandle = <0x74>; + }; + + spi2_gpio46 { + brcm,pins = <0x2e 0x2f 0x30 0x31 0x32>; + brcm,function = <0x02>; + phandle = <0x75>; + }; + + spi3_gpio0 { + brcm,pins = <0x00 0x01 0x02 0x03>; + brcm,function = <0x07>; + phandle = <0x76>; + }; + + spi4_gpio4 { + brcm,pins = <0x04 0x05 0x06 0x07>; + brcm,function = <0x07>; + phandle = <0x77>; + }; + + spi5_gpio12 { + brcm,pins = <0x0c 0x0d 0x0e 0x0f>; + brcm,function = <0x07>; + phandle = <0x78>; + }; + + spi6_gpio18 { + brcm,pins = <0x12 0x13 0x14 0x15>; + brcm,function = <0x07>; + phandle = <0x79>; + }; + + uart2_gpio0 { + brcm,pins = <0x00 0x01>; + brcm,function = <0x03>; + brcm,pull = <0x00 0x02>; + phandle = <0x7a>; + }; + + uart2_ctsrts_gpio2 { + brcm,pins = <0x02 0x03>; + brcm,function = <0x03>; + brcm,pull = <0x02 0x00>; + phandle = <0x7b>; + }; + + uart3_gpio4 { + brcm,pins = <0x04 0x05>; + brcm,function = <0x03>; + brcm,pull = <0x00 0x02>; + phandle = <0x7c>; + }; + + uart3_ctsrts_gpio6 { + brcm,pins = <0x06 0x07>; + brcm,function = <0x03>; + brcm,pull = <0x02 0x00>; + phandle = <0x7d>; + }; + + uart4_gpio8 { + brcm,pins = <0x08 0x09>; + brcm,function = <0x03>; + brcm,pull = <0x00 0x02>; + phandle = <0x7e>; + }; + + uart4_ctsrts_gpio10 { + brcm,pins = <0x0a 0x0b>; + brcm,function = <0x03>; + brcm,pull = <0x02 0x00>; + phandle = <0x7f>; + }; + + uart5_gpio12 { + brcm,pins = <0x0c 0x0d>; + brcm,function = <0x03>; + brcm,pull = <0x00 0x02>; + phandle = <0x80>; + }; + + uart5_ctsrts_gpio14 { + brcm,pins = <0x0e 0x0f>; + brcm,function = <0x03>; + brcm,pull = <0x02 0x00>; + phandle = <0x81>; + }; + + dpi_18bit_gpio0 { + brcm,pins = <0x00 0x01 0x02 0x03 + 0x04 0x05 0x06 0x07 + 0x08 0x09 0x0a 0x0b + 0x0c 0x0d 0x0e 0x0f + 0x10 0x11 0x12 0x13 + 0x14 0x15>; + brcm,function = <0x06>; + phandle = <0x82>; + }; + + spi0_pins { + brcm,pins = <0x09 0x0a 0x0b>; + brcm,function = <0x04>; + phandle = <0x0d>; + }; + + spi0_cs_pins { + brcm,pins = <0x08 0x07>; + brcm,function = <0x01>; + phandle = <0x0e>; + }; + + spi3_pins { + brcm,pins = <0x01 0x02 0x03>; + brcm,function = <0x07>; + phandle = <0x83>; + }; + + spi3_cs_pins { + brcm,pins = <0x00 0x18>; + brcm,function = <0x01>; + phandle = <0x84>; + }; + + spi4_pins { + brcm,pins = <0x05 0x06 0x07>; + brcm,function = <0x07>; + phandle = <0x85>; + }; + + spi4_cs_pins { + brcm,pins = <0x04 0x19>; + brcm,function = <0x01>; + phandle = <0x86>; + }; + + spi5_pins { + brcm,pins = <0x0d 0x0e 0x0f>; + brcm,function = <0x07>; + phandle = <0x87>; + }; + + spi5_cs_pins { + brcm,pins = <0x0c 0x1a>; + brcm,function = <0x01>; + phandle = <0x88>; + }; + + spi6_pins { + brcm,pins = <0x13 0x14 0x15>; + brcm,function = <0x07>; + phandle = <0x89>; + }; + + spi6_cs_pins { + brcm,pins = <0x12 0x1b>; + brcm,function = <0x01>; + phandle = <0x8a>; + }; + + i2c0 { + brcm,pins = <0x00 0x01>; + brcm,function = <0x04>; + phandle = <0x10>; + }; + + i2c1 { + brcm,pins = <0x02 0x03>; + brcm,function = <0x04>; + phandle = <0x14>; + }; + + i2c3 { + brcm,pins = <0x04 0x05>; + brcm,function = <0x02>; + phandle = <0x8b>; + }; + + i2c4 { + brcm,pins = <0x08 0x09>; + brcm,function = <0x02>; + phandle = <0x8c>; + }; + + i2c5 { + brcm,pins = <0x0c 0x0d>; + brcm,function = <0x02>; + phandle = <0x8d>; + }; + + i2c6 { + brcm,pins = <0x16 0x17>; + brcm,function = <0x02>; + phandle = <0x8e>; + }; + + i2s { + brcm,pins = <0x12 0x13 0x14 0x15>; + brcm,function = <0x04>; + phandle = <0x0c>; + }; + + sdio_pins { + brcm,pins = <0x22 0x23 0x24 0x25 0x26 0x27>; + brcm,function = <0x07>; + brcm,pull = <0x00 0x02 0x02 0x02 0x02 0x02>; + phandle = <0x19>; + }; + + bt_pins { + brcm,pins = [2d 00]; + brcm,function = <0x00>; + brcm,pull = <0x02>; + phandle = <0x09>; + }; + + uart0_pins { + brcm,pins = <0x20 0x21>; + brcm,function = <0x07>; + brcm,pull = <0x00 0x02>; + phandle = <0x08>; + }; + + uart1_pins { + brcm,pins; + brcm,function; + brcm,pull; + phandle = <0x12>; + }; + + uart2_pins { + brcm,pins = <0x00 0x01>; + brcm,function = <0x03>; + brcm,pull = <0x00 0x02>; + phandle = <0x8f>; + }; + + uart3_pins { + brcm,pins = <0x04 0x05>; + brcm,function = <0x03>; + brcm,pull = <0x00 0x02>; + phandle = <0x90>; + }; + + uart4_pins { + brcm,pins = <0x08 0x09>; + brcm,function = <0x03>; + brcm,pull = <0x00 0x02>; + phandle = <0x91>; + }; + + uart5_pins { + brcm,pins = <0x0c 0x0d>; + brcm,function = <0x03>; + brcm,pull = <0x00 0x02>; + phandle = <0x92>; + }; + + audio_pins { + brcm,pins = <0x28 0x29>; + brcm,function = <0x04>; + phandle = <0x1b>; + }; + }; + + serial@7e201000 { + compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell"; + reg = <0x7e201000 0x200>; + interrupts = <0x00 0x79 0x04>; + clocks = <0x03 0x13 0x03 0x14>; + clock-names = "uartclk\0apb_pclk"; + arm,primecell-periphid = <0x241011>; + cts-event-workaround; + pinctrl-names = "default"; + pinctrl-0 = <0x08 0x09>; + status = "okay"; + phandle = <0x1f>; + }; + + mmc@7e202000 { + compatible = "brcm,bcm2835-sdhost"; + reg = <0x7e202000 0x100>; + interrupts = <0x00 0x78 0x04>; + clocks = <0x03 0x14>; + dmas = <0x0a 0x2000000d>; + dma-names = "rx-tx"; + status = "disabled"; + pinctrl-names = "default"; + pinctrl-0 = <0x0b>; + bus-width = <0x04>; + brcm,overclock-50 = <0x00>; + brcm,pio-limit = <0x01>; + phandle = <0x27>; + }; + + i2s@7e203000 { + compatible = "brcm,bcm2835-i2s"; + reg = <0x7e203000 0x24>; + clocks = <0x03 0x1f>; + dmas = <0x0a 0x02 0x0a 0x03>; + dma-names = "tx\0rx"; + status = "disabled"; + #sound-dai-cells = <0x00>; + pinctrl-names = "default"; + pinctrl-0 = <0x0c>; + phandle = <0x21>; + }; + + spi@7e204000 { + compatible = "brcm,bcm2835-spi"; + reg = <0x7e204000 0x200>; + interrupts = <0x00 0x76 0x04>; + clocks = <0x03 0x14>; + #address-cells = <0x01>; + #size-cells = <0x00>; + status = "disabled"; + dmas = <0x0a 0x06 0x0a 0x07>; + dma-names = "tx\0rx"; + pinctrl-names = "default"; + pinctrl-0 = <0x0d 0x0e>; + cs-gpios = <0x0f 0x08 0x01 0x0f 0x07 0x01>; + phandle = <0x22>; + + spidev@0 { + compatible = "spidev"; + reg = <0x00>; + #address-cells = <0x01>; + #size-cells = <0x00>; + spi-max-frequency = <0x7735940>; + phandle = <0x93>; + }; + + spidev@1 { + compatible = "spidev"; + reg = <0x01>; + #address-cells = <0x01>; + #size-cells = <0x00>; + spi-max-frequency = <0x7735940>; + phandle = <0x94>; + }; + }; + + i2c@7e205000 { + compatible = "brcm,bcm2835-i2c"; + reg = <0x7e205000 0x200>; + interrupts = <0x00 0x75 0x04>; + clocks = <0x03 0x14>; + #address-cells = <0x01>; + #size-cells = <0x00>; + status = "disabled"; + pinctrl-names = "default"; + pinctrl-0 = <0x10>; + clock-frequency = <0x186a0>; + phandle = <0x23>; + }; + + pixelvalve@7e206000 { + compatible = "brcm,bcm2835-pixelvalve0"; + reg = <0x7e206000 0x100>; + interrupts = <0x00 0x6d 0x04>; + status = "disabled"; + phandle = <0x95>; + }; + + pixelvalve@7e207000 { + compatible = "brcm,bcm2835-pixelvalve1"; + reg = <0x7e207000 0x100>; + interrupts = <0x00 0x6e 0x04>; + status = "disabled"; + phandle = <0x96>; + }; + + dpi@7e208000 { + compatible = "brcm,bcm2835-dpi"; + reg = <0x7e208000 0x8c>; + clocks = <0x03 0x14 0x03 0x2c>; + clock-names = "core\0pixel"; + #address-cells = <0x01>; + #size-cells = <0x00>; + status = "disabled"; + phandle = <0x97>; + }; + + dsi@7e209000 { + compatible = "brcm,bcm2835-dsi0"; + reg = <0x7e209000 0x78>; + interrupts = <0x00 0x64 0x04>; + #address-cells = <0x01>; + #size-cells = <0x00>; + #clock-cells = <0x01>; + clocks = <0x03 0x20 0x03 0x2f 0x03 0x31>; + clock-names = "phy\0escape\0pixel"; + clock-output-names = "dsi0_byte\0dsi0_ddr2\0dsi0_ddr"; + phandle = <0x05>; + }; + + aux@7e215000 { + compatible = "brcm,bcm2835-aux"; + #clock-cells = <0x01>; + reg = <0x7e215000 0x08>; + clocks = <0x03 0x14>; + phandle = <0x11>; + }; + + serial@7e215040 { + compatible = "brcm,bcm2835-aux-uart"; + reg = <0x7e215040 0x40>; + interrupts = <0x00 0x5d 0x04>; + clocks = <0x11 0x00>; + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <0x12>; + phandle = <0x20>; + }; + + spi@7e215080 { + compatible = "brcm,bcm2835-aux-spi"; + reg = <0x7e215080 0x40>; + interrupts = <0x00 0x5d 0x04>; + clocks = <0x11 0x01>; + #address-cells = <0x01>; + #size-cells = <0x00>; + status = "disabled"; + phandle = <0x98>; + }; + + spi@7e2150c0 { + compatible = "brcm,bcm2835-aux-spi"; + reg = <0x7e2150c0 0x40>; + interrupts = <0x00 0x5d 0x04>; + clocks = <0x11 0x02>; + #address-cells = <0x01>; + #size-cells = <0x00>; + status = "disabled"; + phandle = <0x99>; + }; + + pwm@7e20c000 { + compatible = "brcm,bcm2835-pwm"; + reg = <0x7e20c000 0x28>; + clocks = <0x03 0x1e>; + assigned-clocks = <0x03 0x1e>; + assigned-clock-rates = <0x989680>; + #pwm-cells = <0x02>; + status = "disabled"; + phandle = <0x9a>; + }; + + hvs@7e400000 { + compatible = "brcm,bcm2835-hvs"; + reg = <0x7e400000 0x6000>; + interrupts = <0x00 0x61 0x04>; + status = "disabled"; + phandle = <0x9b>; + }; + + dsi@7e700000 { + compatible = "brcm,bcm2835-dsi1"; + reg = <0x7e700000 0x8c>; + interrupts = <0x00 0x6c 0x04>; + #address-cells = <0x01>; + #size-cells = <0x00>; + #clock-cells = <0x01>; + clocks = <0x03 0x23 0x03 0x30 0x03 0x32>; + clock-names = "phy\0escape\0pixel"; + clock-output-names = "dsi1_byte\0dsi1_ddr2\0dsi1_ddr"; + status = "disabled"; + phandle = <0x06>; + }; + + csi@7e800000 { + compatible = "brcm,bcm2835-unicam"; + reg = <0x7e800000 0x800 0x7e802000 0x04>; + interrupts = <0x00 0x66 0x04>; + clocks = <0x03 0x2d>; + clock-names = "lp"; + #address-cells = <0x01>; + #size-cells = <0x00>; + #clock-cells = <0x01>; + status = "disabled"; + power-domains = <0x13 0x0c>; + phandle = <0x9c>; + }; + + csi@7e801000 { + compatible = "brcm,bcm2835-unicam"; + reg = <0x7e801000 0x800 0x7e802004 0x04>; + interrupts = <0x00 0x67 0x04>; + clocks = <0x03 0x2e>; + clock-names = "lp"; + #address-cells = <0x01>; + #size-cells = <0x00>; + #clock-cells = <0x01>; + status = "disabled"; + power-domains = <0x13 0x0d>; + phandle = <0x9d>; + + port { + + endpoint { + data-lanes = <0x01 0x02>; + }; + }; + }; + + i2c@7e804000 { + compatible = "brcm,bcm2835-i2c"; + reg = <0x7e804000 0x1000>; + interrupts = <0x00 0x75 0x04>; + clocks = <0x03 0x14>; + #address-cells = <0x01>; + #size-cells = <0x00>; + status = "disabled"; + pinctrl-names = "default"; + pinctrl-0 = <0x14>; + clock-frequency = <0x186a0>; + phandle = <0x24>; + }; + + i2c@7e805000 { + compatible = "brcm,bcm2835-i2c"; + reg = <0x7e805000 0x1000>; + interrupts = <0x00 0x75 0x04>; + clocks = <0x03 0x14>; + #address-cells = <0x01>; + #size-cells = <0x00>; + status = "disabled"; + clock-frequency = <0x186a0>; + phandle = <0x15>; + }; + + vec@7e806000 { + compatible = "brcm,bcm2835-vec"; + reg = <0x7e806000 0x1000>; + clocks = <0x03 0x18>; + interrupts = <0x00 0x7b 0x04>; + status = "disabled"; + phandle = <0x9e>; + }; + + pixelvalve@7e807000 { + compatible = "brcm,bcm2835-pixelvalve2"; + reg = <0x7e807000 0x100>; + interrupts = <0x00 0x6a 0x04>; + status = "disabled"; + phandle = <0x9f>; + }; + + hdmi@7e902000 { + compatible = "brcm,bcm2835-hdmi"; + reg = <0x7e902000 0x600 0x7e808000 0x100>; + interrupts = <0x00 0x68 0x04 0x00 0x69 0x04>; + ddc = <0x15>; + clocks = <0x03 0x10 0x03 0x19>; + clock-names = "pixel\0hdmi"; + dmas = <0x0a 0x11>; + dma-names = "audio-rx"; + status = "disabled"; + power-domains = <0x13 0x05>; + phandle = <0xa0>; + }; + + usb@7e980000 { + compatible = "brcm,bcm2708-usb"; + reg = <0x7e980000 0x10000 0x7e00b200 0x200>; + interrupts = <0x00 0x49 0x04 0x00 0x28 0x04>; + #address-cells = <0x01>; + #size-cells = <0x00>; + clocks = <0x16>; + clock-names = "otg"; + phys = <0x17>; + phy-names = "usb2-phy"; + interrupt-names = "usb\0soft"; + power-domains = <0x13 0x06>; + phandle = <0xa1>; + }; + + gpu { + compatible = "brcm,bcm2835-vc4"; + status = "disabled"; + phandle = <0xa2>; + }; + + local_intc@40000000 { + compatible = "brcm,bcm2836-l1-intc"; + reg = <0x40000000 0x100>; + phandle = <0xa3>; + }; + + gic400@40041000 { + interrupt-controller; + #interrupt-cells = <0x03>; + compatible = "arm,gic-400"; + reg = <0x40041000 0x1000 0x40042000 0x2000 0x40046000 0x2000 0x40048000 0x2000>; + phandle = <0x01>; + }; + + thermal@7d5d2200 { + compatible = "brcm,avs-tmon-bcm2838"; + reg = <0x7d5d2200 0x2c>; + interrupts = <0x00 0x89 0x04>; + interrupt-names = "tmon"; + clocks = <0x03 0x1b>; + #thermal-sensor-cells = <0x00>; + status = "okay"; + phandle = <0x02>; + }; + + serial@7e201400 { + compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell"; + reg = <0x7e201400 0x200>; + interrupts = <0x00 0x79 0x04>; + clocks = <0x03 0x13 0x03 0x14>; + clock-names = "uartclk\0apb_pclk"; + arm,primecell-periphid = <0x241011>; + status = "disabled"; + phandle = <0xa4>; + }; + + serial@7e201600 { + compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell"; + reg = <0x7e201600 0x200>; + interrupts = <0x00 0x79 0x04>; + clocks = <0x03 0x13 0x03 0x14>; + clock-names = "uartclk\0apb_pclk"; + arm,primecell-periphid = <0x241011>; + status = "disabled"; + phandle = <0xa5>; + }; + + serial@7e201800 { + compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell"; + reg = <0x7e201800 0x200>; + interrupts = <0x00 0x79 0x04>; + clocks = <0x03 0x13 0x03 0x14>; + clock-names = "uartclk\0apb_pclk"; + arm,primecell-periphid = <0x241011>; + status = "disabled"; + phandle = <0xa6>; + }; + + serial@7e201a00 { + compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell"; + reg = <0x7e201a00 0x200>; + interrupts = <0x00 0x79 0x04>; + clocks = <0x03 0x13 0x03 0x14>; + clock-names = "uartclk\0apb_pclk"; + arm,primecell-periphid = <0x241011>; + status = "disabled"; + phandle = <0xa7>; + }; + + spi@7e204600 { + compatible = "brcm,bcm2835-spi"; + reg = <0x7e204600 0x200>; + interrupts = <0x00 0x76 0x04>; + clocks = <0x03 0x14>; + #address-cells = <0x01>; + #size-cells = <0x00>; + status = "disabled"; + phandle = <0xa8>; + }; + + spi@7e204800 { + compatible = "brcm,bcm2835-spi"; + reg = <0x7e204800 0x200>; + interrupts = <0x00 0x76 0x04>; + clocks = <0x03 0x14>; + #address-cells = <0x01>; + #size-cells = <0x00>; + status = "disabled"; + phandle = <0xa9>; + }; + + spi@7e204a00 { + compatible = "brcm,bcm2835-spi"; + reg = <0x7e204a00 0x200>; + interrupts = <0x00 0x76 0x04>; + clocks = <0x03 0x14>; + #address-cells = <0x01>; + #size-cells = <0x00>; + status = "disabled"; + phandle = <0xaa>; + }; + + spi@7e204c00 { + compatible = "brcm,bcm2835-spi"; + reg = <0x7e204c00 0x200>; + interrupts = <0x00 0x76 0x04>; + clocks = <0x03 0x14>; + #address-cells = <0x01>; + #size-cells = <0x00>; + status = "disabled"; + phandle = <0xab>; + }; + + i2c@7e205600 { + compatible = "brcm,bcm2835-i2c"; + reg = <0x7e205600 0x200>; + interrupts = <0x00 0x75 0x04>; + clocks = <0x03 0x14>; + #address-cells = <0x01>; + #size-cells = <0x00>; + status = "disabled"; + phandle = <0xac>; + }; + + i2c@7e205800 { + compatible = "brcm,bcm2835-i2c"; + reg = <0x7e205800 0x200>; + interrupts = <0x00 0x75 0x04>; + clocks = <0x03 0x14>; + #address-cells = <0x01>; + #size-cells = <0x00>; + status = "disabled"; + phandle = <0xad>; + }; + + i2c@7e205a00 { + compatible = "brcm,bcm2835-i2c"; + reg = <0x7e205a00 0x200>; + interrupts = <0x00 0x75 0x04>; + clocks = <0x03 0x14>; + #address-cells = <0x01>; + #size-cells = <0x00>; + status = "disabled"; + phandle = <0xae>; + }; + + i2c@7e205c00 { + compatible = "brcm,bcm2835-i2c"; + reg = <0x7e205c00 0x200>; + interrupts = <0x00 0x75 0x04>; + clocks = <0x03 0x14>; + #address-cells = <0x01>; + #size-cells = <0x00>; + status = "disabled"; + phandle = <0xaf>; + }; + + emmc2@7e340000 { + compatible = "brcm,bcm2711-emmc2"; + status = "okay"; + interrupts = <0x00 0x7e 0x04>; + clocks = <0x03 0x33>; + reg = <0x7e340000 0x100>; + broken-cd; + vqmmc-supply = <0x18>; + phandle = <0xb0>; + }; + + mmc@7e300000 { + compatible = "brcm,bcm2835-mmc\0brcm,bcm2835-sdhci"; + reg = <0x7e300000 0x100>; + interrupts = <0x00 0x7e 0x04>; + clocks = <0x03 0x1c>; + dmas = <0x0a 0x0b>; + dma-names = "rx-tx"; + brcm,overclock-50 = <0x00>; + status = "disabled"; + phandle = <0x28>; + }; + + mmcnr@7e300000 { + compatible = "brcm,bcm2835-mmc\0brcm,bcm2835-sdhci"; + reg = <0x7e300000 0x100>; + interrupts = <0x00 0x7e 0x04>; + clocks = <0x03 0x1c>; + dmas = <0x0a 0x0b>; + dma-names = "rx-tx"; + brcm,overclock-50 = <0x00>; + non-removable; + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <0x19>; + bus-width = <0x04>; + phandle = <0x29>; + }; + + firmwarekms@7e600000 { + compatible = "raspberrypi,rpi-firmware-kms"; + reg = <0x7e600000 0x100>; + interrupts = <0x00 0x70 0x04>; + brcm,firmware = <0x07>; + status = "disabled"; + phandle = <0xb1>; + }; + + smi@7e600000 { + compatible = "brcm,bcm2835-smi"; + reg = <0x7e600000 0x100>; + interrupts = <0x00 0x70 0x04>; + clocks = <0x03 0x2a>; + assigned-clocks = <0x03 0x2a>; + assigned-clock-rates = <0x7735940>; + dmas = <0x0a 0x04>; + dma-names = "rx-tx"; + status = "disabled"; + phandle = <0xb2>; + }; + + axiperf { + compatible = "brcm,bcm2835-axiperf"; + reg = <0x7e009800 0x100 0x7ee08000 0x100>; + firmware = <0x07>; + status = "disabled"; + phandle = <0x2a>; + }; + + gpiomem { + compatible = "brcm,bcm2835-gpiomem"; + reg = <0x7e200000 0x1000>; + }; + + firmware { + compatible = "raspberrypi,bcm2835-firmware\0simple-bus"; + #address-cells = <0x00>; + #size-cells = <0x00>; + mboxes = <0x1a>; + phandle = <0x07>; + + expgpio { + compatible = "raspberrypi,firmware-gpio"; + gpio-controller; + #gpio-cells = <0x02>; + status = "okay"; + phandle = <0x2d>; + }; + }; + + power { + compatible = "raspberrypi,bcm2835-power"; + firmware = <0x07>; + #power-domain-cells = <0x01>; + phandle = <0x13>; + }; + + fb { + compatible = "brcm,bcm2708-fb"; + firmware = <0x07>; + status = "okay"; + phandle = <0xb3>; + }; + + vcsm { + compatible = "raspberrypi,bcm2835-vcsm"; + firmware = <0x07>; + status = "okay"; + phandle = <0xb4>; + }; + + audio { + compatible = "brcm,bcm2835-audio"; + brcm,pwm-channels = <0x08>; + status = "disabled"; + pinctrl-names = "default"; + pinctrl-0 = <0x1b>; + phandle = <0x25>; + }; + + sound { + status = "disabled"; + phandle = <0xb5>; + }; + + virtgpio { + compatible = "brcm,bcm2835-virtgpio"; + gpio-controller; + #gpio-cells = <0x02>; + firmware = <0x07>; + status = "okay"; + phandle = <0xb6>; + }; + }; + + clocks { + compatible = "simple-bus"; + #address-cells = <0x01>; + #size-cells = <0x00>; + + clock@3 { + compatible = "fixed-clock"; + reg = <0x03>; + #clock-cells = <0x00>; + clock-output-names = "osc"; + clock-frequency = <0x337f980>; + phandle = <0x04>; + }; + + clock@4 { + compatible = "fixed-clock"; + reg = <0x04>; + #clock-cells = <0x00>; + clock-output-names = "otg"; + clock-frequency = <0x1c9c3800>; + phandle = <0x16>; + }; + }; + + phy { + compatible = "usb-nop-xceiv"; + #phy-cells = <0x00>; + phandle = <0x17>; + }; + + arm-pmu { + compatible = "arm,cortex-a72-pmu\0arm,cortex-a53-pmu"; + interrupts = <0x00 0x10 0x04 0x00 0x11 0x04 0x00 0x12 0x04 0x00 0x13 0x04>; + }; + + timer { + compatible = "arm,armv7-timer"; + interrupts = <0x01 0x0d 0xf08 0x01 0x0e 0xf08 0x01 0x0b 0xf08 0x01 0x0a 0xf08>; + arm,cpu-registers-not-fw-configured; + always-on; + }; + + cpus { + #address-cells = <0x01>; + #size-cells = <0x00>; + enable-method = "brcm,bcm2836-smp"; + phandle = <0xb7>; + + cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a72"; + reg = <0x00>; + enable-method = "spin-table"; + cpu-release-addr = <0x00 0xd8>; + phandle = <0xb8>; + }; + + cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a72"; + reg = <0x01>; + enable-method = "spin-table"; + cpu-release-addr = <0x00 0xe0>; + phandle = <0xb9>; + }; + + cpu@2 { + device_type = "cpu"; + compatible = "arm,cortex-a72"; + reg = <0x02>; + enable-method = "spin-table"; + cpu-release-addr = <0x00 0xe8>; + phandle = <0xba>; + }; + + cpu@3 { + device_type = "cpu"; + compatible = "arm,cortex-a72"; + reg = <0x03>; + enable-method = "spin-table"; + cpu-release-addr = <0x00 0xf0>; + phandle = <0xbb>; + }; + }; + + v3dbus { + compatible = "simple-bus"; + #address-cells = <0x01>; + #size-cells = <0x01>; + ranges = <0x7c500000 0x00 0xfc500000 0x3300000 0x40000000 0x00 0xff800000 0x800000>; + dma-ranges = <0x00 0x00 0x00 0x3c000000>; + + v3d@7ec04000 { + compatible = "brcm,2711-v3d"; + reg = <0x7ec00000 0x4000 0x7ec04000 0x4000>; + reg-names = "hub\0core0"; + power-domains = <0x1c 0x01>; + resets = <0x1c 0x00>; + clocks = <0x03 0x15>; + interrupts = <0x00 0x4a 0x04>; + status = "okay"; + phandle = <0xbc>; + }; + }; + + scb { + compatible = "simple-bus"; + #address-cells = <0x02>; + #size-cells = <0x01>; + ranges = <0x00 0x7c000000 0x00 0xfc000000 + 0x3800000 0x00 0x40000000 0x00 + 0xff800000 0x800000 0x06 0x00 + 0x06 0x00 0x40000000 0x00 + 0x00 0x00 0x00 0xfc000000>; + dma-ranges = <0x00 0x00 0x00 0x00 0xfc000000>; + phandle = <0xbd>; + + pcie@7d500000 { + reg = <0x00 0x7d500000 0x9310 0x00 0x7e00f300 0x20>; + msi-controller; + msi-parent = <0x1d>; + #address-cells = <0x03>; + #interrupt-cells = <0x01>; + #size-cells = <0x02>; + bus-range = <0x00 0x01>; + compatible = "brcm,bcm7211-pcie\0brcm,bcm7445-pcie\0brcm,pci-plat-dev"; + max-link-speed = <0x02>; + tot-num-pcie = <0x01>; + linux,pci-domain = <0x00>; + interrupts = <0x00 0x94 0x04 0x00 0x94 0x04>; + interrupt-names = "pcie\0msi"; + interrupt-map-mask = <0x00 0x00 0x00 0x07>; + interrupt-map = <0x00 0x00 0x00 0x01 + 0x01 0x00 0x8f 0x04 0x00 0x00 0x00 0x02 + 0x01 0x00 0x90 0x04 0x00 0x00 0x00 0x03 + 0x01 0x00 0x91 0x04 0x00 0x00 0x00 0x04 + 0x01 0x00 0x92 0x04>; + ranges = <0x2000000 0x00 0xf8000000 0x06 0x00 0x00 0x4000000>; + dma-ranges = <0x2000000 0x00 0x00 0x00 0x00 0x01 0x00>; + status = "okay"; + phandle = <0x1d>; + }; + + genet@7d580000 { + compatible = "brcm,genet-v5"; + reg = <0x00 0x7d580000 0x10000>; + status = "okay"; + #address-cells = <0x01>; + #size-cells = <0x01>; + interrupts = <0x00 0x9d 0x04 0x00 0x9e 0x04>; + phy-handle = <0x1e>; + phy-mode = "rgmii"; + phandle = <0xbe>; + + mdio@e14 { + #address-cells = <0x00>; + #size-cells = <0x01>; + compatible = "brcm,genet-mdio-v5"; + reg = <0xe14 0x08>; + reg-names = "mdio"; + + genet-phy@0 { + compatible = "ethernet-phy-ieee802.3-c22"; + max-speed = <0x3e8>; + reg = <0x01>; + phandle = <0x1e>; + }; + }; + }; + + dma@7e007b00 { + compatible = "brcm,bcm2838-dma"; + reg = <0x00 0x7e007b00 0x400>; + interrupts = <0x00 0x59 0x04 0x00 0x5a 0x04 0x00 0x5b + 0x04 0x00 0x5c 0x04>; + interrupt-names = "dma11\0dma12\0dma13\0dma14"; + #dma-cells = <0x01>; + brcm,dma-channel-mask = <0x7000>; + phandle = <0xbf>; + }; + + xhci@7e9c0000 { + compatible = "generic-xhci"; + status = "disabled"; + reg = <0x00 0x7e9c0000 0x100000>; + interrupts = <0x00 0xb0 0x04>; + phandle = <0xc0>; + }; + + mailbox@7e00b840 { + compatible = "brcm,bcm2838-vchiq"; + reg = <0x00 0x7e00b840 0x3c>; + interrupts = <0x00 0x22 0x04>; + phandle = <0xc1>; + }; + + hevc-decoder@7eb00000 { + compatible = "raspberrypi,argon-hevc-decoder"; + reg = <0x00 0x7eb00000 0x10000>; + status = "okay"; + }; + + argon-local-intc@7eb10000 { + compatible = "raspberrypi,argon-local-intc"; + reg = <0x00 0x7eb10000 0x1000>; + status = "okay"; + interrupts = <0x00 0x62 0x04>; + }; + + h264-decoder@7eb20000 { + compatible = "raspberrypi,argon-h264-decoder"; + reg = <0x00 0x7eb20000 0x10000>; + status = "okay"; + }; + + vp9-decoder@7eb30000 { + compatible = "raspberrypi,argon-vp9-decoder"; + reg = <0x00 0x7eb30000 0x10000>; + status = "okay"; + }; + }; + + fixedregulator_5v0 { + compatible = "regulator-fixed"; + regulator-name = "5v0"; + regulator-min-microvolt = <0x4c4b40>; + regulator-max-microvolt = <0x4c4b40>; + regulator-always-on; + phandle = <0x2e>; + }; + + fixedregulator_3v3 { + compatible = "regulator-fixed"; + regulator-name = "3v3"; + regulator-min-microvolt = <0x325aa0>; + regulator-max-microvolt = <0x325aa0>; + regulator-always-on; + phandle = <0xc2>; + }; + + __overrides__ { + cam0-pwdn-ctrl; + cam0-pwdn; + cam0-led-ctrl; + cam0-led; + cache_line_size; + uart0 = [00 00 00 1f 73 74 61 74 75 73 00]; + uart1 = "\0\0\0 status"; + i2s = "\0\0\0!status"; + spi = "\0\0\0"status"; + i2c0 = "\0\0\0#status"; + i2c1 = "\0\0\0$status"; + i2c2_iknowwhatimdoing = [00 00 00 15 73 74 61 74 75 73 00]; + i2c0_baudrate = "\0\0\0#clock-frequency:0"; + i2c1_baudrate = "\0\0\0$clock-frequency:0"; + i2c2_baudrate = [00 00 00 15 63 6c 6f 63 + 6b 2d 66 72 65 71 75 65 + 6e 63 79 3a 30 00]; + audio = "\0\0\0%status"; + watchdog = [00 00 00 1c 73 74 61 74 75 73 00]; + random = "\0\0\0&status"; + sd_overclock = "\0\0\0'brcm,overclock-50:0"; + sd_force_pio = "\0\0\0'brcm,force-pio?"; + sd_pio_limit = "\0\0\0'brcm,pio-limit:0"; + sd_debug = "\0\0\0'brcm,debug"; + sdio_overclock = "\0\0\0(brcm,overclock-50:0\0\0\0\0)brcm,overclock-50:0"; + axiperf = "\0\0\0*status"; + arm_freq; + act_led_gpio = "\0\0\0+gpios:4"; + act_led_activelow = "\0\0\0+gpios:8"; + act_led_trigger = "\0\0\0+linux,default-trigger"; + pwr_led_gpio = "\0\0\0,gpios:4"; + pwr_led_activelow = "\0\0\0,gpios:8"; + pwr_led_trigger = "\0\0\0,linux,default-trigger"; + }; + + memory { + device_type = "memory"; + reg = <0x00 0x00 0x00>; + }; + + leds { + compatible = "gpio-leds"; + phandle = <0xc3>; + + act { + label = "led0"; + linux,default-trigger = "mmc0"; + gpios = <0x0f 0x2a 0x00>; + phandle = <0x2b>; + }; + + pwr { + label = "led1"; + linux,default-trigger = "input"; + gpios = <0x2d 0x02 0x00>; + phandle = <0x2c>; + }; + }; + + sd_io_1v8_reg { + status = "okay"; + compatible = "regulator-gpio"; + vin-supply = <0x2e>; + regulator-name = "vdd-sd-io"; + regulator-min-microvolt = <0x1b7740>; + regulator-max-microvolt = <0x325aa0>; + regulator-boot-on; + regulator-always-on; + regulator-settling-time-us = <0x1388>; + gpios = <0x2d 0x04 0x00>; + states = <0x1b7740 0x01 0x325aa0 0x00>; + phandle = <0x18>; + }; + + __symbols__ { + cpu_thermal = "/thermal-zones/cpu-thermal"; + soc = "/soc"; + txp = "/soc/txp@7e004000"; + dma = "/soc/dma@7e007000"; + watchdog = "/soc/watchdog@7e100000"; + pm = "/soc/watchdog@7e100000"; + clocks = "/soc/cprman@7e101000"; + random = "/soc/rng@7e104000"; + rng = "/soc/rng@7e104000"; + mailbox = "/soc/mailbox@7e00b880"; + gpio = "/soc/gpio@7e200000"; + dpi_gpio0 = "/soc/gpio@7e200000/dpi_gpio0"; + emmc_gpio22 = "/soc/gpio@7e200000/emmc_gpio22"; + emmc_gpio34 = "/soc/gpio@7e200000/emmc_gpio34"; + emmc_gpio48 = "/soc/gpio@7e200000/emmc_gpio48"; + gpclk0_gpio4 = "/soc/gpio@7e200000/gpclk0_gpio4"; + gpclk1_gpio5 = "/soc/gpio@7e200000/gpclk1_gpio5"; + gpclk1_gpio42 = "/soc/gpio@7e200000/gpclk1_gpio42"; + gpclk1_gpio44 = "/soc/gpio@7e200000/gpclk1_gpio44"; + gpclk2_gpio6 = "/soc/gpio@7e200000/gpclk2_gpio6"; + gpclk2_gpio43 = "/soc/gpio@7e200000/gpclk2_gpio43"; + i2c0_gpio0 = "/soc/gpio@7e200000/i2c0_gpio0"; + i2c0_gpio28 = "/soc/gpio@7e200000/i2c0_gpio28"; + i2c0_gpio44 = "/soc/gpio@7e200000/i2c0_gpio44"; + i2c1_gpio2 = "/soc/gpio@7e200000/i2c1_gpio2"; + i2c1_gpio44 = "/soc/gpio@7e200000/i2c1_gpio44"; + jtag_gpio22 = "/soc/gpio@7e200000/jtag_gpio22"; + pcm_gpio18 = "/soc/gpio@7e200000/pcm_gpio18"; + pcm_gpio28 = "/soc/gpio@7e200000/pcm_gpio28"; + pwm0_gpio12 = "/soc/gpio@7e200000/pwm0_gpio12"; + pwm0_gpio18 = "/soc/gpio@7e200000/pwm0_gpio18"; + pwm0_gpio40 = "/soc/gpio@7e200000/pwm0_gpio40"; + pwm1_gpio13 = "/soc/gpio@7e200000/pwm1_gpio13"; + pwm1_gpio19 = "/soc/gpio@7e200000/pwm1_gpio19"; + pwm1_gpio41 = "/soc/gpio@7e200000/pwm1_gpio41"; + pwm1_gpio45 = "/soc/gpio@7e200000/pwm1_gpio45"; + sdhost_pins = "/soc/gpio@7e200000/sdhost_gpio48"; + sdhost_gpio48 = "/soc/gpio@7e200000/sdhost_gpio48"; + spi0_gpio7 = "/soc/gpio@7e200000/spi0_gpio7"; + spi0_gpio35 = "/soc/gpio@7e200000/spi0_gpio35"; + spi1_gpio16 = "/soc/gpio@7e200000/spi1_gpio16"; + spi2_gpio40 = "/soc/gpio@7e200000/spi2_gpio40"; + uart0_gpio14 = "/soc/gpio@7e200000/uart0_gpio14"; + uart0_ctsrts_gpio16 = "/soc/gpio@7e200000/uart0_ctsrts_gpio16"; + uart0_ctsrts_gpio30 = "/soc/gpio@7e200000/uart0_ctsrts_gpio30"; + uart0_gpio32 = "/soc/gpio@7e200000/uart0_gpio32"; + uart0_gpio36 = "/soc/gpio@7e200000/uart0_gpio36"; + uart0_ctsrts_gpio38 = "/soc/gpio@7e200000/uart0_ctsrts_gpio38"; + uart1_gpio14 = "/soc/gpio@7e200000/uart1_gpio14"; + uart1_ctsrts_gpio16 = "/soc/gpio@7e200000/uart1_ctsrts_gpio16"; + uart1_gpio32 = "/soc/gpio@7e200000/uart1_gpio32"; + uart1_ctsrts_gpio30 = "/soc/gpio@7e200000/uart1_ctsrts_gpio30"; + uart1_gpio40 = "/soc/gpio@7e200000/uart1_gpio40"; + uart1_ctsrts_gpio42 = "/soc/gpio@7e200000/uart1_ctsrts_gpio42"; + gpclk0_gpio49 = "/soc/gpio@7e200000/gpclk0_gpio49"; + gpclk1_gpio50 = "/soc/gpio@7e200000/gpclk1_gpio50"; + gpclk2_gpio51 = "/soc/gpio@7e200000/gpclk2_gpio51"; + i2c0_gpio46 = "/soc/gpio@7e200000/i2c0_gpio46"; + i2c1_gpio46 = "/soc/gpio@7e200000/i2c1_gpio46"; + i2c3_gpio2 = "/soc/gpio@7e200000/i2c3_gpio2"; + i2c3_gpio4 = "/soc/gpio@7e200000/i2c3_gpio4"; + i2c4_gpio6 = "/soc/gpio@7e200000/i2c4_gpio6"; + i2c4_gpio8 = "/soc/gpio@7e200000/i2c4_gpio8"; + i2c5_gpio10 = "/soc/gpio@7e200000/i2c5_gpio10"; + i2c5_gpio12 = "/soc/gpio@7e200000/i2c5_gpio12"; + i2c6_gpio0 = "/soc/gpio@7e200000/i2c6_gpio0"; + i2c6_gpio22 = "/soc/gpio@7e200000/i2c6_gpio22"; + i2c_slave_gpio8 = "/soc/gpio@7e200000/i2c_slave_gpio8"; + jtag_gpio48 = "/soc/gpio@7e200000/jtag_gpio48"; + mii_gpio28 = "/soc/gpio@7e200000/mii_gpio28"; + mii_gpio36 = "/soc/gpio@7e200000/mii_gpio36"; + pcm_gpio50 = "/soc/gpio@7e200000/pcm_gpio50"; + pwm0_gpio52 = "/soc/gpio@7e200000/pwm0_gpio52"; + pwm1_gpio53 = "/soc/gpio@7e200000/pwm1_gpio53"; + rgmii_gpio35 = "/soc/gpio@7e200000/rgmii_gpio35"; + rgmii_irq_gpio34 = "/soc/gpio@7e200000/rgmii_irq_gpio34"; + rgmii_irq_gpio39 = "/soc/gpio@7e200000/rgmii_irq_gpio39"; + rgmii_mdio_gpio28 = "/soc/gpio@7e200000/rgmii_mdio_gpio28"; + rgmii_mdio_gpio37 = "/soc/gpio@7e200000/rgmii_mdio_gpio37"; + spi0_gpio46 = "/soc/gpio@7e200000/spi0_gpio46"; + spi2_gpio46 = "/soc/gpio@7e200000/spi2_gpio46"; + spi3_gpio0 = "/soc/gpio@7e200000/spi3_gpio0"; + spi4_gpio4 = "/soc/gpio@7e200000/spi4_gpio4"; + spi5_gpio12 = "/soc/gpio@7e200000/spi5_gpio12"; + spi6_gpio18 = "/soc/gpio@7e200000/spi6_gpio18"; + uart2_gpio0 = "/soc/gpio@7e200000/uart2_gpio0"; + uart2_ctsrts_gpio2 = "/soc/gpio@7e200000/uart2_ctsrts_gpio2"; + uart3_gpio4 = "/soc/gpio@7e200000/uart3_gpio4"; + uart3_ctsrts_gpio6 = "/soc/gpio@7e200000/uart3_ctsrts_gpio6"; + uart4_gpio8 = "/soc/gpio@7e200000/uart4_gpio8"; + uart4_ctsrts_gpio10 = "/soc/gpio@7e200000/uart4_ctsrts_gpio10"; + uart5_gpio12 = "/soc/gpio@7e200000/uart5_gpio12"; + uart5_ctsrts_gpio14 = "/soc/gpio@7e200000/uart5_ctsrts_gpio14"; + dpi_18bit_gpio0 = "/soc/gpio@7e200000/dpi_18bit_gpio0"; + spi0_pins = "/soc/gpio@7e200000/spi0_pins"; + spi0_cs_pins = "/soc/gpio@7e200000/spi0_cs_pins"; + spi3_pins = "/soc/gpio@7e200000/spi3_pins"; + spi3_cs_pins = "/soc/gpio@7e200000/spi3_cs_pins"; + spi4_pins = "/soc/gpio@7e200000/spi4_pins"; + spi4_cs_pins = "/soc/gpio@7e200000/spi4_cs_pins"; + spi5_pins = "/soc/gpio@7e200000/spi5_pins"; + spi5_cs_pins = "/soc/gpio@7e200000/spi5_cs_pins"; + spi6_pins = "/soc/gpio@7e200000/spi6_pins"; + spi6_cs_pins = "/soc/gpio@7e200000/spi6_cs_pins"; + i2c0_pins = "/soc/gpio@7e200000/i2c0"; + i2c1_pins = "/soc/gpio@7e200000/i2c1"; + i2c3_pins = "/soc/gpio@7e200000/i2c3"; + i2c4_pins = "/soc/gpio@7e200000/i2c4"; + i2c5_pins = "/soc/gpio@7e200000/i2c5"; + i2c6_pins = "/soc/gpio@7e200000/i2c6"; + i2s_pins = "/soc/gpio@7e200000/i2s"; + sdio_pins = "/soc/gpio@7e200000/sdio_pins"; + bt_pins = "/soc/gpio@7e200000/bt_pins"; + uart0_pins = "/soc/gpio@7e200000/uart0_pins"; + uart1_pins = "/soc/gpio@7e200000/uart1_pins"; + uart2_pins = "/soc/gpio@7e200000/uart2_pins"; + uart3_pins = "/soc/gpio@7e200000/uart3_pins"; + uart4_pins = "/soc/gpio@7e200000/uart4_pins"; + uart5_pins = "/soc/gpio@7e200000/uart5_pins"; + audio_pins = "/soc/gpio@7e200000/audio_pins"; + uart0 = "/soc/serial@7e201000"; + sdhost = "/soc/mmc@7e202000"; + i2s = "/soc/i2s@7e203000"; + spi0 = "/soc/spi@7e204000"; + spi = "/soc/spi@7e204000"; + spidev0 = "/soc/spi@7e204000/spidev@0"; + spidev1 = "/soc/spi@7e204000/spidev@1"; + i2c0 = "/soc/i2c@7e205000"; + pixelvalve0 = "/soc/pixelvalve@7e206000"; + pixelvalve1 = "/soc/pixelvalve@7e207000"; + dpi = "/soc/dpi@7e208000"; + dsi0 = "/soc/dsi@7e209000"; + aux = "/soc/aux@7e215000"; + uart1 = "/soc/serial@7e215040"; + spi1 = "/soc/spi@7e215080"; + spi2 = "/soc/spi@7e2150c0"; + pwm = "/soc/pwm@7e20c000"; + hvs = "/soc/hvs@7e400000"; + dsi1 = "/soc/dsi@7e700000"; + csi0 = "/soc/csi@7e800000"; + csi1 = "/soc/csi@7e801000"; + i2c1 = "/soc/i2c@7e804000"; + i2c2 = "/soc/i2c@7e805000"; + vec = "/soc/vec@7e806000"; + pixelvalve2 = "/soc/pixelvalve@7e807000"; + hdmi = "/soc/hdmi@7e902000"; + usb = "/soc/usb@7e980000"; + vc4 = "/soc/gpu"; + local_intc = "/soc/local_intc@40000000"; + gicv2 = "/soc/gic400@40041000"; + thermal = "/soc/thermal@7d5d2200"; + uart2 = "/soc/serial@7e201400"; + uart3 = "/soc/serial@7e201600"; + uart4 = "/soc/serial@7e201800"; + uart5 = "/soc/serial@7e201a00"; + spi3 = "/soc/spi@7e204600"; + spi4 = "/soc/spi@7e204800"; + spi5 = "/soc/spi@7e204a00"; + spi6 = "/soc/spi@7e204c00"; + i2c3 = "/soc/i2c@7e205600"; + i2c4 = "/soc/i2c@7e205800"; + i2c5 = "/soc/i2c@7e205a00"; + i2c6 = "/soc/i2c@7e205c00"; + emmc2 = "/soc/emmc2@7e340000"; + mmc = "/soc/mmc@7e300000"; + mmcnr = "/soc/mmcnr@7e300000"; + firmwarekms = "/soc/firmwarekms@7e600000"; + smi = "/soc/smi@7e600000"; + axiperf = "/soc/axiperf"; + firmware = "/soc/firmware"; + expgpio = "/soc/firmware/expgpio"; + power = "/soc/power"; + fb = "/soc/fb"; + vcsm = "/soc/vcsm"; + audio = "/soc/audio"; + sound = "/soc/sound"; + virtgpio = "/soc/virtgpio"; + clk_osc = "/clocks/clock@3"; + clk_usb = "/clocks/clock@4"; + usbphy = "/phy"; + cpus = "/cpus"; + cpu0 = "/cpus/cpu@0"; + cpu1 = "/cpus/cpu@1"; + cpu2 = "/cpus/cpu@2"; + cpu3 = "/cpus/cpu@3"; + v3d = "/v3dbus/v3d@7ec04000"; + scb = "/scb"; + pcie_0 = "/scb/pcie@7d500000"; + genet = "/scb/genet@7d580000"; + phy1 = "/scb/genet@7d580000/mdio@e14/genet-phy@0"; + dma40 = "/scb/dma@7e007b00"; + xhci = "/scb/xhci@7e9c0000"; + vchiq = "/scb/mailbox@7e00b840"; + vdd_5v0_reg = "/fixedregulator_5v0"; + vdd_3v3_reg = "/fixedregulator_3v3"; + leds = "/leds"; + act_led = "/leds/act"; + pwr_led = "/leds/pwr"; + sd_io_1v8_reg = "/sd_io_1v8_reg"; + }; +}; diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig index d592df50706..31d77dbe4eb 100644 --- a/configs/rpi_4_32b_defconfig +++ b/configs/rpi_4_32b_defconfig @@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x00008000 CONFIG_TARGET_RPI_4_32B=y CONFIG_SYS_MALLOC_F_LEN=0x2000 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 ab5cc90d912..a2a88d66dbd 100644 --- a/configs/rpi_4_defconfig +++ b/configs/rpi_4_defconfig @@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x00080000 CONFIG_TARGET_RPI_4=y CONFIG_SYS_MALLOC_F_LEN=0x2000 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 382d99dc2eb..fb8abbccc45 100644 --- a/configs/rpi_arm64_defconfig +++ b/configs/rpi_arm64_defconfig @@ -6,6 +6,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x2000 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;"
Add this file, obtained from the Linaro website[1], so there is a reference file in the U-Boot tree.
Note that U-Boot does not normally need this at runtime, since CONFIG_OF_BOARD is enabled. The previous firmware stage provides a devicetree at runtime.
[1] https://releases.linaro.org/android/reference-lcr/juno/7.1-17.05/
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
arch/arm/dts/Makefile | 3 + arch/arm/dts/juno-r2.dts | 1038 ++++++++++++++++++++++++ configs/vexpress_aemv8a_juno_defconfig | 1 + 3 files changed, 1042 insertions(+) create mode 100644 arch/arm/dts/juno-r2.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index f5a02bec4e1..0be50ecd9c8 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1140,7 +1140,10 @@ dtb-$(CONFIG_TARGET_GE_BX50V3) += \ dtb-$(CONFIG_TARGET_GE_B1X5V2) += imx6dl-b1x5v2.dtb dtb-$(CONFIG_TARGET_MX53PPD) += imx53-ppd.dtb
+# TODO(Linus Walleij linus.walleij@linaro.org): Should us a single vexpress +# Kconfig option to build all of these. See examples above. dtb-$(CONFIG_TARGET_VEXPRESS_CA9X4) += vexpress-v2p-ca9.dtb +dtb-$(CONFIG_TARGET_VEXPRESS64_JUNO) += juno-r2.dtb
dtb-$(CONFIG_TARGET_TOTAL_COMPUTE) += total_compute.dtb
diff --git a/arch/arm/dts/juno-r2.dts b/arch/arm/dts/juno-r2.dts new file mode 100644 index 00000000000..5a536d8100e --- /dev/null +++ b/arch/arm/dts/juno-r2.dts @@ -0,0 +1,1038 @@ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +/* + * Sample device tree for juno + + * Copyright 2021 Google LLC + */ + +/dts-v1/; + +/ { + model = "ARM Juno development board (r2)"; + compatible = "arm,juno-r2\0arm,juno"; + interrupt-parent = <0x01>; + #address-cells = <0x02>; + #size-cells = <0x02>; + + aliases { + serial0 = "/uart@7ff80000"; + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; + + psci { + compatible = "arm,psci-0.2"; + method = "smc"; + }; + + cpus { + #address-cells = <0x02>; + #size-cells = <0x00>; + + cpu-map { + + cluster0 { + + core0 { + cpu = <0x02>; + }; + + core1 { + cpu = <0x03>; + }; + }; + + cluster1 { + + core0 { + cpu = <0x04>; + }; + + core1 { + cpu = <0x05>; + }; + + core2 { + cpu = <0x06>; + }; + + core3 { + cpu = <0x07>; + }; + }; + }; + + idle-states { + entry-method = "arm,psci"; + + cpu-sleep-0 { + compatible = "arm,idle-state"; + arm,psci-suspend-param = <0x10000>; + local-timer-stop; + entry-latency-us = <0x12c>; + exit-latency-us = <0x4b0>; + min-residency-us = <0x7d0>; + linux,phandle = <0x0a>; + phandle = <0x0a>; + }; + + cluster-sleep-0 { + compatible = "arm,idle-state"; + arm,psci-suspend-param = <0x1010000>; + local-timer-stop; + entry-latency-us = <0x190>; + exit-latency-us = <0x4b0>; + min-residency-us = <0x9c4>; + linux,phandle = <0x0b>; + phandle = <0x0b>; + }; + }; + + cpu@0 { + compatible = "arm,cortex-a72\0arm,armv8"; + reg = <0x00 0x00>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <0x08>; + clocks = <0x09 0x00>; + cpu-idle-states = <0x0a 0x0b>; + sched-energy-costs = <0x0c 0x0d>; + #cooling-cells = <0x02>; + dynamic-power-coefficient = <0x1c2>; + linux,phandle = <0x02>; + phandle = <0x02>; + }; + + cpu@1 { + compatible = "arm,cortex-a72\0arm,armv8"; + reg = <0x00 0x01>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <0x08>; + clocks = <0x09 0x00>; + cpu-idle-states = <0x0a 0x0b>; + sched-energy-costs = <0x0c 0x0d>; + #cooling-cells = <0x02>; + dynamic-power-coefficient = <0x1c2>; + linux,phandle = <0x03>; + phandle = <0x03>; + }; + + cpu@100 { + compatible = "arm,cortex-a53\0arm,armv8"; + reg = <0x00 0x100>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <0x0e>; + clocks = <0x09 0x01>; + cpu-idle-states = <0x0a 0x0b>; + sched-energy-costs = <0x0f 0x10>; + #cooling-cells = <0x02>; + dynamic-power-coefficient = <0x8c>; + linux,phandle = <0x04>; + phandle = <0x04>; + }; + + cpu@101 { + compatible = "arm,cortex-a53\0arm,armv8"; + reg = <0x00 0x101>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <0x0e>; + clocks = <0x09 0x01>; + cpu-idle-states = <0x0a 0x0b>; + sched-energy-costs = <0x0f 0x10>; + #cooling-cells = <0x02>; + dynamic-power-coefficient = <0x8c>; + linux,phandle = <0x05>; + phandle = <0x05>; + }; + + cpu@102 { + compatible = "arm,cortex-a53\0arm,armv8"; + reg = <0x00 0x102>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <0x0e>; + clocks = <0x09 0x01>; + cpu-idle-states = <0x0a 0x0b>; + sched-energy-costs = <0x0f 0x10>; + #cooling-cells = <0x02>; + dynamic-power-coefficient = <0x8c>; + linux,phandle = <0x06>; + phandle = <0x06>; + }; + + cpu@103 { + compatible = "arm,cortex-a53\0arm,armv8"; + reg = <0x00 0x103>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <0x0e>; + clocks = <0x09 0x01>; + cpu-idle-states = <0x0a 0x0b>; + sched-energy-costs = <0x0f 0x10>; + #cooling-cells = <0x02>; + dynamic-power-coefficient = <0x8c>; + linux,phandle = <0x07>; + phandle = <0x07>; + }; + + l2-cache0 { + compatible = "cache"; + linux,phandle = <0x08>; + phandle = <0x08>; + }; + + l2-cache1 { + compatible = "cache"; + linux,phandle = <0x0e>; + phandle = <0x0e>; + }; + + energy-costs { + + core-cost0 { + busy-cost-data = <0x1f5 0xae 0x351 0x158 0x3ff 0x20e>; + idle-cost-data = <0x30 0x30 0x00 0x00>; + linux,phandle = <0x0c>; + phandle = <0x0c>; + }; + + core-cost1 { + busy-cost-data = <0x114 0x25 0x1f5 0x3b 0x251 0x75>; + idle-cost-data = <0x21 0x21 0x00 0x00>; + linux,phandle = <0x0f>; + phandle = <0x0f>; + }; + + cluster-cost0 { + busy-cost-data = <0x1f5 0x30 0x351 0x49 0x400 0x6b>; + idle-cost-data = <0x30 0x30 0x30 0x12>; + linux,phandle = <0x0d>; + phandle = <0x0d>; + }; + + cluster-cost1 { + busy-cost-data = <0x114 0x29 0x1f5 0x56 0x251 0x6b>; + idle-cost-data = <0x29 0x29 0x29 0x0e>; + linux,phandle = <0x10>; + phandle = <0x10>; + }; + }; + }; + + pmu_a72 { + compatible = "arm,cortex-a72-pmu"; + interrupts = <0x00 0x02 0x04 0x00 0x06 0x04>; + interrupt-affinity = <0x02 0x03>; + }; + + pmu_a53 { + compatible = "arm,cortex-a53-pmu"; + interrupts = <0x00 0x12 0x04 0x00 0x16 0x04 0x00 0x1a 0x04 0x00 0x1e 0x04>; + interrupt-affinity = <0x04 0x05 0x06 0x07>; + }; + + timer@2a810000 { + compatible = "arm,armv7-timer-mem"; + reg = <0x00 0x2a810000 0x00 0x10000>; + clock-frequency = <0x2faf080>; + #address-cells = <0x02>; + #size-cells = <0x02>; + ranges; + status = "okay"; + + frame@2a830000 { + frame-number = <0x01>; + interrupts = <0x00 0x3c 0x04>; + reg = <0x00 0x2a830000 0x00 0x10000>; + }; + }; + + mhu@2b1f0000 { + compatible = "arm,mhu\0arm,primecell"; + reg = <0x00 0x2b1f0000 0x00 0x1000>; + interrupts = <0x00 0x24 0x04 0x00 0x23 0x04>; + interrupt-names = "mhu_lpri_rx\0mhu_hpri_rx"; + #mbox-cells = <0x01>; + clocks = <0x11>; + clock-names = "apb_pclk"; + linux,phandle = <0x13>; + phandle = <0x13>; + }; + + interrupt-controller@2c010000 { + compatible = "arm,gic-400\0arm,cortex-a15-gic"; + reg = <0x00 0x2c010000 0x00 0x1000 + 0x00 0x2c02f000 0x00 0x2000 + 0x00 0x2c04f000 0x00 0x2000 + 0x00 0x2c06f000 0x00 0x2000>; + #address-cells = <0x02>; + #interrupt-cells = <0x03>; + #size-cells = <0x02>; + interrupt-controller; + interrupts = <0x01 0x09 0x3f04>; + ranges = <0x00 0x00 0x00 0x2c1c0000 0x00 0x40000>; + linux,phandle = <0x01>; + phandle = <0x01>; + + v2m@0 { + compatible = "arm,gic-v2m-frame"; + msi-controller; + reg = <0x00 0x00 0x00 0x1000>; + linux,phandle = <0x12>; + phandle = <0x12>; + }; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <0x01 0x0d 0x3f08 0x01 0x0e 0x3f08 0x01 0x0b 0x3f08 0x01 0x0a 0x3f08>; + }; + + sram@2e000000 { + compatible = "arm,juno-sram-ns\0mmio-sram"; + reg = <0x00 0x2e000000 0x00 0x8000>; + #address-cells = <0x01>; + #size-cells = <0x01>; + ranges = <0x00 0x00 0x2e000000 0x8000>; + + scp-shmem@0 { + compatible = "arm,juno-scp-shmem"; + reg = <0x00 0x200>; + }; + + scp-shmem@200 { + compatible = "arm,juno-scp-shmem"; + reg = <0x200 0x200>; + linux,phandle = <0x14>; + phandle = <0x14>; + }; + }; + + pcie-controller@40000000 { + compatible = "arm,juno-r1-pcie\0plda,xpressrich3-axi\0pci-host-ecam-generic"; + device_type = "pci"; + reg = <0x00 0x40000000 0x00 0x10000000>; + bus-range = <0x00 0xff>; + linux,pci-domain = <0x00>; + #address-cells = <0x03>; + #size-cells = <0x02>; + dma-coherent; + ranges = <0x1000000 0x00 0x00 0x00 + 0x5f800000 0x00 0x800000 0x2000000 + 0x00 0x50000000 0x00 0x50000000 + 0x00 0x8000000 0x42000000 0x40 + 0x00 0x40 0x00 0x01 0x00>; + #interrupt-cells = <0x01>; + interrupt-map-mask = <0x00 0x00 0x00 0x07>; + interrupt-map = <0x00 0x00 0x00 0x01 0x01 0x00 0x00 0x00 + 0x88 0x04 0x00 0x00 0x00 0x02 0x01 0x00 + 0x00 0x00 0x89 0x04 0x00 0x00 0x00 0x03 + 0x01 0x00 0x00 0x00 0x8a 0x04 0x00 0x00 + 0x00 0x04 0x01 0x00 0x00 0x00 0x8b 0x04>; + msi-parent = <0x12>; + status = "okay"; + }; + + scpi { + compatible = "arm,scpi"; + mboxes = <0x13 0x01>; + shmem = <0x14>; + + clocks { + compatible = "arm,scpi-clocks"; + + scpi-dvfs { + compatible = "arm,scpi-dvfs-clocks"; + #clock-cells = <0x01>; + clock-indices = <0x00 0x01 0x02>; + clock-output-names = "atlclk\0aplclk\0clk_mali"; + linux,phandle = <0x09>; + phandle = <0x09>; + }; + + scpi-clk { + compatible = "arm,scpi-variable-clocks"; + #clock-cells = <0x01>; + clock-indices = <0x03 0x04 0x05>; + clock-output-names = "pxlclk\0pxlclk1\0i2sclk"; + linux,phandle = <0x19>; + phandle = <0x19>; + }; + }; + + scpi-power-domains { + compatible = "arm,scpi-power-domains"; + num-domains = <0x02>; + #power-domain-cells = <0x01>; + linux,phandle = <0x22>; + phandle = <0x22>; + }; + + sensors { + compatible = "arm,scpi-sensors"; + #thermal-sensor-cells = <0x01>; + linux,phandle = <0x15>; + phandle = <0x15>; + }; + }; + + thermal-zones { + + pmic { + polling-delay = <0x3e8>; + polling-delay-passive = <0x64>; + thermal-sensors = <0x15 0x00>; + }; + + soc { + polling-delay = <0x3e8>; + polling-delay-passive = <0x64>; + sustainable-power = <0x9c4>; + thermal-sensors = <0x15 0x03>; + + trips { + + threshold { + temperature = <0xd6d8>; + hysteresis = <0x3e8>; + type = "passive"; + }; + + target { + temperature = <0xfde8>; + hysteresis = <0x3e8>; + type = "passive"; + linux,phandle = <0x16>; + phandle = <0x16>; + }; + }; + + cooling-maps { + + map0 { + trip = <0x16>; + cooling-device = <0x04 0xffffffff 0xffffffff>; + contribution = <0x800>; + }; + + map1 { + trip = <0x16>; + contribution = <0x400>; + cooling-device = <0x02 0xffffffff 0xffffffff>; + }; + + map2 { + trip = <0x16>; + cooling-device = <0x17 0xffffffff 0xffffffff>; + contribution = <0x400>; + }; + }; + }; + + big_cluster { + polling-delay = <0x3e8>; + polling-delay-passive = <0x64>; + thermal-sensors = <0x15 0x15>; + status = "okay"; + }; + + little_cluster { + polling-delay = <0x3e8>; + polling-delay-passive = <0x64>; + thermal-sensors = <0x15 0x16>; + status = "okay"; + }; + + gpu0 { + polling-delay = <0x3e8>; + polling-delay-passive = <0x64>; + thermal-sensors = <0x15 0x17>; + status = "okay"; + }; + + gpu1 { + polling-delay = <0x3e8>; + polling-delay-passive = <0x64>; + thermal-sensors = <0x15 0x18>; + status = "okay"; + }; + }; + + refclk7273800hz { + compatible = "fixed-clock"; + #clock-cells = <0x00>; + clock-frequency = <0x6efd48>; + clock-output-names = "juno:uartclk"; + linux,phandle = <0x1b>; + phandle = <0x1b>; + }; + + clk48mhz { + compatible = "fixed-clock"; + #clock-cells = <0x00>; + clock-frequency = <0x2dc6c00>; + clock-output-names = "clk48mhz"; + linux,phandle = <0x1e>; + phandle = <0x1e>; + }; + + clk50mhz { + compatible = "fixed-clock"; + #clock-cells = <0x00>; + clock-frequency = <0x2faf080>; + clock-output-names = "smc_clk"; + linux,phandle = <0x1c>; + phandle = <0x1c>; + }; + + refclk100mhz { + compatible = "fixed-clock"; + #clock-cells = <0x00>; + clock-frequency = <0x5f5e100>; + clock-output-names = "apb_pclk"; + linux,phandle = <0x11>; + phandle = <0x11>; + }; + + refclk400mhz { + compatible = "fixed-clock"; + #clock-cells = <0x00>; + clock-frequency = <0x17d78400>; + clock-output-names = "faxi_clk"; + linux,phandle = <0x18>; + phandle = <0x18>; + }; + + dma@7ff00000 { + compatible = "arm,pl330\0arm,primecell"; + reg = <0x00 0x7ff00000 0x00 0x1000>; + #dma-cells = <0x01>; + #dma-channels = <0x08>; + #dma-requests = <0x20>; + interrupts = <0x00 0x58 0x04 0x00 0x59 0x04 0x00 0x5a + 0x04 0x00 0x5b 0x04 0x00 0x5c 0x04 0x00 + 0x6c 0x04 0x00 0x6d 0x04 0x00 0x6e 0x04 + 0x00 0x6f 0x04>; + clocks = <0x18>; + clock-names = "apb_pclk"; + linux,phandle = <0x1f>; + phandle = <0x1f>; + }; + + hdlcd@7ff60000 { + compatible = "arm,hdlcd"; + reg = <0x00 0x7ff60000 0x00 0x1000>; + interrupts = <0x00 0x55 0x04>; + clocks = <0x19 0x03>; + clock-names = "pxlclk"; + + port { + + hdlcd0-endpoint { + remote-endpoint = <0x1a>; + linux,phandle = <0x1d>; + phandle = <0x1d>; + }; + }; + }; + + uart@7ff80000 { + compatible = "arm,pl011\0arm,primecell"; + reg = <0x00 0x7ff80000 0x00 0x1000>; + interrupts = <0x00 0x53 0x04>; + clocks = <0x1b 0x11>; + clock-names = "uartclk\0apb_pclk"; + }; + + i2c@7ffa0000 { + compatible = "snps,designware-i2c"; + reg = <0x00 0x7ffa0000 0x00 0x1000>; + #address-cells = <0x01>; + #size-cells = <0x00>; + interrupts = <0x00 0x68 0x04>; + clock-frequency = <0x186a0>; + i2c-sda-hold-time-ns = <0x1f4>; + clocks = <0x1c>; + + hdmi-transmitter@70 { + compatible = "nxp,tda998x"; + reg = <0x70>; + audio-ports = <0x03 0x04>; + audio-port-names = "i2s\0spdif"; + #sound-dai-cells = <0x01>; + linux,phandle = <0x21>; + phandle = <0x21>; + + port { + + tda998x-0-endpoint { + remote-endpoint = <0x1d>; + linux,phandle = <0x1a>; + phandle = <0x1a>; + }; + }; + }; + + hdmi-transmitter@71 { + compatible = "nxp,tda998x"; + reg = <0x71>; + + port { + }; + }; + }; + + ohci@7ffb0000 { + compatible = "generic-ohci"; + reg = <0x00 0x7ffb0000 0x00 0x10000>; + interrupts = <0x00 0x74 0x04>; + clocks = <0x1e>; + }; + + ehci@7ffc0000 { + compatible = "generic-ehci"; + reg = <0x00 0x7ffc0000 0x00 0x10000>; + interrupts = <0x00 0x75 0x04>; + clocks = <0x1e>; + }; + + memory-controller@7ffd0000 { + compatible = "arm,pl354\0arm,primecell"; + reg = <0x00 0x7ffd0000 0x00 0x1000>; + interrupts = <0x00 0x56 0x04 0x00 0x57 0x04>; + clocks = <0x1c>; + clock-names = "apb_pclk"; + }; + + memory@80000000 { + device_type = "memory"; + reg = <0x00 0x80000000 0x00 0x7f000000 0x08 0x80000000 0x01 0x80000000>; + }; + + reserved-memory { + #address-cells = <0x02>; + #size-cells = <0x02>; + ranges; + + optee@0xfee00000 { + reg = <0x00 0xfee00000 0x00 0x200000>; + no-map; + }; + }; + + i2s@7ff90000 { + compatible = "snps,designware-i2s"; + reg = <0x00 0x7ff90000 0x00 0x1000>; + clocks = <0x19 0x05 0x11>; + clock-names = "i2sclk\0apb_pclk"; + #sound-dai-cells = <0x00>; + dmas = <0x1f 0x05>; + dma-names = "tx"; + linux,phandle = <0x20>; + phandle = <0x20>; + }; + + hdmi_audio@0 { + compatible = "linux,hdmi-audio"; + #sound-dai-cells = <0x00>; + status = "okay"; + }; + + sound { + compatible = "simple-audio-card"; + simple-audio-card,format = "i2s"; + + simple-audio-card,cpu { + sound-dai = <0x20>; + }; + + simple-audio-card,codec { + sound-dai = <0x21 0x00>; + }; + }; + + gpu@0x2d000000 { + compatible = "arm,malit6xx\0arm,mali-midgard"; + #cooling-cells = <0x02>; + reg = <0x00 0x2d000000 0x00 0x4000>; + interrupts = <0x00 0x21 0x04 0x00 0x22 0x04 0x00 0x20 0x04>; + interrupt-names = "JOB\0MMU\0GPU"; + clocks = <0x09 0x02>; + clock-names = "clk_mali"; + power-domains = <0x22 0x01>; + linux,phandle = <0x17>; + phandle = <0x17>; + + power_model { + compatible = "arm,mali-simple-power-model"; + voltage = <0x320>; + frequency = <0x1f4>; + static-power = <0x1f4>; + dynamic-power = <0x5dc>; + ts = <0x4e20 0x7d0 0xffffffec 0x02>; + thermal-zone = "soc"; + }; + }; + + smb@08000000 { + compatible = "simple-bus"; + #address-cells = <0x02>; + #size-cells = <0x01>; + ranges = <0x00 0x00 0x00 0x8000000 + 0x4000000 0x01 0x00 0x00 + 0x14000000 0x4000000 0x02 0x00 + 0x00 0x18000000 0x4000000 0x03 + 0x00 0x00 0x1c000000 0x4000000 + 0x04 0x00 0x00 0xc000000 + 0x4000000 0x05 0x00 0x00 + 0x10000000 0x4000000>; + #interrupt-cells = <0x01>; + interrupt-map-mask = <0x00 0x00 0x0f>; + interrupt-map = <0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x44 + 0x04 0x00 0x00 0x01 0x01 0x00 0x00 0x00 + 0x45 0x04 0x00 0x00 0x02 0x01 0x00 0x00 + 0x00 0x46 0x04 0x00 0x00 0x03 0x01 0x00 + 0x00 0x00 0xa0 0x04 0x00 0x00 0x04 0x01 + 0x00 0x00 0x00 0xa1 0x04 0x00 0x00 0x05 + 0x01 0x00 0x00 0x00 0xa2 0x04 0x00 0x00 + 0x06 0x01 0x00 0x00 0x00 0xa3 0x04 0x00 + 0x00 0x07 0x01 0x00 0x00 0x00 0xa4 0x04 + 0x00 0x00 0x08 0x01 0x00 0x00 0x00 0xa5 + 0x04 0x00 0x00 0x09 0x01 0x00 0x00 0x00 + 0xa6 0x04 0x00 0x00 0x0a 0x01 0x00 0x00 + 0x00 0xa7 0x04 0x00 0x00 0x0b 0x01 0x00 + 0x00 0x00 0xa8 0x04 0x00 0x00 0x0c 0x01 + 0x00 0x00 0x00 0xa9 0x04>; + + clk24mhz { + compatible = "fixed-clock"; + #clock-cells = <0x00>; + clock-frequency = <0x16e3600>; + clock-output-names = "juno_mb:clk24mhz"; + linux,phandle = <0x28>; + phandle = <0x28>; + }; + + clk25mhz { + compatible = "fixed-clock"; + #clock-cells = <0x00>; + clock-frequency = <0x17d7840>; + clock-output-names = "juno_mb:clk25mhz"; + linux,phandle = <0x24>; + phandle = <0x24>; + }; + + refclk1mhz { + compatible = "fixed-clock"; + #clock-cells = <0x00>; + clock-frequency = <0xf4240>; + clock-output-names = "juno_mb:refclk1mhz"; + linux,phandle = <0x27>; + phandle = <0x27>; + }; + + refclk32khz { + compatible = "fixed-clock"; + #clock-cells = <0x00>; + clock-frequency = <0x8000>; + clock-output-names = "juno_mb:refclk32khz"; + linux,phandle = <0x26>; + phandle = <0x26>; + }; + + motherboard { + compatible = "arm,vexpress,v2p-p1\0simple-bus"; + #address-cells = <0x02>; + #size-cells = <0x01>; + #interrupt-cells = <0x01>; + ranges; + model = "V2M-Juno"; + arm,hbi = <0x252>; + arm,vexpress,site = <0x00>; + arm,v2m-memory-map = "rs1"; + + mcc-sb-3v3 { + compatible = "regulator-fixed"; + regulator-name = "MCC_SB_3V3"; + regulator-min-microvolt = <0x325aa0>; + regulator-max-microvolt = <0x325aa0>; + regulator-always-on; + linux,phandle = <0x25>; + phandle = <0x25>; + }; + + gpio_keys { + compatible = "gpio-keys"; + #address-cells = <0x01>; + #size-cells = <0x00>; + + power-button { + debounce_interval = <0x32>; + wakeup-source; + linux,code = <0x74>; + label = "POWER"; + gpios = <0x23 0x00 0x04>; + }; + + home-button { + debounce_interval = <0x32>; + wakeup-source; + linux,code = <0x66>; + label = "HOME"; + gpios = <0x23 0x01 0x04>; + }; + + rlock-button { + debounce_interval = <0x32>; + wakeup-source; + linux,code = <0x98>; + label = "RLOCK"; + gpios = <0x23 0x02 0x04>; + }; + + vol-up-button { + debounce_interval = <0x32>; + wakeup-source; + linux,code = <0x73>; + label = "VOL+"; + gpios = <0x23 0x03 0x04>; + }; + + vol-down-button { + debounce_interval = <0x32>; + wakeup-source; + linux,code = <0x72>; + label = "VOL-"; + gpios = <0x23 0x04 0x04>; + }; + + nmi-button { + debounce_interval = <0x32>; + wakeup-source; + linux,code = <0x63>; + label = "NMI"; + gpios = <0x23 0x05 0x04>; + }; + }; + + flash@0,00000000 { + compatible = "arm,vexpress-flash\0cfi-flash"; + linux,part-probe = "afs"; + reg = <0x00 0x00 0x4000000>; + bank-width = <0x04>; + status = "disabled"; + }; + + ethernet@2,00000000 { + compatible = "smsc,lan9118\0smsc,lan9115"; + reg = <0x02 0x00 0x10000>; + interrupts = <0x03>; + phy-mode = "mii"; + reg-io-width = <0x04>; + smsc,irq-active-high; + smsc,irq-push-pull; + clocks = <0x24>; + vdd33a-supply = <0x25>; + vddvario-supply = <0x25>; + status = "disabled"; + }; + + usb@5,00000000 { + compatible = "nxp,usb-isp1763"; + reg = <0x05 0x00 0x20000>; + bus-width = <0x10>; + interrupts = <0x04>; + }; + + iofpga@3,00000000 { + compatible = "arm,amba-bus\0simple-bus"; + #address-cells = <0x01>; + #size-cells = <0x01>; + ranges = <0x00 0x03 0x00 0x200000>; + + sysctl@020000 { + compatible = "arm,sp810\0arm,primecell"; + reg = <0x20000 0x1000>; + clocks = <0x26 0x27 0x28>; + clock-names = "refclk\0timclk\0apb_pclk"; + #clock-cells = <0x01>; + clock-output-names = "timerclken0\0timerclken1\0timerclken2\0timerclken3"; + assigned-clocks = <0x29 0x00 0x29 0x01 0x29 0x03 0x29 0x03>; + assigned-clock-parents = <0x27 0x27 0x27 0x27>; + linux,phandle = <0x29>; + phandle = <0x29>; + }; + + apbregs@010000 { + compatible = "syscon\0simple-mfd"; + reg = <0x10000 0x1000>; + + led0 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x01>; + label = "vexpress:0"; + linux,default-trigger = "heartbeat"; + default-state = "on"; + }; + + led1 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x02>; + label = "vexpress:1"; + linux,default-trigger = "mmc0"; + default-state = "off"; + }; + + led2 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x04>; + label = "vexpress:2"; + linux,default-trigger = "cpu0"; + default-state = "off"; + }; + + led3 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x08>; + label = "vexpress:3"; + linux,default-trigger = "cpu1"; + default-state = "off"; + }; + + led4 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x10>; + label = "vexpress:4"; + linux,default-trigger = "cpu2"; + default-state = "off"; + }; + + led5 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x20>; + label = "vexpress:5"; + linux,default-trigger = "cpu3"; + default-state = "off"; + }; + + led6 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x40>; + label = "vexpress:6"; + default-state = "off"; + }; + + led7 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x80>; + label = "vexpress:7"; + default-state = "off"; + }; + }; + + mmci@050000 { + compatible = "arm,pl180\0arm,primecell"; + reg = <0x50000 0x1000>; + interrupts = <0x05>; + max-frequency = <0xb71b00>; + vmmc-supply = <0x25>; + clocks = <0x28 0x1c>; + clock-names = "mclk\0apb_pclk"; + }; + + kmi@060000 { + compatible = "arm,pl050\0arm,primecell"; + reg = <0x60000 0x1000>; + interrupts = <0x08>; + clocks = <0x28 0x1c>; + clock-names = "KMIREFCLK\0apb_pclk"; + }; + + kmi@070000 { + compatible = "arm,pl050\0arm,primecell"; + reg = <0x70000 0x1000>; + interrupts = <0x08>; + clocks = <0x28 0x1c>; + clock-names = "KMIREFCLK\0apb_pclk"; + }; + + wdt@0f0000 { + compatible = "arm,sp805\0arm,primecell"; + reg = <0xf0000 0x10000>; + interrupts = <0x07>; + clocks = <0x28 0x1c>; + clock-names = "wdogclk\0apb_pclk"; + }; + + timer@110000 { + compatible = "arm,sp804\0arm,primecell"; + reg = <0x110000 0x10000>; + interrupts = <0x09>; + clocks = <0x29 0x00 0x29 0x01 0x28>; + clock-names = "timclken1\0timclken2\0apb_pclk"; + }; + + timer@120000 { + compatible = "arm,sp804\0arm,primecell"; + reg = <0x120000 0x10000>; + interrupts = <0x09>; + clocks = <0x29 0x02 0x29 0x03 0x28>; + clock-names = "timclken1\0timclken2\0apb_pclk"; + }; + + rtc@170000 { + compatible = "arm,pl031\0arm,primecell"; + reg = <0x170000 0x10000>; + interrupts = <0x00>; + clocks = <0x1c>; + clock-names = "apb_pclk"; + }; + + gpio@1d0000 { + compatible = "arm,pl061\0arm,primecell"; + reg = <0x1d0000 0x1000>; + interrupts = <0x06>; + clocks = <0x1c>; + clock-names = "apb_pclk"; + gpio-controller; + #gpio-cells = <0x02>; + interrupt-controller; + #interrupt-cells = <0x02>; + linux,phandle = <0x23>; + phandle = <0x23>; + }; + }; + }; + }; + + tlx@60000000 { + compatible = "simple-bus"; + #address-cells = <0x01>; + #size-cells = <0x01>; + ranges = <0x00 0x00 0x60000000 0x10000000>; + #interrupt-cells = <0x01>; + interrupt-map-mask = <0x00 0x00>; + interrupt-map = <0x00 0x00 0x01 0x00 0x00 0x00 0xa8 0x04>; + }; + + firmware { + + optee { + compatible = "linaro,optee-tz"; + method = "smc"; + }; + }; +}; diff --git a/configs/vexpress_aemv8a_juno_defconfig b/configs/vexpress_aemv8a_juno_defconfig index 3125adaf5c4..95b4fe2c0a9 100644 --- a/configs/vexpress_aemv8a_juno_defconfig +++ b/configs/vexpress_aemv8a_juno_defconfig @@ -52,3 +52,4 @@ CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_GENERIC=y +CONFIG_DEFAULT_DEVICE_TREE="juno-r2"
Add an empty file to prevent build errors when building with CONFIG_OF_SEPARATE enabled.
The build instructions in U-Boot do not provide enough detail to build a useful devicetree, unfortunately.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
arch/arm/dts/Makefile | 2 ++ arch/arm/dts/xenguest-arm64.dts | 15 +++++++++++++++ configs/xenguest_arm64_defconfig | 1 + 3 files changed, 18 insertions(+) create mode 100644 arch/arm/dts/xenguest-arm64.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 0be50ecd9c8..a9c76bcf0a9 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1131,6 +1131,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \ mt8516-pumpkin.dtb \ mt8518-ap1-emmc.dtb
+dtb-$(CONFIG_XEN) += xenguest-arm64.dtb + dtb-$(CONFIG_TARGET_GE_BX50V3) += \ imx6q-bx50v3.dtb \ imx6q-b850v3.dtb \ diff --git a/arch/arm/dts/xenguest-arm64.dts b/arch/arm/dts/xenguest-arm64.dts new file mode 100644 index 00000000000..52d3b062248 --- /dev/null +++ b/arch/arm/dts/xenguest-arm64.dts @@ -0,0 +1,15 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Dummy devicetre file for xenguest_arm64 + * + * This is required to make the board build with CONFIG OF_SEPARATE + * Build instructions at xenguest_arm64.rst are inadequate for obtaining a real + * devicetree. + * + * Copyright 2021 Google LLC + */ + +/dts-v1/; + +/ { +}; diff --git a/configs/xenguest_arm64_defconfig b/configs/xenguest_arm64_defconfig index b72e40a1399..8e32cd63229 100644 --- a/configs/xenguest_arm64_defconfig +++ b/configs/xenguest_arm64_defconfig @@ -4,6 +4,7 @@ CONFIG_TARGET_XENGUEST_ARM64=y CONFIG_SYS_TEXT_BASE=0x40080000 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_SYS_MALLOC_LEN=0x2000000 +CONFIG_DEFAULT_DEVICE_TREE="xenguest-arm64" CONFIG_IDENT_STRING=" xenguest" CONFIG_SYS_LOAD_ADDR=0x40000000 CONFIG_BOOTDELAY=10
Add an empty file to prevent build errors when building with CONFIG_OF_SEPARATE enabled.
Unfortunately there are no build instructions in the U-Boot tree to enable a real file to be created.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
arch/arm/dts/Makefile | 3 +++ arch/arm/dts/octeontx.dts | 14 ++++++++++++++ configs/octeontx2_95xx_defconfig | 1 + configs/octeontx2_96xx_defconfig | 1 + configs/octeontx_81xx_defconfig | 1 + configs/octeontx_83xx_defconfig | 1 + 6 files changed, 21 insertions(+) create mode 100644 arch/arm/dts/octeontx.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index a9c76bcf0a9..44835145f4b 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1133,6 +1133,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 6d8457f1d07..fac4c50aec4 100644 --- a/configs/octeontx2_95xx_defconfig +++ b/configs/octeontx2_95xx_defconfig @@ -12,6 +12,7 @@ CONFIG_ENV_SECT_SIZE=0x10000 CONFIG_TARGET_OCTEONTX2_95XX=y CONFIG_SYS_MALLOC_LEN=0x4008000 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 b72caef77d8..db883b5542c 100644 --- a/configs/octeontx2_96xx_defconfig +++ b/configs/octeontx2_96xx_defconfig @@ -10,6 +10,7 @@ CONFIG_ENV_SECT_SIZE=0x10000 CONFIG_TARGET_OCTEONTX2_96XX=y CONFIG_SYS_MALLOC_LEN=0x4008000 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 52678d59ff1..8309c29c091 100644 --- a/configs/octeontx_81xx_defconfig +++ b/configs/octeontx_81xx_defconfig @@ -12,6 +12,7 @@ CONFIG_ENV_SECT_SIZE=0x10000 CONFIG_TARGET_OCTEONTX_81XX=y CONFIG_SYS_MALLOC_LEN=0x4008000 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 3890c1e97d4..dae1d4880f8 100644 --- a/configs/octeontx_83xx_defconfig +++ b/configs/octeontx_83xx_defconfig @@ -10,6 +10,7 @@ CONFIG_ENV_SECT_SIZE=0x10000 CONFIG_TARGET_OCTEONTX_83XX=y CONFIG_SYS_MALLOC_LEN=0x4008000 CONFIG_DM_GPIO=y +CONFIG_DEFAULT_DEVICE_TREE="octeontx" CONFIG_DEBUG_UART_BASE=0x87e028000000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_DEBUG_UART=y
Add a devicetree file obtained from qemu for this board. This was obtained with:
qemu-system-aarch64 -M xlnx-versal-virt -machine dumpdtb=dtb.dtb
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
arch/arm/dts/Makefile | 3 +- arch/arm/dts/xilinx-versal-virt.dts | 307 +++++++++++++++++++++++++++ configs/xilinx_versal_virt_defconfig | 1 + 3 files changed, 310 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 44835145f4b..0a30ad327cf 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -352,7 +352,8 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += \ dtb-$(CONFIG_ARCH_VERSAL) += \ versal-mini.dtb \ versal-mini-emmc0.dtb \ - versal-mini-emmc1.dtb + versal-mini-emmc1.dtb \ + xilinx-versal-virt.dtb dtb-$(CONFIG_ARCH_ZYNQMP_R5) += \ zynqmp-r5.dtb dtb-$(CONFIG_AM33XX) += \ diff --git a/arch/arm/dts/xilinx-versal-virt.dts b/arch/arm/dts/xilinx-versal-virt.dts new file mode 100644 index 00000000000..3712af9e7a4 --- /dev/null +++ b/arch/arm/dts/xilinx-versal-virt.dts @@ -0,0 +1,307 @@ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +/* + * Sample device tree for versal-virt board + + * Copyright 2021 Google LLC + */ + +/dts-v1/; + +/ { + compatible = "xlnx-versal-virt"; + model = "Xilinx Versal Virtual development board"; + #address-cells = <0x02>; + #size-cells = <0x02>; + interrupt-parent = <0x8000>; + + memory@0 { + reg = <0x00 0x00 0x00 0x8000000>; + device_type = "memory"; + }; + + clk25 { + u-boot,dm-pre-reloc; + compatible = "fixed-clock"; + #clock-cells = <0x00>; + clock-frequency = <0x17d7840>; + phandle = <0x8003>; + }; + + clk125 { + u-boot,dm-pre-reloc; + compatible = "fixed-clock"; + #clock-cells = <0x00>; + clock-frequency = <0x7735940>; + phandle = <0x8004>; + }; + + cpus { + #address-cells = <0x01>; + #size-cells = <0x00>; + + cpu@0 { + compatible = "arm,cortex-a72"; + device_type = "cpu"; + reg = <0x00>; + }; + + cpu@1 { + compatible = "arm,cortex-a72"; + device_type = "cpu"; + reg = <0x01>; + }; + }; + + rtc@f12a0000 { + compatible = "xlnx,zynqmp-rtc"; + reg = <0x00 0xf12a0000 0x00 0x10000>; + interrupt-names = "alarm\0sec"; + interrupts = <0x00 0x8e 0x04 0x00 0x8f 0x04>; + }; + + sdhci@f1040000 { + compatible = "arasan,sdhci-8.9a"; + reg = <0x00 0xf1040000 0x00 0x10000>; + interrupts = <0x00 0x7e 0x04>; + clock-names = "clk_xin\0clk_ahb"; + clocks = <0x8003 0x8003>; + }; + + sdhci@f1050000 { + compatible = "arasan,sdhci-8.9a"; + reg = <0x00 0xf1050000 0x00 0x10000>; + interrupts = <0x00 0x80 0x04>; + clock-names = "clk_xin\0clk_ahb"; + clocks = <0x8003 0x8003>; + }; + + usb@ff9d0000 { + phandle = <0x8005>; + #size-cells = <0x02>; + #address-cells = <0x02>; + ranges; + clocks = <0x8003 0x8004>; + clock-names = "bus_clk\0ref_clk"; + reg = <0x00 0xff9d0000 0x00 0x10000>; + compatible = "xlnx,versal-dwc3"; + + dwc3@fe200000 { + maximum-speed = "high-speed"; + phandle = <0x8006>; + snps,mask_phy_reset; + snps,refclk_fladj; + snps,dis_u3_susphy_quirk; + snps,dis_u2_susphy_quirk; + phy-names = "usb3-phy"; + dr_mode = "host"; + #stream-id-cells = <0x01>; + snps,quirk-frame-length-adjustment = <0x20>; + interrupts = <0x00 0x16 0x04>; + interrupt-names = "dwc_usb3"; + reg = <0x00 0xfe200000 0x00 0x10000>; + compatible = "snps,dwc3"; + }; + }; + + dma@ffa80000 { + compatible = "xlnx,zynqmp-dma-1.0"; + reg = <0x00 0xffa80000 0x00 0x1000>; + interrupts = <0x00 0x3c 0x04>; + clock-names = "clk_main\0clk_apb"; + clocks = <0x8003 0x8003>; + xlnx,bus-width = <0x40>; + }; + + dma@ffa90000 { + compatible = "xlnx,zynqmp-dma-1.0"; + reg = <0x00 0xffa90000 0x00 0x1000>; + interrupts = <0x00 0x3d 0x04>; + clock-names = "clk_main\0clk_apb"; + clocks = <0x8003 0x8003>; + xlnx,bus-width = <0x40>; + }; + + dma@ffaa0000 { + compatible = "xlnx,zynqmp-dma-1.0"; + reg = <0x00 0xffaa0000 0x00 0x1000>; + interrupts = <0x00 0x3e 0x04>; + clock-names = "clk_main\0clk_apb"; + clocks = <0x8003 0x8003>; + xlnx,bus-width = <0x40>; + }; + + dma@ffab0000 { + compatible = "xlnx,zynqmp-dma-1.0"; + reg = <0x00 0xffab0000 0x00 0x1000>; + interrupts = <0x00 0x3f 0x04>; + clock-names = "clk_main\0clk_apb"; + clocks = <0x8003 0x8003>; + xlnx,bus-width = <0x40>; + }; + + dma@ffac0000 { + compatible = "xlnx,zynqmp-dma-1.0"; + reg = <0x00 0xffac0000 0x00 0x1000>; + interrupts = <0x00 0x40 0x04>; + clock-names = "clk_main\0clk_apb"; + clocks = <0x8003 0x8003>; + xlnx,bus-width = <0x40>; + }; + + dma@ffad0000 { + compatible = "xlnx,zynqmp-dma-1.0"; + reg = <0x00 0xffad0000 0x00 0x1000>; + interrupts = <0x00 0x41 0x04>; + clock-names = "clk_main\0clk_apb"; + clocks = <0x8003 0x8003>; + xlnx,bus-width = <0x40>; + }; + + dma@ffae0000 { + compatible = "xlnx,zynqmp-dma-1.0"; + reg = <0x00 0xffae0000 0x00 0x1000>; + interrupts = <0x00 0x42 0x04>; + clock-names = "clk_main\0clk_apb"; + clocks = <0x8003 0x8003>; + xlnx,bus-width = <0x40>; + }; + + dma@ffaf0000 { + compatible = "xlnx,zynqmp-dma-1.0"; + reg = <0x00 0xffaf0000 0x00 0x1000>; + interrupts = <0x00 0x43 0x04>; + clock-names = "clk_main\0clk_apb"; + clocks = <0x8003 0x8003>; + xlnx,bus-width = <0x40>; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <0x01 0x0d 0x04 0x01 0x0e 0x04 0x01 0x0b 0x04 0x01 0x0a 0x04>; + }; + + gic@f9000000 { + compatible = "arm,gic-v3"; + #interrupt-cells = <0x03>; + reg = <0x00 0xf9000000 0x00 0x10000 0x00 0xf9080000 0x00 0x80000>; + interrupt-controller; + interrupts = <0x01 0x09 0x04>; + phandle = <0x8000>; + }; + + uart@ff000000 { + u-boot,dm-pre-reloc; + compatible = "arm,pl011\0arm,sbsa-uart"; + reg = <0x00 0xff000000 0x00 0x1000>; + interrupts = <0x00 0x12 0x04>; + clock-names = "uartclk\0apb_pclk"; + clocks = <0x8004 0x8004>; + current-speed = <0x1c200>; + }; + + uart@ff010000 { + u-boot,dm-pre-reloc; + compatible = "arm,pl011\0arm,sbsa-uart"; + reg = <0x00 0xff010000 0x00 0x1000>; + interrupts = <0x00 0x13 0x04>; + clock-names = "uartclk\0apb_pclk"; + clocks = <0x8004 0x8004>; + current-speed = <0x1c200>; + }; + + ethernet@ff0c0000 { + #size-cells = <0x00>; + #address-cells = <0x01>; + compatible = "cdns,zynqmp-gem\0cdns,gem"; + reg = <0x00 0xff0c0000 0x00 0x1000>; + interrupts = <0x00 0x38 0x04 0x00 0x38 0x04>; + clock-names = "pclk\0hclk\0tx_clk\0rx_clk"; + clocks = <0x8003 0x8003 0x8004 0x8004>; + phy-handle = <0x8002>; + phy-mode = "rgmii-id"; + + fixed-link { + speed = <0x3e8>; + full-duplex; + phandle = <0x8002>; + }; + }; + + ethernet@ff0d0000 { + #size-cells = <0x00>; + #address-cells = <0x01>; + compatible = "cdns,zynqmp-gem\0cdns,gem"; + reg = <0x00 0xff0d0000 0x00 0x1000>; + interrupts = <0x00 0x3a 0x04 0x00 0x3a 0x04>; + clock-names = "pclk\0hclk\0tx_clk\0rx_clk"; + clocks = <0x8003 0x8003 0x8004 0x8004>; + phy-handle = <0x8001>; + phy-mode = "rgmii-id"; + + fixed-link { + speed = <0x3e8>; + full-duplex; + phandle = <0x8001>; + }; + }; + + virtio_mmio@a0000e00 { + compatible = "virtio,mmio"; + reg = <0x00 0xa0000e00 0x00 0x200>; + interrupts = <0x00 0x76 0x01>; + dma-coherent; + }; + + virtio_mmio@a0000c00 { + compatible = "virtio,mmio"; + reg = <0x00 0xa0000c00 0x00 0x200>; + interrupts = <0x00 0x75 0x01>; + dma-coherent; + }; + + virtio_mmio@a0000a00 { + compatible = "virtio,mmio"; + reg = <0x00 0xa0000a00 0x00 0x200>; + interrupts = <0x00 0x74 0x01>; + dma-coherent; + }; + + virtio_mmio@a0000800 { + compatible = "virtio,mmio"; + reg = <0x00 0xa0000800 0x00 0x200>; + interrupts = <0x00 0x73 0x01>; + dma-coherent; + }; + + virtio_mmio@a0000600 { + compatible = "virtio,mmio"; + reg = <0x00 0xa0000600 0x00 0x200>; + interrupts = <0x00 0x72 0x01>; + dma-coherent; + }; + + virtio_mmio@a0000400 { + compatible = "virtio,mmio"; + reg = <0x00 0xa0000400 0x00 0x200>; + interrupts = <0x00 0x71 0x01>; + dma-coherent; + }; + + virtio_mmio@a0000200 { + compatible = "virtio,mmio"; + reg = <0x00 0xa0000200 0x00 0x200>; + interrupts = <0x00 0x70 0x01>; + dma-coherent; + }; + + virtio_mmio@a0000000 { + compatible = "virtio,mmio"; + reg = <0x00 0xa0000000 0x00 0x200>; + interrupts = <0x00 0x6f 0x01>; + dma-coherent; + }; + + chosen { + stdout-path = "/uart@ff000000"; + }; +}; diff --git a/configs/xilinx_versal_virt_defconfig b/configs/xilinx_versal_virt_defconfig index 11598623954..f0ec2639a38 100644 --- a/configs/xilinx_versal_virt_defconfig +++ b/configs/xilinx_versal_virt_defconfig @@ -7,6 +7,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x100000 CONFIG_SYS_MEMTEST_START=0x00000000 CONFIG_SYS_MEMTEST_END=0x00001000 CONFIG_DM_GPIO=y +CONFIG_DEFAULT_DEVICE_TREE="xilinx-versal-virt" CONFIG_CMD_FRU=y CONFIG_DEFINE_TCM_OCM_MMAP=y CONFIG_COUNTER_FREQUENCY=100000000
Add a dummy devicetree file for these boards. It seems to be possible to obtain a real one from another bootloader called 'bolt' but I will leave this to the maintainer.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
arch/arm/dts/Makefile | 2 ++ arch/arm/dts/bcm7xxx.dts | 15 +++++++++++++++ configs/bcm7260_defconfig | 1 + configs/bcm7445_defconfig | 1 + 4 files changed, 19 insertions(+) create mode 100644 arch/arm/dts/bcm7xxx.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 0a30ad327cf..68ddf5933ea 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1083,6 +1083,8 @@ dtb-$(CONFIG_ARCH_BCM6858) += \
dtb-$(CONFIG_TARGET_BCMNS3) += ns3-board.dtb
+dtb-$(CONFIG_ARCH_BCMSTB) += bcm7xxx.dtb + dtb-$(CONFIG_ASPEED_AST2500) += ast2500-evb.dtb dtb-$(CONFIG_ASPEED_AST2600) += ast2600-evb.dtb
diff --git a/arch/arm/dts/bcm7xxx.dts b/arch/arm/dts/bcm7xxx.dts new file mode 100644 index 00000000000..799cc9caad4 --- /dev/null +++ b/arch/arm/dts/bcm7xxx.dts @@ -0,0 +1,15 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Dummy devicetre file for bcm7260 board + * + * This is required to make the board build with CONFIG OF_SEPARATE + * In-tree document explains how to obtain a real devicetree using 'bolt' but + * I did not attempt this. + * + * Copyright 2021 Google LLC + */ + +/dts-v1/; + +/ { +}; diff --git a/configs/bcm7260_defconfig b/configs/bcm7260_defconfig index 3afb909f712..89b5b01ad76 100644 --- a/configs/bcm7260_defconfig +++ b/configs/bcm7260_defconfig @@ -7,6 +7,7 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x10000 CONFIG_ENV_OFFSET=0x814800 CONFIG_SYS_MALLOC_LEN=0x2800000 +CONFIG_DEFAULT_DEVICE_TREE="bcm7xxx" CONFIG_ENV_OFFSET_REDUND=0x824800 CONFIG_SYS_LOAD_ADDR=0x02000000 CONFIG_FIT=y diff --git a/configs/bcm7445_defconfig b/configs/bcm7445_defconfig index 3726abd7354..92c1b36185a 100644 --- a/configs/bcm7445_defconfig +++ b/configs/bcm7445_defconfig @@ -8,6 +8,7 @@ CONFIG_ENV_SIZE=0x10000 CONFIG_ENV_OFFSET=0x1E0000 CONFIG_ENV_SECT_SIZE=0x10000 CONFIG_SYS_MALLOC_LEN=0xa00000 +CONFIG_DEFAULT_DEVICE_TREE="bcm7xxx" CONFIG_ENV_OFFSET_REDUND=0x1F0000 CONFIG_SYS_LOAD_ADDR=0x02000000 CONFIG_FIT=y
Add a devicetree file obtained from qemu for this board. This was obtained with:
qemu-system-ppc64 -machine ppce500 -cpu e6500 -M dumpdtb=dtb.dtb
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/qemu-ppce500.dts | 264 ++++++++++++++++++++++++++++++ configs/qemu-ppce500_defconfig | 1 + 3 files changed, 266 insertions(+) create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
diff --git a/arch/powerpc/dts/Makefile b/arch/powerpc/dts/Makefile index ceaa8ce5c82..66d22ae8a45 100644 --- a/arch/powerpc/dts/Makefile +++ b/arch/powerpc/dts/Makefile @@ -18,6 +18,7 @@ dtb-$(CONFIG_TARGET_P2041RDB) += p2041rdb.dtb dtb-$(CONFIG_TARGET_P3041DS) += p3041ds.dtb dtb-$(CONFIG_TARGET_P4080DS) += p4080ds.dtb dtb-$(CONFIG_TARGET_P5040DS) += p5040ds.dtb +dtb-$(CONFIG_TARGET_QEMU_PPCE500) += qemu-ppce500.dtb dtb-$(CONFIG_TARGET_SOCRATES) += socrates.dtb dtb-$(CONFIG_TARGET_T1024RDB) += t1024rdb.dtb dtb-$(CONFIG_TARGET_T1042D4RDB) += t1042d4rdb.dtb diff --git a/arch/powerpc/dts/qemu-ppce500.dts b/arch/powerpc/dts/qemu-ppce500.dts new file mode 100644 index 00000000000..92368e4d731 --- /dev/null +++ b/arch/powerpc/dts/qemu-ppce500.dts @@ -0,0 +1,264 @@ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +/* + * Sample device tree for qemu-ppce400 + + * Copyright 2021 Google LLC + */ +/dts-v1/; + +/ { + compatible = "fsl,qemu-e500"; + model = "QEMU ppce500"; + #size-cells = <0x02>; + #address-cells = <0x02>; + + platform@f00000000 { + interrupt-parent = <0x8003>; + ranges = <0x00 0x0f 0x00 0x8000000>; + #address-cells = <0x01>; + #size-cells = <0x01>; + compatible = "qemu,platform\0simple-bus"; + }; + + pci@fe0008000 { + #address-cells = <0x03>; + #size-cells = <0x02>; + #interrupt-cells = <0x01>; + clock-frequency = <0x3f940aa>; + reg = <0x0f 0xe0008000 0x00 0x1000>; + ranges = <0x2000000 0x00 0xe0000000 0x0c + 0x00 0x00 0x20000000 0x1000000 + 0x00 0x00 0x0f 0xe1000000 + 0x00 0x10000>; + fsl,msi = <0x8004>; + bus-range = <0x00 0xff>; + interrupts = <0x18 0x02>; + interrupt-parent = <0x8003>; + interrupt-map = <0x800 0x00 0x00 0x01 0x8003 0x02 0x01 0x800 + 0x00 0x00 0x02 0x8003 0x03 0x01 0x800 0x00 + 0x00 0x03 0x8003 0x04 0x01 0x800 0x00 0x00 + 0x04 0x8003 0x01 0x01 0x1000 0x00 0x00 0x01 + 0x8003 0x03 0x01 0x1000 0x00 0x00 0x02 0x8003 + 0x04 0x01 0x1000 0x00 0x00 0x03 0x8003 0x01 + 0x01 0x1000 0x00 0x00 0x04 0x8003 0x02 0x01 + 0x1800 0x00 0x00 0x01 0x8003 0x04 0x01 0x1800 + 0x00 0x00 0x02 0x8003 0x01 0x01 0x1800 0x00 + 0x00 0x03 0x8003 0x02 0x01 0x1800 0x00 0x00 + 0x04 0x8003 0x03 0x01 0x2000 0x00 0x00 0x01 + 0x8003 0x01 0x01 0x2000 0x00 0x00 0x02 0x8003 + 0x02 0x01 0x2000 0x00 0x00 0x03 0x8003 0x03 + 0x01 0x2000 0x00 0x00 0x04 0x8003 0x04 0x01 + 0x2800 0x00 0x00 0x01 0x8003 0x02 0x01 0x2800 + 0x00 0x00 0x02 0x8003 0x03 0x01 0x2800 0x00 + 0x00 0x03 0x8003 0x04 0x01 0x2800 0x00 0x00 + 0x04 0x8003 0x01 0x01 0x3000 0x00 0x00 0x01 + 0x8003 0x03 0x01 0x3000 0x00 0x00 0x02 0x8003 + 0x04 0x01 0x3000 0x00 0x00 0x03 0x8003 0x01 + 0x01 0x3000 0x00 0x00 0x04 0x8003 0x02 0x01 + 0x3800 0x00 0x00 0x01 0x8003 0x04 0x01 0x3800 + 0x00 0x00 0x02 0x8003 0x01 0x01 0x3800 0x00 + 0x00 0x03 0x8003 0x02 0x01 0x3800 0x00 0x00 + 0x04 0x8003 0x03 0x01 0x4000 0x00 0x00 0x01 + 0x8003 0x01 0x01 0x4000 0x00 0x00 0x02 0x8003 + 0x02 0x01 0x4000 0x00 0x00 0x03 0x8003 0x03 + 0x01 0x4000 0x00 0x00 0x04 0x8003 0x04 0x01 + 0x4800 0x00 0x00 0x01 0x8003 0x02 0x01 0x4800 + 0x00 0x00 0x02 0x8003 0x03 0x01 0x4800 0x00 + 0x00 0x03 0x8003 0x04 0x01 0x4800 0x00 0x00 + 0x04 0x8003 0x01 0x01 0x5000 0x00 0x00 0x01 + 0x8003 0x03 0x01 0x5000 0x00 0x00 0x02 0x8003 + 0x04 0x01 0x5000 0x00 0x00 0x03 0x8003 0x01 + 0x01 0x5000 0x00 0x00 0x04 0x8003 0x02 0x01 + 0x5800 0x00 0x00 0x01 0x8003 0x04 0x01 0x5800 + 0x00 0x00 0x02 0x8003 0x01 0x01 0x5800 0x00 + 0x00 0x03 0x8003 0x02 0x01 0x5800 0x00 0x00 + 0x04 0x8003 0x03 0x01 0x6000 0x00 0x00 0x01 + 0x8003 0x01 0x01 0x6000 0x00 0x00 0x02 0x8003 + 0x02 0x01 0x6000 0x00 0x00 0x03 0x8003 0x03 + 0x01 0x6000 0x00 0x00 0x04 0x8003 0x04 0x01 + 0x6800 0x00 0x00 0x01 0x8003 0x02 0x01 0x6800 + 0x00 0x00 0x02 0x8003 0x03 0x01 0x6800 0x00 + 0x00 0x03 0x8003 0x04 0x01 0x6800 0x00 0x00 + 0x04 0x8003 0x01 0x01 0x7000 0x00 0x00 0x01 + 0x8003 0x03 0x01 0x7000 0x00 0x00 0x02 0x8003 + 0x04 0x01 0x7000 0x00 0x00 0x03 0x8003 0x01 + 0x01 0x7000 0x00 0x00 0x04 0x8003 0x02 0x01 + 0x7800 0x00 0x00 0x01 0x8003 0x04 0x01 0x7800 + 0x00 0x00 0x02 0x8003 0x01 0x01 0x7800 0x00 + 0x00 0x03 0x8003 0x02 0x01 0x7800 0x00 0x00 + 0x04 0x8003 0x03 0x01 0x8000 0x00 0x00 0x01 + 0x8003 0x01 0x01 0x8000 0x00 0x00 0x02 0x8003 + 0x02 0x01 0x8000 0x00 0x00 0x03 0x8003 0x03 + 0x01 0x8000 0x00 0x00 0x04 0x8003 0x04 0x01 + 0x8800 0x00 0x00 0x01 0x8003 0x02 0x01 0x8800 + 0x00 0x00 0x02 0x8003 0x03 0x01 0x8800 0x00 + 0x00 0x03 0x8003 0x04 0x01 0x8800 0x00 0x00 + 0x04 0x8003 0x01 0x01 0x9000 0x00 0x00 0x01 + 0x8003 0x03 0x01 0x9000 0x00 0x00 0x02 0x8003 + 0x04 0x01 0x9000 0x00 0x00 0x03 0x8003 0x01 + 0x01 0x9000 0x00 0x00 0x04 0x8003 0x02 0x01 + 0x9800 0x00 0x00 0x01 0x8003 0x04 0x01 0x9800 + 0x00 0x00 0x02 0x8003 0x01 0x01 0x9800 0x00 + 0x00 0x03 0x8003 0x02 0x01 0x9800 0x00 0x00 + 0x04 0x8003 0x03 0x01 0xa000 0x00 0x00 0x01 + 0x8003 0x01 0x01 0xa000 0x00 0x00 0x02 0x8003 + 0x02 0x01 0xa000 0x00 0x00 0x03 0x8003 0x03 + 0x01 0xa000 0x00 0x00 0x04 0x8003 0x04 0x01 + 0xa800 0x00 0x00 0x01 0x8003 0x02 0x01 0xa800 + 0x00 0x00 0x02 0x8003 0x03 0x01 0xa800 0x00 + 0x00 0x03 0x8003 0x04 0x01 0xa800 0x00 0x00 + 0x04 0x8003 0x01 0x01 0xb000 0x00 0x00 0x01 + 0x8003 0x03 0x01 0xb000 0x00 0x00 0x02 0x8003 + 0x04 0x01 0xb000 0x00 0x00 0x03 0x8003 0x01 + 0x01 0xb000 0x00 0x00 0x04 0x8003 0x02 0x01 + 0xb800 0x00 0x00 0x01 0x8003 0x04 0x01 0xb800 + 0x00 0x00 0x02 0x8003 0x01 0x01 0xb800 0x00 + 0x00 0x03 0x8003 0x02 0x01 0xb800 0x00 0x00 + 0x04 0x8003 0x03 0x01 0xc000 0x00 0x00 0x01 + 0x8003 0x01 0x01 0xc000 0x00 0x00 0x02 0x8003 + 0x02 0x01 0xc000 0x00 0x00 0x03 0x8003 0x03 + 0x01 0xc000 0x00 0x00 0x04 0x8003 0x04 0x01 + 0xc800 0x00 0x00 0x01 0x8003 0x02 0x01 0xc800 + 0x00 0x00 0x02 0x8003 0x03 0x01 0xc800 0x00 + 0x00 0x03 0x8003 0x04 0x01 0xc800 0x00 0x00 + 0x04 0x8003 0x01 0x01 0xd000 0x00 0x00 0x01 + 0x8003 0x03 0x01 0xd000 0x00 0x00 0x02 0x8003 + 0x04 0x01 0xd000 0x00 0x00 0x03 0x8003 0x01 + 0x01 0xd000 0x00 0x00 0x04 0x8003 0x02 0x01 + 0xd800 0x00 0x00 0x01 0x8003 0x04 0x01 0xd800 + 0x00 0x00 0x02 0x8003 0x01 0x01 0xd800 0x00 + 0x00 0x03 0x8003 0x02 0x01 0xd800 0x00 0x00 + 0x04 0x8003 0x03 0x01 0xe000 0x00 0x00 0x01 + 0x8003 0x01 0x01 0xe000 0x00 0x00 0x02 0x8003 + 0x02 0x01 0xe000 0x00 0x00 0x03 0x8003 0x03 + 0x01 0xe000 0x00 0x00 0x04 0x8003 0x04 0x01 + 0xe800 0x00 0x00 0x01 0x8003 0x02 0x01 0xe800 + 0x00 0x00 0x02 0x8003 0x03 0x01 0xe800 0x00 + 0x00 0x03 0x8003 0x04 0x01 0xe800 0x00 0x00 + 0x04 0x8003 0x01 0x01 0xf000 0x00 0x00 0x01 + 0x8003 0x03 0x01 0xf000 0x00 0x00 0x02 0x8003 + 0x04 0x01 0xf000 0x00 0x00 0x03 0x8003 0x01 + 0x01 0xf000 0x00 0x00 0x04 0x8003 0x02 0x01 + 0xf800 0x00 0x00 0x01 0x8003 0x04 0x01 0xf800 + 0x00 0x00 0x02 0x8003 0x01 0x01 0xf800 0x00 + 0x00 0x03 0x8003 0x02 0x01 0xf800 0x00 0x00 + 0x04 0x8003 0x03 0x01>; + interrupt-map-mask = <0xf800 0x00 0x00 0x07>; + device_type = "pci"; + compatible = "fsl,mpc8540-pci"; + cell-index = <0x00>; + }; + + soc@fe0000000 { + bus-frequency = <0x00>; + ranges = <0x00 0x0f 0xe0000000 0x100000>; + #size-cells = <0x01>; + #address-cells = <0x01>; + compatible = "fsl,mpc8544-immr\0simple-bus"; + device_type = "soc"; + + power-off { + gpios = <0x8005 0x00 0x00>; + compatible = "gpio-poweroff"; + }; + + gpio@ff000 { + linux,phandle = <0x8005>; + phandle = <0x8005>; + gpio-controller; + #gpio-cells = <0x02>; + interrupt-parent = <0x8003>; + interrupts = <0x2f 0x02>; + reg = <0xff000 0x1000>; + compatible = "fsl,qoriq-gpio"; + }; + + msi@41600 { + linux,phandle = <0x8004>; + phandle = <0x8004>; + interrupts = <0xe0 0x00 0xe1 0x00 0xe2 0x00 0xe3 0x00 + 0xe4 0x00 0xe5 0x00 0xe6 0x00 0xe7 0x00>; + interrupt-parent = <0x8003>; + msi-available-ranges = <0x00 0x100>; + reg = <0x41600 0x200>; + compatible = "fsl,mpic-msi"; + }; + + global-utilities@e0000 { + fsl,has-rstcr; + reg = <0xe0000 0x1000>; + compatible = "fsl,mpc8544-guts"; + }; + + i2c@3000 { + interrupt-parent = <0x8003>; + interrupts = <0x2b 0x02>; + cell-index = <0x00>; + reg = <0x3000 0x14>; + compatible = "fsl-i2c"; + device_type = "i2c"; + + rtc@68 { + reg = <0x68>; + compatible = "pericom,pt7c4338"; + }; + }; + + serial@4500 { + interrupt-parent = <0x8003>; + interrupts = <0x2a 0x02>; + clock-frequency = <0x17d78400>; + cell-index = <0x00>; + reg = <0x4500 0x100>; + compatible = "ns16550"; + device_type = "serial"; + }; + + pic@40000 { + interrupt-controller; + linux,phandle = <0x8003>; + phandle = <0x8003>; + #interrupt-cells = <0x02>; + #address-cells = <0x00>; + reg = <0x40000 0x40000>; + compatible = "fsl,mpic"; + device_type = "open-pic"; + }; + }; + + aliases { + pci0 = "/pci@fe0008000"; + rtc = "i2c/rtc@68"; + i2c = "/soc@fe0000000/i2c@3000"; + serial0 = "/soc@fe0000000/serial@4500"; + }; + + cpus { + #size-cells = <0x00>; + #address-cells = <0x01>; + + PowerPC,8544@0 { + status = "okay"; + bus-frequency = <0x00>; + i-cache-size = <0x8000>; + d-cache-size = <0x8000>; + i-cache-line-size = <0x20>; + d-cache-line-size = <0x20>; + reg = <0x00>; + device_type = "cpu"; + timebase-frequency = <0x17d78400>; + clock-frequency = <0x17d78400>; + }; + }; + + chosen { + stdout-path = "/soc@fe0000000/serial@4500"; + linux,stdout-path = "/soc@fe0000000/serial@4500"; + bootargs = [00]; + }; + + memory { + reg = <0x00 0x00 0x00 0x8000000>; + device_type = "memory"; + }; +}; diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig index 55f646537b2..5bf3e8de37a 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
Add an empty file to prevent build errors when building with CONFIG_OF_SEPARATE enabled.
Unfortunately there are no build instructions in the U-Boot tree to enable a real file to be created.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
arch/arm/dts/Makefile | 2 ++ arch/arm/dts/highbank.dts | 14 ++++++++++++++ configs/highbank_defconfig | 2 +- 3 files changed, 17 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/highbank.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 68ddf5933ea..2d9bfbe8efa 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -862,6 +862,8 @@ dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \ dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-com.dtb \ imx7ulp-evk.dtb
+dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb + dtb-$(CONFIG_ARCH_IMX8) += \ fsl-imx8qm-apalis.dtb \ fsl-imx8qm-mek.dtb \ diff --git a/arch/arm/dts/highbank.dts b/arch/arm/dts/highbank.dts new file mode 100644 index 00000000000..29ac48f5788 --- /dev/null +++ b/arch/arm/dts/highbank.dts @@ -0,0 +1,14 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Dummy devicetre file for highbank board + * + * This is required to make the board build with CONFIG OF_SEPARATE + * There appears to be no in-tree documentation about this board at all. + * + * Copyright 2021 Google LLC + */ + +/dts-v1/; + +/ { +}; diff --git a/configs/highbank_defconfig b/configs/highbank_defconfig index 43a070e7233..b9d325d391a 100644 --- a/configs/highbank_defconfig +++ b/configs/highbank_defconfig @@ -7,6 +7,7 @@ CONFIG_SYS_TEXT_BASE=0x00008000 CONFIG_NR_DRAM_BANKS=2 CONFIG_ENV_SIZE=0x2000 CONFIG_SYS_MALLOC_LEN=0x80000 +CONFIG_DEFAULT_DEVICE_TREE="highbank" CONFIG_SYS_BOOTCOUNT_ADDR=0xfff3cf0c CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y CONFIG_DISTRO_DEFAULTS=y @@ -21,7 +22,6 @@ CONFIG_AUTOBOOT_KEYED_CTRLC=y # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_MISC_INIT_R=y # CONFIG_CMD_SETEXPR is not set -CONFIG_OF_BOARD=y CONFIG_ENV_IS_IN_NVRAM=y CONFIG_ENV_ADDR=0xFFF88000 CONFIG_SCSI_AHCI=y
This should not be a separate option from OF_SEPARATE. It is a run-time option to override the devicetree, even if present.
Move the option out of the choice.
Disable BINMAN_FDT for a few boards which don't actually use it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
configs/qemu-ppce500_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 2 ++ configs/qemu-riscv64_spl_defconfig | 1 + dts/Kconfig | 9 +++++---- 4 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig index 5bf3e8de37a..66411f73a11 100644 --- a/configs/qemu-ppce500_defconfig +++ b/configs/qemu-ppce500_defconfig @@ -54,4 +54,5 @@ CONFIG_VIRTIO_PCI=y CONFIG_VIRTIO_NET=y CONFIG_VIRTIO_BLK=y CONFIG_ADDR_MAP=y +# CONFIG_BINMAN_FDT is not set CONFIG_PANIC_HANG=y diff --git a/configs/qemu-riscv32_spl_defconfig b/configs/qemu-riscv32_spl_defconfig index 3909c9a15ad..4621afb1a87 100644 --- a/configs/qemu-riscv32_spl_defconfig +++ b/configs/qemu-riscv32_spl_defconfig @@ -6,6 +6,7 @@ CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32" CONFIG_SPL=y CONFIG_TARGET_QEMU_VIRT=y CONFIG_RISCV_SMODE=y +# CONFIG_OF_BOARD_FIXUP is not set CONFIG_DISTRO_DEFAULTS=y CONFIG_SYS_LOAD_ADDR=0x80200000 CONFIG_FIT=y @@ -18,3 +19,4 @@ CONFIG_OF_BOARD=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYSRESET_SBI=y +# CONFIG_BINMAN_FDT is not set diff --git a/configs/qemu-riscv64_spl_defconfig b/configs/qemu-riscv64_spl_defconfig index 34d88da41b0..6f8ff91df9e 100644 --- a/configs/qemu-riscv64_spl_defconfig +++ b/configs/qemu-riscv64_spl_defconfig @@ -19,3 +19,4 @@ CONFIG_OF_BOARD=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYSRESET_SBI=y +# CONFIG_BINMAN_FDT is not set diff --git a/dts/Kconfig b/dts/Kconfig index 99a7a8b0338..97ace4ec39c 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -100,7 +100,6 @@ choice
config OF_SEPARATE bool "Separate DTB for DT control" - depends on !SANDBOX help If this option is enabled, the device tree will be built and placed as a separate u-boot.dtb file alongside the U-Boot image. @@ -113,14 +112,16 @@ config OF_EMBED and development only and is not recommended for production devices. Boards in the mainline U-Boot tree should not use it.
+endchoice + config OF_BOARD bool "Provided by the board (e.g a previous loader) at runtime" help If this option is enabled, the device tree will be provided by - the board at runtime if the board supports it, instead of being - bundled with the image. + the board at runtime if the board supports it. The device tree bundled + with the image (if any) will be overridden / ignored.
-endchoice + A device tree file must be provided in the tree.
config DEFAULT_DEVICE_TREE string "Default Device Tree for DT control"
This was added as a hack to work around not having an in-tree devicetree. Now that this is fixed it is not needed.
Drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
Makefile | 3 +-- dts/Kconfig | 18 ------------------ tools/binman/binman.rst | 20 -------------------- 3 files changed, 1 insertion(+), 40 deletions(-)
diff --git a/Makefile b/Makefile index c0ea933cb63..09a5cea8cb8 100644 --- a/Makefile +++ b/Makefile @@ -943,7 +943,6 @@ endif endif INPUTS-$(CONFIG_TPL) += tpl/u-boot-tpl.bin INPUTS-$(CONFIG_OF_SEPARATE) += u-boot.dtb -INPUTS-$(CONFIG_BINMAN_STANDALONE_FDT) += u-boot.dtb ifeq ($(CONFIG_SPL_FRAMEWORK),y) INPUTS-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img endif @@ -1407,7 +1406,7 @@ u-boot-lzma.img: u-boot.bin.lzma FORCE
u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \ $(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin \ - $(if $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb) \ + $(if $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX),dts/dt.dtb) \ ,$(UBOOT_BIN)) FORCE $(call if_changed,mkimage) $(BOARD_SIZE_CHECK) diff --git a/dts/Kconfig b/dts/Kconfig index 97ace4ec39c..20ddc534a61 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -16,24 +16,6 @@ config BINMAN bool select DTOC
-config BINMAN_STANDALONE_FDT - bool - depends on BINMAN - default y if OF_BOARD - help - This option tells U-Boot build system that a standalone device tree - source is explicitly required when using binman to package U-Boot. - - This is not necessary in a common scenario where a device tree source - that contains the binman node is provided in the arch/<arch>/dts - directory for a specific board. Such device tree sources are built for - OF_SEPARATE or OF_EMBED. However for a scenario like the board device - tree blob is not provided in the U-Boot build tree, but fed to U-Boot - in the runtime, e.g.: in the OF_BOARD case that it is passed by - a prior stage bootloader. For such scenario, a standalone device tree - blob containing binman node to describe how to package U-Boot should - be provided explicitly. - menu "Device Tree Control" depends on SUPPORT_OF_CONTROL
diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst index 614df541c5a..f90dd3a5e5d 100644 --- a/tools/binman/binman.rst +++ b/tools/binman/binman.rst @@ -232,26 +232,6 @@ You can use other, more specific CONFIG options - see 'Automatic .dtsi inclusion' below.
-Using binman with OF_BOARD --------------------------------------------- - -Normally binman is used with a board configured with OF_SEPARATE or OF_EMBED. -This is a typical scenario where a device tree source that contains the binman -node is provided in the arch/<arch>/dts directory for a specific board. - -However for a board configured with OF_BOARD, no device tree blob is provided -in the U-Boot build phase hence the binman node information is not available. -In order to support such use case, a new Kconfig option BINMAN_STANDALONE_FDT -is introduced, to tell the build system that a standalone device tree blob -containing binman node is explicitly required. - -Note there is a Kconfig option BINMAN_FDT which enables U-Boot run time to -access information about binman entries, stored in the device tree in a binman -node. Generally speaking, this option makes sense for OF_SEPARATE or OF_EMBED. -For the other OF_CONTROL methods, it's quite possible binman node is not -available as binman is invoked during the build phase, thus this option is not -turned on by default for these OF_CONTROL methods. - Access to binman entry offsets at run time (symbols) ----------------------------------------------------
Since OF_BOARD has been corrected to be a run-time option, we can drop the historical info from this documentation.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
doc/develop/devicetree/dt_update.rst | 74 +++------------------------- 1 file changed, 8 insertions(+), 66 deletions(-)
diff --git a/doc/develop/devicetree/dt_update.rst b/doc/develop/devicetree/dt_update.rst index 3d4902e3592..4a1976f5b4b 100644 --- a/doc/develop/devicetree/dt_update.rst +++ b/doc/develop/devicetree/dt_update.rst @@ -32,66 +32,6 @@ that board on suitable hardware (or emulation). This is specified using the `CONFIG DEFAULT_DEVICE_TREE` option.
-Current situation (October 2021) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty, -e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an enormous -amount of confusion and some wasted effort. This was not intended. Support for -an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. - -Some of the problems created are: - -- It is not obvious that the devicetree is coming from another project - -- There is no way to see even a sample devicetree for these platform in U-Boot, - so it is hard to know what is going on, e.g. which devices are typically - present - -- The other project may not provide a way to support U-Boot's requirements for - devicetree, such as the /config node. Note: On the U-Boot mailing linst, this - was only discovered after weeks of discussion and confusion - -- For QEMU specifically, consulting two QEMU source files is required, for which - there are no references in U-Boot documentation. The code is generating a - devicetree, but it is not clear what controls affect this generation. - -Specifically on the changes in U-Bootm `CONFIG_OF_BOARD` was added in -rpi_patch_ for Raspberry Pi, which does have an in-tree devicetree, but this -feature has since been used for boards that don't - -Once this bug is fixed, CONFIG_OF_BOARD will override (at runtime) the -evicetree suppled with U-Boot, but will otherwise use CONFIG_OF_SEPARATE for the -in-tree build. So these two will become options, moving out of the 'choice' in -`dts/Kconfig`. - -This means that there is a basic devicetree build in the U-Boot tree, for -build-testing, consistency and documentation purposes, but at runtime U-Boot can -accept its devicetree from another source. The in-tree devicetree may contain -U-Boot-specific features (in u-boot*.dtsi files) and this may prove useful for -the other project, so it can ensure that U-Boot functions correctly and supports -all its expected features. - -To be clear, while U-Boot has its own copy of the devicetree source for each -board, this must match the Linux source, perhaps with some u-boot.dtsi -additions. The intent here is not to create a separate binding, just to provide -a representative devicetree in U-Boot. - -Offending boards are: - -- rpi_4 and rpi_4_32b (other rpi boards do have an in-tree devicetree) -- qemu_arm64 -- qemu_arm -- qemu-ppce500 -- qemu-riscv32 -- qemu-riscv32_smode -- qemu-riscv64 -- qemu-riscv64_smode - -All of these need to have a devicetree added in-tree. This is targeted to be -fixed in the 2022.01 release. - - Building the devicetree -----------------------
@@ -205,15 +145,18 @@ Operating System. Also, while Linux has a (sometimes extremely long) command line, U-Boot does not support this. The devicetree provides a more structured approach in any case.
+Note: Dicussions on adding a binding for this to the Linux devicetree bindings +are ongoing as of October 2021. +
Devicetree in another project -----------------------------
-In some cases U-Boot receive its devicetree at runtime from a program that calls -it. For example ARM's Trusted Firmware A (`TF-A`_) may have a devicetree that it -passes to U-Boot. This overrides any devicetree build by U-Boot. When packaging -the firmware, the U-Boot devicetree may in fact be left out if it can be -guaranteed that it will receive one from another project. +In some cases U-Boot receives its devicetree at runtime from a program that +calls it. For example ARM's Trusted Firmware A (`TF-A`_) may have a devicetree +that it passes to U-Boot. This overrides any devicetree build by U-Boot. When +packaging the firmware, the U-Boot devicetree may in fact be left out if it can +be guaranteed that it will receive one from another project.
In this case, the devicetree in the other project must track U-Boot's use of device tree, for the following reasons: @@ -547,7 +490,6 @@ Overall, adding a second devicetree would create enormous confusion and complexity. It seems a lot cheaper to solve this by a change of attitude.
-.. _rpi_patch: https://patchwork.ozlabs.org/project/uboot/patch/20170402082520.32546-1-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
This logic is a bit convoluted for one function. Move the mulit-FIT part into its own function.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
lib/fdtdec.c | 62 ++++++++++++++++++++++++++++++++-------------------- 1 file changed, 38 insertions(+), 24 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 688741108c7..58ea8f70cfe 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -1591,13 +1591,46 @@ __weak int fdtdec_board_setup(const void *fdt_blob) return 0; }
+/** + * setup_multi_dtb_fit() - locate the correct dtb from a FIT + * + * This supports the CONFIG_MULTI_DTB_FIT feature, looking for the dtb in a + * supplied FIT + * + * It accepts the current value of gd->fdt_blob, which points to the FIT, then + * updates that gd->fdt_blob, to point to the chosen dtb so that U-Boot uses the + * correct one + */ +static void setup_multi_dtb_fit(void) +{ +# if CONFIG_IS_ENABLED(MULTI_DTB_FIT) + void *blob; + + /* + * Try and uncompress the blob. + * Unfortunately there is no way to know how big the input blob really + * is. So let us set the maximum input size arbitrarily high. 16MB + * ought to be more than enough for packed DTBs. + */ + if (uncompress_blob(gd->fdt_blob, 0x1000000, &blob) == 0) + gd->fdt_blob = blob; + + /* + * Check if blob is a FIT images containings DTBs. + * If so, pick the most relevant + */ + blob = locate_dtb_in_fit(gd->fdt_blob); + if (blob) { + gd->multi_dtb_fit = gd->fdt_blob; + gd->fdt_blob = blob; + } +#endif /* # MULTI_DTB_FIT */ +} + int fdtdec_setup(void) { int ret; #if CONFIG_IS_ENABLED(OF_CONTROL) -# if CONFIG_IS_ENABLED(MULTI_DTB_FIT) - void *fdt_blob; -# endif # ifdef CONFIG_OF_EMBED /* Get a pointer to the FDT */ # ifdef CONFIG_SPL_BUILD @@ -1616,27 +1649,8 @@ int fdtdec_setup(void) (unsigned long)map_to_sysmem(gd->fdt_blob)), 0); # endif
-# if CONFIG_IS_ENABLED(MULTI_DTB_FIT) - /* - * Try and uncompress the blob. - * Unfortunately there is no way to know how big the input blob really - * is. So let us set the maximum input size arbitrarily high. 16MB - * ought to be more than enough for packed DTBs. - */ - if (uncompress_blob(gd->fdt_blob, 0x1000000, &fdt_blob) == 0) - gd->fdt_blob = fdt_blob; - - /* - * Check if blob is a FIT images containings DTBs. - * If so, pick the most relevant - */ - fdt_blob = locate_dtb_in_fit(gd->fdt_blob); - if (fdt_blob) { - gd->multi_dtb_fit = gd->fdt_blob; - gd->fdt_blob = fdt_blob; - } - -# endif + if (CONFIG_IS_ENABLED(MULTI_DTB_FIT)) + setup_multi_dtb_fit(); #endif
ret = fdtdec_prepare_fdt();
Hi Simon,
Since those patch series are too long and borderline unreviewable, I'd much rather split them on different patchsets (i.e one with cleanups and one with the actual proposal).
On Mon, Oct 25, 2021 at 06:23:37PM -0600, Simon Glass wrote:
This logic is a bit convoluted for one function. Move the mulit-FIT part into its own function.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v1)
lib/fdtdec.c | 62 ++++++++++++++++++++++++++++++++-------------------- 1 file changed, 38 insertions(+), 24 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 688741108c7..58ea8f70cfe 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -1591,13 +1591,46 @@ __weak int fdtdec_board_setup(const void *fdt_blob) return 0; }
+/**
- setup_multi_dtb_fit() - locate the correct dtb from a FIT
- This supports the CONFIG_MULTI_DTB_FIT feature, looking for the dtb in a
- supplied FIT
- It accepts the current value of gd->fdt_blob, which points to the FIT, then
- updates that gd->fdt_blob, to point to the chosen dtb so that U-Boot uses the
- correct one
- */
+static void setup_multi_dtb_fit(void) +{ +# if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
- void *blob;
- /*
* Try and uncompress the blob.* Unfortunately there is no way to know how big the input blob really* is. So let us set the maximum input size arbitrarily high. 16MB* ought to be more than enough for packed DTBs.*/- if (uncompress_blob(gd->fdt_blob, 0x1000000, &blob) == 0)
gd->fdt_blob = blob;- /*
* Check if blob is a FIT images containings DTBs.* If so, pick the most relevant*/- blob = locate_dtb_in_fit(gd->fdt_blob);
- if (blob) {
gd->multi_dtb_fit = gd->fdt_blob;gd->fdt_blob = blob;- }
+#endif /* # MULTI_DTB_FIT */ +}
int fdtdec_setup(void) { int ret; #if CONFIG_IS_ENABLED(OF_CONTROL) -# if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
- void *fdt_blob;
-# endif # ifdef CONFIG_OF_EMBED /* Get a pointer to the FDT */ # ifdef CONFIG_SPL_BUILD @@ -1616,27 +1649,8 @@ int fdtdec_setup(void) (unsigned long)map_to_sysmem(gd->fdt_blob)), 0); # endif
-# if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
- /*
* Try and uncompress the blob.* Unfortunately there is no way to know how big the input blob really* is. So let us set the maximum input size arbitrarily high. 16MB* ought to be more than enough for packed DTBs.*/- if (uncompress_blob(gd->fdt_blob, 0x1000000, &fdt_blob) == 0)
gd->fdt_blob = fdt_blob;- /*
* Check if blob is a FIT images containings DTBs.* If so, pick the most relevant*/- fdt_blob = locate_dtb_in_fit(gd->fdt_blob);
- if (fdt_blob) {
gd->multi_dtb_fit = gd->fdt_blob;gd->fdt_blob = fdt_blob;- }
-# endif
- if (CONFIG_IS_ENABLED(MULTI_DTB_FIT))
setup_multi_dtb_fit();#endif
ret = fdtdec_prepare_fdt();
2.33.0.1079.g6e70778dc9-goog
Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org
Refactor the code to drop the #ifdefs for this feature.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
dts/Kconfig | 1 - include/asm-generic/global_data.h | 8 ++++++++ lib/fdtdec.c | 31 +++++++++++-------------------- 3 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/dts/Kconfig b/dts/Kconfig index 20ddc534a61..0f7e3ad7db7 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -176,7 +176,6 @@ endchoice
config MULTI_DTB_FIT_UNCOMPRESS_SZ hex "Size of memory reserved to uncompress the DTBs" - depends on (MULTI_DTB_FIT_GZIP || MULTI_DTB_FIT_LZO) default 0x8000 help This is the size of this area where the DTBs are uncompressed. diff --git a/include/asm-generic/global_data.h b/include/asm-generic/global_data.h index 16fd305a65c..99daa20c765 100644 --- a/include/asm-generic/global_data.h +++ b/include/asm-generic/global_data.h @@ -512,6 +512,14 @@ static_assert(sizeof(struct global_data) == GD_SIZE); #define gd_acpi_ctx() NULL #endif
+#if CONFIG_IS_ENABLED(MULTI_DTB_FIT) +#define gd_multi_dtb_fit() gd->multi_dtb_fit +#define gd_set_multi_dtb_fit(_dtb) gd->multi_dtb_fit = _dtb +#else +#define gd_multi_dtb_fit() NULL +#define gd_set_multi_dtb_fit(_dtb) +#endif + /** * enum gd_flags - global data flags * diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 58ea8f70cfe..15a990e5b98 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -1146,11 +1146,10 @@ int fdtdec_setup_mem_size_base_lowest(void) return 0; }
-#if CONFIG_IS_ENABLED(MULTI_DTB_FIT) -# if CONFIG_IS_ENABLED(MULTI_DTB_FIT_GZIP) ||\ - CONFIG_IS_ENABLED(MULTI_DTB_FIT_LZO) static int uncompress_blob(const void *src, ulong sz_src, void **dstp) { +#if CONFIG_IS_ENABLED(MULTI_DTB_FIT_GZIP) ||\ + CONFIG_IS_ENABLED(MULTI_DTB_FIT_LZO) size_t sz_out = CONFIG_VAL(MULTI_DTB_FIT_UNCOMPRESS_SZ); bool gzip = 0, lzo = 0; ulong sz_in = sz_src; @@ -1175,11 +1174,11 @@ static int uncompress_blob(const void *src, ulong sz_src, void **dstp) return -ENOMEM; } } else { -# if CONFIG_IS_ENABLED(MULTI_DTB_FIT_USER_DEFINED_AREA) +# if CONFIG_IS_ENABLED(MULTI_DTB_FIT_USER_DEFINED_AREA) dst = (void *)CONFIG_VAL(MULTI_DTB_FIT_USER_DEF_ADDR); -# else +# else return -ENOTSUPP; -# endif +# endif }
if (CONFIG_IS_ENABLED(GZIP) && gzip) @@ -1197,16 +1196,12 @@ static int uncompress_blob(const void *src, ulong sz_src, void **dstp) return -EBADMSG; } *dstp = dst; - return 0; -} -# else -static int uncompress_blob(const void *src, ulong sz_src, void **dstp) -{ +#else + *dstp = (void *)src; *dstp = (void *)src; +#endif return 0; } -# endif -#endif
#if defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE) /* @@ -1603,7 +1598,6 @@ __weak int fdtdec_board_setup(const void *fdt_blob) */ static void setup_multi_dtb_fit(void) { -# if CONFIG_IS_ENABLED(MULTI_DTB_FIT) void *blob;
/* @@ -1621,10 +1615,9 @@ static void setup_multi_dtb_fit(void) */ blob = locate_dtb_in_fit(gd->fdt_blob); if (blob) { - gd->multi_dtb_fit = gd->fdt_blob; + gd_set_multi_dtb_fit(gd->fdt_blob); gd->fdt_blob = blob; } -#endif /* # MULTI_DTB_FIT */ }
int fdtdec_setup(void) @@ -1659,7 +1652,6 @@ int fdtdec_setup(void) return ret; }
-#if CONFIG_IS_ENABLED(MULTI_DTB_FIT) int fdtdec_resetup(int *rescan) { void *fdt_blob; @@ -1670,8 +1662,8 @@ int fdtdec_resetup(int *rescan) * FIT image stillpresent there. Save the time and space * required to uncompress it again. */ - if (gd->multi_dtb_fit) { - fdt_blob = locate_dtb_in_fit(gd->multi_dtb_fit); + if (gd_multi_dtb_fit()) { + fdt_blob = locate_dtb_in_fit(gd_multi_dtb_fit());
if (fdt_blob == gd->fdt_blob) { /* @@ -1695,7 +1687,6 @@ int fdtdec_resetup(int *rescan) *rescan = 0; return 0; } -#endif
int fdtdec_decode_ram_size(const void *blob, const char *area, int board_id, phys_addr_t *basep, phys_size_t *sizep,
Hi Simon,
likewise, since this is a pretty big patchset split it of in refactoring/new code patchsets so we can actually review it.
Thanks /Ilias On Mon, Oct 25, 2021 at 06:23:38PM -0600, Simon Glass wrote:
Refactor the code to drop the #ifdefs for this feature.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v1)
dts/Kconfig | 1 - include/asm-generic/global_data.h | 8 ++++++++ lib/fdtdec.c | 31 +++++++++++-------------------- 3 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/dts/Kconfig b/dts/Kconfig index 20ddc534a61..0f7e3ad7db7 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -176,7 +176,6 @@ endchoice
config MULTI_DTB_FIT_UNCOMPRESS_SZ hex "Size of memory reserved to uncompress the DTBs"
- depends on (MULTI_DTB_FIT_GZIP || MULTI_DTB_FIT_LZO) default 0x8000 help This is the size of this area where the DTBs are uncompressed.
diff --git a/include/asm-generic/global_data.h b/include/asm-generic/global_data.h index 16fd305a65c..99daa20c765 100644 --- a/include/asm-generic/global_data.h +++ b/include/asm-generic/global_data.h @@ -512,6 +512,14 @@ static_assert(sizeof(struct global_data) == GD_SIZE); #define gd_acpi_ctx() NULL #endif
+#if CONFIG_IS_ENABLED(MULTI_DTB_FIT) +#define gd_multi_dtb_fit() gd->multi_dtb_fit +#define gd_set_multi_dtb_fit(_dtb) gd->multi_dtb_fit = _dtb +#else +#define gd_multi_dtb_fit() NULL +#define gd_set_multi_dtb_fit(_dtb) +#endif
/**
- enum gd_flags - global data flags
diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 58ea8f70cfe..15a990e5b98 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -1146,11 +1146,10 @@ int fdtdec_setup_mem_size_base_lowest(void) return 0; }
-#if CONFIG_IS_ENABLED(MULTI_DTB_FIT) -# if CONFIG_IS_ENABLED(MULTI_DTB_FIT_GZIP) ||\
- CONFIG_IS_ENABLED(MULTI_DTB_FIT_LZO)
static int uncompress_blob(const void *src, ulong sz_src, void **dstp) { +#if CONFIG_IS_ENABLED(MULTI_DTB_FIT_GZIP) ||\
- CONFIG_IS_ENABLED(MULTI_DTB_FIT_LZO) size_t sz_out = CONFIG_VAL(MULTI_DTB_FIT_UNCOMPRESS_SZ); bool gzip = 0, lzo = 0; ulong sz_in = sz_src;
@@ -1175,11 +1174,11 @@ static int uncompress_blob(const void *src, ulong sz_src, void **dstp) return -ENOMEM; } } else { -# if CONFIG_IS_ENABLED(MULTI_DTB_FIT_USER_DEFINED_AREA) +# if CONFIG_IS_ENABLED(MULTI_DTB_FIT_USER_DEFINED_AREA) dst = (void *)CONFIG_VAL(MULTI_DTB_FIT_USER_DEF_ADDR); -# else +# else return -ENOTSUPP; -# endif +# endif }
if (CONFIG_IS_ENABLED(GZIP) && gzip) @@ -1197,16 +1196,12 @@ static int uncompress_blob(const void *src, ulong sz_src, void **dstp) return -EBADMSG; } *dstp = dst;
- return 0;
-} -# else -static int uncompress_blob(const void *src, ulong sz_src, void **dstp) -{ +#else
- *dstp = (void *)src; *dstp = (void *)src;
+#endif return 0; } -# endif -#endif
#if defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE) /* @@ -1603,7 +1598,6 @@ __weak int fdtdec_board_setup(const void *fdt_blob) */ static void setup_multi_dtb_fit(void) { -# if CONFIG_IS_ENABLED(MULTI_DTB_FIT) void *blob;
/* @@ -1621,10 +1615,9 @@ static void setup_multi_dtb_fit(void) */ blob = locate_dtb_in_fit(gd->fdt_blob); if (blob) {
gd->multi_dtb_fit = gd->fdt_blob;
gd_set_multi_dtb_fit(gd->fdt_blob);-#endif /* # MULTI_DTB_FIT */ }
int fdtdec_setup(void) @@ -1659,7 +1652,6 @@ int fdtdec_setup(void) return ret; }
-#if CONFIG_IS_ENABLED(MULTI_DTB_FIT) int fdtdec_resetup(int *rescan) { void *fdt_blob; @@ -1670,8 +1662,8 @@ int fdtdec_resetup(int *rescan) * FIT image stillpresent there. Save the time and space * required to uncompress it again. */
- if (gd->multi_dtb_fit) {
fdt_blob = locate_dtb_in_fit(gd->multi_dtb_fit);
if (gd_multi_dtb_fit()) {
fdt_blob = locate_dtb_in_fit(gd_multi_dtb_fit());if (fdt_blob == gd->fdt_blob) { /*
@@ -1695,7 +1687,6 @@ int fdtdec_resetup(int *rescan) *rescan = 0; return 0; } -#endif
int fdtdec_decode_ram_size(const void *blob, const char *area, int board_id, phys_addr_t *basep, phys_size_t *sizep, -- 2.33.0.1079.g6e70778dc9-goog
Move this to the header file to clean up the C code.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
include/fdtdec.h | 14 ++++++++++++++ lib/fdtdec.c | 6 +----- 2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h index 239814228d7..386f6611294 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -111,6 +111,20 @@ struct fdt_pci_addr { extern u8 __dtb_dt_begin[]; /* embedded device tree blob */ extern u8 __dtb_dt_spl_begin[]; /* embedded device tree blob for SPL/TPL */
+/* Get a pointer to the embedded devicetree, if there is one, else NULL */ +static inline u8 *dtb_dt_embedded(void) +{ +#ifdef CONFIG_OF_EMBED +# ifdef CONFIG_SPL_BUILD + return __dtb_dt_spl_begin; +# else + return __dtb_dt_begin; +# endif +#else + return NULL; +#endif +} + /** * Compute the size of a resource. * diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 15a990e5b98..69877baaaf5 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -1626,11 +1626,7 @@ int fdtdec_setup(void) #if CONFIG_IS_ENABLED(OF_CONTROL) # ifdef CONFIG_OF_EMBED /* Get a pointer to the FDT */ -# ifdef CONFIG_SPL_BUILD - gd->fdt_blob = __dtb_dt_spl_begin; -# else - gd->fdt_blob = __dtb_dt_begin; -# endif + gd->fdt_blob = dtb_dt_embedded(); # elif defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE) /* Allow the board to override the fdt address. */ gd->fdt_blob = board_fdt_blob_setup();
This serves no purpose. Drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
lib/fdtdec.c | 2 -- 1 file changed, 2 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 69877baaaf5..5a4cf440fa7 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -1203,7 +1203,6 @@ static int uncompress_blob(const void *src, ulong sz_src, void **dstp) return 0; }
-#if defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE) /* * For CONFIG_OF_SEPARATE, the board may optionally implement this to * provide and/or fixup the fdt. @@ -1223,7 +1222,6 @@ __weak void *board_fdt_blob_setup(void) #endif return fdt_blob; } -#endif
int fdtdec_set_ethernet_mac_address(void *fdt, const u8 *mac, size_t size) {
We only have two choices for obtaining the devicetree. Simplify the code to make that clear.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
lib/fdtdec.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 0973cf0690b..067c27d0aa3 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -1621,13 +1621,13 @@ static void setup_multi_dtb_fit(void) int fdtdec_setup(void) { int ret; -#ifdef CONFIG_OF_EMBED - /* Get a pointer to the FDT */ - gd->fdt_blob = dtb_dt_embedded(); -#elif defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE) - /* Allow the board to override the fdt address. */ - gd->fdt_blob = board_fdt_blob_setup(); -#endif + + /* The devicetree is typically appended to U-Boot */ + if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD)) + gd->fdt_blob = board_fdt_blob_setup(); + else /* embed dtb in ELF file for testing / development */ + gd->fdt_blob = dtb_dt_embedded(); + if (!IS_ENABLED(CONFIG_SPL_BUILD)) { /* Allow the early environment to override the fdt address */ gd->fdt_blob = map_sysmem(env_get_ulong("fdtcontroladdr", 16,
At present this override function is called even when OF_BOARD Is not enabled. This makes it impossible to disable this feature and in fact makes the OF_BOARD option useless.
Reinstate its intended purpose, so that it is possible to switch between the appended devicetree and one provided by the board's custom function.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v5: - Add new patches to clean up fdtdec_setup() and surrounds
include/fdtdec.h | 7 +++++-- lib/fdtdec.c | 17 +++++++++++------ 2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h index 386f6611294..b2faa84008e 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -1170,8 +1170,11 @@ int fdtdec_resetup(int *rescan);
/** * Board-specific FDT initialization. Returns the address to a device tree blob. - * Called when CONFIG_OF_BOARD is defined, or if CONFIG_OF_SEPARATE is defined - * and the board implements it. + * Called when CONFIG_OF_BOARD is defined. + * + * The existing devicetree is available at gd->fdt_blob + * + * @returns new devicetree blob pointer */ void *board_fdt_blob_setup(void);
diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 067c27d0aa3..da36dffec62 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -1203,11 +1203,12 @@ static int uncompress_blob(const void *src, ulong sz_src, void **dstp) return 0; }
-/* - * For CONFIG_OF_SEPARATE, the board may optionally implement this to - * provide and/or fixup the fdt. +/** + * fdt_find_separate() - Find a devicetree at the end of the image + * + * @return pointer to FDT blob */ -__weak void *board_fdt_blob_setup(void) +static void *fdt_find_separate(void) { void *fdt_blob = NULL; #ifdef CONFIG_SPL_BUILD @@ -1623,11 +1624,15 @@ int fdtdec_setup(void) int ret;
/* The devicetree is typically appended to U-Boot */ - if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD)) - gd->fdt_blob = board_fdt_blob_setup(); + if (IS_ENABLED(CONFIG_OF_SEPARATE)) + gd->fdt_blob = fdt_find_separate(); else /* embed dtb in ELF file for testing / development */ gd->fdt_blob = dtb_dt_embedded();
+ /* Allow the board to override the fdt address. */ + if (IS_ENABLED(CONFIG_OF_BOARD)) + gd->fdt_blob = board_fdt_blob_setup(); + if (!IS_ENABLED(CONFIG_SPL_BUILD)) { /* Allow the early environment to override the fdt address */ gd->fdt_blob = map_sysmem(env_get_ulong("fdtcontroladdr", 16,
Hi Simon,
As I said here [1], this is moving on an entirely different direction I had in mind. I'd much prefer starting the discussions for a solution that allows us to scale. FWIW I think the current code is still not clean for my taste. Commit 3b595da441cf ("fdtdec: allow board to provide fdt for CONFIG_OF_SEPARATE") allowed this function to be used regardless of the config options. IMHO we should have 2 clear options: - U-Boot provides the DTB - It's somehow passed over to U-Boot
On Mon, Oct 25, 2021 at 06:23:44PM -0600, Simon Glass wrote:
At present this override function is called even when OF_BOARD Is not enabled. This makes it impossible to disable this feature and in fact makes the OF_BOARD option useless.
Reinstate its intended purpose, so that it is possible to switch between the appended devicetree and one provided by the board's custom function.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v5:
- Add new patches to clean up fdtdec_setup() and surrounds
include/fdtdec.h | 7 +++++-- lib/fdtdec.c | 17 +++++++++++------ 2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h index 386f6611294..b2faa84008e 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -1170,8 +1170,11 @@ int fdtdec_resetup(int *rescan);
/**
- Board-specific FDT initialization. Returns the address to a device tree blob.
- Called when CONFIG_OF_BOARD is defined, or if CONFIG_OF_SEPARATE is defined
- and the board implements it.
- Called when CONFIG_OF_BOARD is defined.
- The existing devicetree is available at gd->fdt_blob
*/
- @returns new devicetree blob pointer
void *board_fdt_blob_setup(void);
diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 067c27d0aa3..da36dffec62 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -1203,11 +1203,12 @@ static int uncompress_blob(const void *src, ulong sz_src, void **dstp) return 0; }
-/*
- For CONFIG_OF_SEPARATE, the board may optionally implement this to
- provide and/or fixup the fdt.
+/**
- fdt_find_separate() - Find a devicetree at the end of the image
*/
- @return pointer to FDT blob
-__weak void *board_fdt_blob_setup(void) +static void *fdt_find_separate(void) { void *fdt_blob = NULL; #ifdef CONFIG_SPL_BUILD @@ -1623,11 +1624,15 @@ int fdtdec_setup(void) int ret;
/* The devicetree is typically appended to U-Boot */
- if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD))
gd->fdt_blob = board_fdt_blob_setup();
if (IS_ENABLED(CONFIG_OF_SEPARATE))
gd->fdt_blob = fdt_find_separate();else /* embed dtb in ELF file for testing / development */ gd->fdt_blob = dtb_dt_embedded();
/* Allow the board to override the fdt address. */
if (IS_ENABLED(CONFIG_OF_BOARD))
gd->fdt_blob = board_fdt_blob_setup();if (!IS_ENABLED(CONFIG_SPL_BUILD)) { /* Allow the early environment to override the fdt address */ gd->fdt_blob = map_sysmem(env_get_ulong("fdtcontroladdr", 16,
-- 2.33.0.1079.g6e70778dc9-goog
[1] https://lore.kernel.org/u-boot/YXekTkeL73NM0UOU@apalos.home/
Regards /Ilias
Hi Ilias,
On Tue, 26 Oct 2021 at 07:56, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
As I said here [1], this is moving on an entirely different direction I had in mind. I'd much prefer starting the discussions for a solution that allows us to scale.
I am missing the point here. Is there something in the plans that I don't know about?
FWIW I think the current code is still not clean for my taste. Commit 3b595da441cf ("fdtdec: allow board to provide fdt for CONFIG_OF_SEPARATE") allowed this function to be used regardless of the config options. IMHO we should have 2 clear options:
- U-Boot provides the DTB
Supported with: OF_SEPARATE
- It's somehow passed over to U-Boot
Supported with: OF_SEPARATE + OF_BOARD
I actually hit this problem with my qemu testing, in that it is actually not possible to use U-Boot's devicetree without hacking the code. We need to be able to select this feature explicitly, or turn it off, at least for development.
Regards, Simon
On Mon, Oct 25, 2021 at 06:23:44PM -0600, Simon Glass wrote:
At present this override function is called even when OF_BOARD Is not enabled. This makes it impossible to disable this feature and in fact makes the OF_BOARD option useless.
Reinstate its intended purpose, so that it is possible to switch between the appended devicetree and one provided by the board's custom function.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v5:
- Add new patches to clean up fdtdec_setup() and surrounds
include/fdtdec.h | 7 +++++-- lib/fdtdec.c | 17 +++++++++++------ 2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h index 386f6611294..b2faa84008e 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -1170,8 +1170,11 @@ int fdtdec_resetup(int *rescan);
/**
- Board-specific FDT initialization. Returns the address to a device tree blob.
- Called when CONFIG_OF_BOARD is defined, or if CONFIG_OF_SEPARATE is defined
- and the board implements it.
- Called when CONFIG_OF_BOARD is defined.
- The existing devicetree is available at gd->fdt_blob
*/
- @returns new devicetree blob pointer
void *board_fdt_blob_setup(void);
diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 067c27d0aa3..da36dffec62 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -1203,11 +1203,12 @@ static int uncompress_blob(const void *src, ulong sz_src, void **dstp) return 0; }
-/*
- For CONFIG_OF_SEPARATE, the board may optionally implement this to
- provide and/or fixup the fdt.
+/**
- fdt_find_separate() - Find a devicetree at the end of the image
*/
- @return pointer to FDT blob
-__weak void *board_fdt_blob_setup(void) +static void *fdt_find_separate(void) { void *fdt_blob = NULL; #ifdef CONFIG_SPL_BUILD @@ -1623,11 +1624,15 @@ int fdtdec_setup(void) int ret;
/* The devicetree is typically appended to U-Boot */
if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD))gd->fdt_blob = board_fdt_blob_setup();
if (IS_ENABLED(CONFIG_OF_SEPARATE))gd->fdt_blob = fdt_find_separate(); else /* embed dtb in ELF file for testing / development */ gd->fdt_blob = dtb_dt_embedded();/* Allow the board to override the fdt address. */if (IS_ENABLED(CONFIG_OF_BOARD))gd->fdt_blob = board_fdt_blob_setup();if (!IS_ENABLED(CONFIG_SPL_BUILD)) { /* Allow the early environment to override the fdt address */ gd->fdt_blob = map_sysmem(env_get_ulong("fdtcontroladdr", 16,-- 2.33.0.1079.g6e70778dc9-goog
[1] https://lore.kernel.org/u-boot/YXekTkeL73NM0UOU@apalos.home/
Regards /Ilias
Hi Simon,
On Tue, 26 Oct 2021 at 18:27, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Tue, 26 Oct 2021 at 07:56, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
As I said here [1], this is moving on an entirely different direction I had in mind. I'd much prefer starting the discussions for a solution that allows us to scale.
I am missing the point here. Is there something in the plans that I don't know about?
I have some ideas, but haven't found time to code it and send patches yet.
FWIW I think the current code is still not clean for my taste. Commit 3b595da441cf ("fdtdec: allow board to provide fdt for CONFIG_OF_SEPARATE") allowed this function to be used regardless of the config options. IMHO we should have 2 clear options:
- U-Boot provides the DTB
Supported with: OF_SEPARATE
- It's somehow passed over to U-Boot
Supported with: OF_SEPARATE + OF_BOARD
That's exactly what I don't personally like. In your example OF_BOARD means "U-Boot has a DTB and here's a way to override it". In my head that options means "U-Boot was handed over a DTB on a register and it must be able to deal with it". The latter is obviously less restrictive to previous bootloaders.
I actually hit this problem with my qemu testing, in that it is actually not possible to use U-Boot's devicetree without hacking the code. We need to be able to select this feature explicitly, or turn it off, at least for development.
Alternatively we can just keep U-Boot config node in a .dtbo and apply it on the fly after QEMU has handed us over the DTB it created.
Regards /Ilias
Regards, Simon
On Mon, Oct 25, 2021 at 06:23:44PM -0600, Simon Glass wrote:
At present this override function is called even when OF_BOARD Is not enabled. This makes it impossible to disable this feature and in fact makes the OF_BOARD option useless.
Reinstate its intended purpose, so that it is possible to switch between the appended devicetree and one provided by the board's custom function.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v5:
- Add new patches to clean up fdtdec_setup() and surrounds
include/fdtdec.h | 7 +++++-- lib/fdtdec.c | 17 +++++++++++------ 2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h index 386f6611294..b2faa84008e 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -1170,8 +1170,11 @@ int fdtdec_resetup(int *rescan);
/**
- Board-specific FDT initialization. Returns the address to a device tree blob.
- Called when CONFIG_OF_BOARD is defined, or if CONFIG_OF_SEPARATE is defined
- and the board implements it.
- Called when CONFIG_OF_BOARD is defined.
- The existing devicetree is available at gd->fdt_blob
*/
- @returns new devicetree blob pointer
void *board_fdt_blob_setup(void);
diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 067c27d0aa3..da36dffec62 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -1203,11 +1203,12 @@ static int uncompress_blob(const void *src, ulong sz_src, void **dstp) return 0; }
-/*
- For CONFIG_OF_SEPARATE, the board may optionally implement this to
- provide and/or fixup the fdt.
+/**
- fdt_find_separate() - Find a devicetree at the end of the image
*/
- @return pointer to FDT blob
-__weak void *board_fdt_blob_setup(void) +static void *fdt_find_separate(void) { void *fdt_blob = NULL; #ifdef CONFIG_SPL_BUILD @@ -1623,11 +1624,15 @@ int fdtdec_setup(void) int ret;
/* The devicetree is typically appended to U-Boot */
if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD))gd->fdt_blob = board_fdt_blob_setup();
if (IS_ENABLED(CONFIG_OF_SEPARATE))gd->fdt_blob = fdt_find_separate(); else /* embed dtb in ELF file for testing / development */ gd->fdt_blob = dtb_dt_embedded();/* Allow the board to override the fdt address. */if (IS_ENABLED(CONFIG_OF_BOARD))gd->fdt_blob = board_fdt_blob_setup();if (!IS_ENABLED(CONFIG_SPL_BUILD)) { /* Allow the early environment to override the fdt address */ gd->fdt_blob = map_sysmem(env_get_ulong("fdtcontroladdr", 16,-- 2.33.0.1079.g6e70778dc9-goog
[1] https://lore.kernel.org/u-boot/YXekTkeL73NM0UOU@apalos.home/
Regards /Ilias
On Wed, Oct 27, 2021 at 10:17:05AM +0300, Ilias Apalodimas wrote:
Hi Simon,
On Tue, 26 Oct 2021 at 18:27, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Tue, 26 Oct 2021 at 07:56, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
As I said here [1], this is moving on an entirely different direction I had in mind. I'd much prefer starting the discussions for a solution that allows us to scale.
I am missing the point here. Is there something in the plans that I don't know about?
I have some ideas, but haven't found time to code it and send patches yet.
FWIW I think the current code is still not clean for my taste. Commit 3b595da441cf ("fdtdec: allow board to provide fdt for CONFIG_OF_SEPARATE") allowed this function to be used regardless of the config options. IMHO we should have 2 clear options:
- U-Boot provides the DTB
Supported with: OF_SEPARATE
- It's somehow passed over to U-Boot
Supported with: OF_SEPARATE + OF_BOARD
That's exactly what I don't personally like. In your example OF_BOARD means "U-Boot has a DTB and here's a way to override it". In my head
In some ways this is just highlighting a long standing problem of working with DTB. There's certainly been some places where splitting the data from the driver has helped. But in some other places, my goodness has it made the development cycle worse. Doing this on QEMU probably is on one of the most annoying cases too since yes, you start by dumping the dtb you would get, then iterating the dts outside of the rest of the scope of your build. In the kernel you can "make dtbs" at least and get things spit out. I'm just repeating over here that the development cycle of working on device trees is at times not great.
Hi Tom
Le mer. 27 oct. 2021 à 21:12, Tom Rini trini@konsulko.com a écrit :
On Wed, Oct 27, 2021 at 10:17:05AM +0300, Ilias Apalodimas wrote:
Hi Simon,
On Tue, 26 Oct 2021 at 18:27, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Tue, 26 Oct 2021 at 07:56, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
As I said here [1], this is moving on an entirely different
direction I had
in mind. I'd much prefer starting the discussions for a solution that allows us to scale.
I am missing the point here. Is there something in the plans that I don't know about?
I have some ideas, but haven't found time to code it and send patches
yet.
FWIW I think the current code is still not clean for my taste.
Commit
3b595da441cf ("fdtdec: allow board to provide fdt for
CONFIG_OF_SEPARATE")
allowed this function to be used regardless of the config options.
IMHO we
should have 2 clear options:
- U-Boot provides the DTB
Supported with: OF_SEPARATE
- It's somehow passed over to U-Boot
Supported with: OF_SEPARATE + OF_BOARD
That's exactly what I don't personally like. In your example OF_BOARD means "U-Boot has a DTB and here's a way to override it". In my head
In some ways this is just highlighting a long standing problem of working with DTB. There's certainly been some places where splitting the data from the driver has helped. But in some other places, my goodness has it made the development cycle worse. Doing this on QEMU probably is on one of the most annoying cases too since yes, you start by dumping the dtb you would get, then iterating the dts outside of the rest of the scope of your build. In the kernel you can "make dtbs" at least and get things spit out. I'm just repeating over here that the development cycle of working on device trees is at times not great.
In general you do this only once, unless you use the virt machine and in that case there is no documentation about DT generated for each device added on the command line. I had lots of difficulties getting all UART possibilities: virtio <1.0, 1.0,1.1; mmio or pci. But once you get the command line, the dTB is fixed. Of course it would be better to get Qemu document DT generation of its devices.
-- Tom
On Wed, Oct 27, 2021 at 11:33:53PM +0200, François Ozog wrote:
Hi Tom
Le mer. 27 oct. 2021 à 21:12, Tom Rini trini@konsulko.com a écrit :
On Wed, Oct 27, 2021 at 10:17:05AM +0300, Ilias Apalodimas wrote:
Hi Simon,
On Tue, 26 Oct 2021 at 18:27, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Tue, 26 Oct 2021 at 07:56, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
As I said here [1], this is moving on an entirely different
direction I had
in mind. I'd much prefer starting the discussions for a solution that allows us to scale.
I am missing the point here. Is there something in the plans that I don't know about?
I have some ideas, but haven't found time to code it and send patches
yet.
FWIW I think the current code is still not clean for my taste.
Commit
3b595da441cf ("fdtdec: allow board to provide fdt for
CONFIG_OF_SEPARATE")
allowed this function to be used regardless of the config options.
IMHO we
should have 2 clear options:
- U-Boot provides the DTB
Supported with: OF_SEPARATE
- It's somehow passed over to U-Boot
Supported with: OF_SEPARATE + OF_BOARD
That's exactly what I don't personally like. In your example OF_BOARD means "U-Boot has a DTB and here's a way to override it". In my head
In some ways this is just highlighting a long standing problem of working with DTB. There's certainly been some places where splitting the data from the driver has helped. But in some other places, my goodness has it made the development cycle worse. Doing this on QEMU probably is on one of the most annoying cases too since yes, you start by dumping the dtb you would get, then iterating the dts outside of the rest of the scope of your build. In the kernel you can "make dtbs" at least and get things spit out. I'm just repeating over here that the development cycle of working on device trees is at times not great.
In general you do this only once, unless you use the virt machine and in that case there is no documentation about DT generated for each device added on the command line. I had lots of difficulties getting all UART possibilities: virtio <1.0, 1.0,1.1; mmio or pci. But once you get the command line, the dTB is fixed. Of course it would be better to get Qemu document DT generation of its devices.
In a lot of ways QEMU isn't even the real problem, unless it's applying rand() to some parts of where devices end up, etc. The cycle there isn't any worse than where the device tree resides in hardware. The device tree development cycle is a pain. QEMU is actually not so bad in this regard really since it's just dumpdtb and pass back the modified one, it takes care of then ensuring it's in the correct spot. The part where every blob must be in the right place is another part of that horror show that binman and fconf both try and address.
Hi Simon
Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
Cheers
FF
Le mar. 26 oct. 2021 à 02:24, Simon Glass sjg@chromium.org a écrit :
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so there are only three ways to obtain a devicetree:
- OF_SEPARATE - the normal way, where the devicetree is built and appended to U-Boot
- OF_EMBED - for development purposes, the devicetree is embedded in the ELF file (also used for EFI)
- OF_BOARD - the board figures it out on its own
The last one is currently set up so that no devicetree is needed at all in the U-Boot tree. Most boards do provide one, but some don't. Some don't even provide instructions on how to boot on the board.
The problems with this approach are documented in another patch in this series: "doc: Add documentation about devicetree usage"
In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board can obtain its devicetree at runtime, even it is has a devicetree built in U-Boot. This is because U-Boot may be a second-stage bootloader and its caller may have a better idea about the hardware available in the machine. This is the case with a few QEMU boards, for example.
So it makes no sense to have OF_BOARD as a 'choice'. It should be an option, available with either OF_SEPARATE or OF_EMBED.
This series makes this change, adding various missing devicetree files (and placeholders) to make the build work.
Note: If board maintainers are able to add their own patch to add the files, some patches in this series can be dropped.
It also provides a few qemu clean-ups discovered along the way.
Note: This breaks the qemu-riscv64_spl test, which still needs investigation.
[1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sj...
Changes in v5:
- Bring into the OF_BOARD series
- Rebase to master and drop mention of OF_PRIOR_STAGE, since removed
- Refer to the 'control' DTB in the first paragraph
- Use QEMU instead of qemu
- Merge RISC-V and ARM patches since they are similar
- Add new patches to clean up fdtdec_setup() and surrounds
Changes in v3:
- Clarify the 'bug' refered to at the top
- Reword 'This means that there' paragraph to explain U-Boot-specific
things
- Move to doc/develop/devicetree now that OF_CONTROL is in the docs
Changes in v2:
- Fix typos per Sean (thank you!) and a few others
- Add a 'Use of U-Boot /config node' section
- Drop mention of dm-verity since that actually uses the kernel cmdline
- Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph)
- Expand a bit on the reason why the 'Current situation' is bad
- Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...'
- Expand on why we should have rules for other projects in 'Devicetree in another project'
- Add a comment as to why devicetree in U-Boot is not 'bad design'
- Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
- Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1
- Add 'Why does U-Boot have its nodes and properties?'
- Add 'Why not have two devicetrees?'
Ilias Apalodimas (1): sandbox: Remove OF_HOSTFILE
Simon Glass (25): doc: Add documentation about devicetree usage arm: qemu: Mention -nographic in the docs arm: riscv: qemu: Explain how to extract the generated dt arm: qemu: Add a devicetree file for qemu_arm arm: qemu: Add a devicetree file for qemu_arm64 riscv: qemu: Add devicetree files for qemu_riscv32/64 arm: rpi: Add a devicetree file for rpi_4 arm: vexpress: Add a devicetree file for juno arm: xenguest_arm64: Add a fake devicetree file arm: octeontx: Add a fake devicetree file arm: xilinx_versal_virt: Add a devicetree file arm: bcm7xxx: Add a devicetree file arm: qemu-ppce500: Add a devicetree file arm: highbank: Add a fake devicetree file fdt: Make OF_BOARD a bool option Drop CONFIG_BINMAN_STANDALONE_FDT doc: Update info on devicetree update fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() fdt: Drop #ifdefs with MULTI_DTB_FIT fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() fdt: Drop #ifdef around board_fdt_blob_setup() fdt: Use if() for fdtcontroladdr check fdt: Drop OF_CONTROL check in fdtdec_setup() fdt: Drop remaining preprocessor macros in fdtdec_setup() fdt: Don't call board_fdt_blob_setup() without OF_BOARD
Makefile | 7 +- arch/arm/dts/Makefile | 20 +- arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 +++++++++++++++++++++ arch/arm/dts/bcm7xxx.dts | 15 + arch/arm/dts/highbank.dts | 14 + arch/arm/dts/juno-r2.dts | 1038 +++++++++++ arch/arm/dts/octeontx.dts | 14 + arch/arm/dts/qemu-arm.dts | 402 +++++ arch/arm/dts/qemu-arm64.dts | 381 ++++ arch/arm/dts/xenguest-arm64.dts | 15 + arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/qemu-ppce500.dts | 264 +++ arch/riscv/dts/Makefile | 2 +- arch/riscv/dts/qemu-virt.dts | 8 - arch/riscv/dts/qemu-virt32.dts | 217 +++ arch/riscv/dts/qemu-virt64.dts | 217 +++ arch/sandbox/cpu/cpu.c | 21 +- arch/sandbox/include/asm/u-boot-sandbox.h | 8 - configs/bcm7260_defconfig | 1 + configs/bcm7445_defconfig | 1 + configs/highbank_defconfig | 2 +- configs/octeontx2_95xx_defconfig | 1 + configs/octeontx2_96xx_defconfig | 1 + configs/octeontx_81xx_defconfig | 1 + configs/octeontx_83xx_defconfig | 1 + configs/qemu-ppce500_defconfig | 2 + configs/qemu-riscv32_defconfig | 1 + configs/qemu-riscv32_smode_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 4 +- configs/qemu-riscv64_defconfig | 1 + configs/qemu-riscv64_smode_defconfig | 1 + configs/qemu-riscv64_spl_defconfig | 3 +- configs/qemu_arm64_defconfig | 1 + configs/qemu_arm_defconfig | 1 + configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + configs/sandbox64_defconfig | 2 +- configs/sandbox_defconfig | 2 +- configs/sandbox_flattree_defconfig | 2 +- configs/sandbox_noinst_defconfig | 2 +- configs/sandbox_spl_defconfig | 2 +- configs/tools-only_defconfig | 2 +- configs/vexpress_aemv8a_juno_defconfig | 1 + configs/xenguest_arm64_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + doc/board/emulation/qemu-arm.rst | 10 +- doc/board/emulation/qemu-riscv.rst | 3 + doc/develop/devicetree/control.rst | 7 +- doc/develop/devicetree/dt_qemu.rst | 48 + doc/develop/devicetree/dt_update.rst | 498 ++++++ doc/develop/devicetree/index.rst | 2 + dts/Kconfig | 37 +- include/asm-generic/global_data.h | 8 + include/fdtdec.h | 21 +- lib/fdtdec.c | 116 +- scripts/Makefile.spl | 4 +- tools/binman/binman.rst | 20 - 59 files changed, 5560 insertions(+), 164 deletions(-) create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts create mode 100644 arch/arm/dts/bcm7xxx.dts create mode 100644 arch/arm/dts/highbank.dts create mode 100644 arch/arm/dts/juno-r2.dts create mode 100644 arch/arm/dts/octeontx.dts create mode 100644 arch/arm/dts/qemu-arm.dts create mode 100644 arch/arm/dts/qemu-arm64.dts create mode 100644 arch/arm/dts/xenguest-arm64.dts create mode 100644 arch/arm/dts/xilinx-versal-virt.dts create mode 100644 arch/powerpc/dts/qemu-ppce500.dts delete mode 100644 arch/riscv/dts/qemu-virt.dts create mode 100644 arch/riscv/dts/qemu-virt32.dts create mode 100644 arch/riscv/dts/qemu-virt64.dts create mode 100644 doc/develop/devicetree/dt_qemu.rst create mode 100644 doc/develop/devicetree/dt_update.rst
-- 2.33.0.1079.g6e70778dc9-goog
--
François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
But trying to do any driver / core work for a board where you don't have the devicetree is currently not possible. The devicetree is a core component and being unable to modify it is simply not practical. We are talking here about an option that can be enabled or disabled. In my case I am able to disable it locally and do my development work.
BTW I've got the bloblist handoff working with a devicetree inside it, for qemu_arm. I need to try it on a real board to figure out what the difference is.
Regards, Simon
Cheers
FF
Le mar. 26 oct. 2021 à 02:24, Simon Glass sjg@chromium.org a écrit :
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so there are only three ways to obtain a devicetree:
- OF_SEPARATE - the normal way, where the devicetree is built and appended to U-Boot
- OF_EMBED - for development purposes, the devicetree is embedded in the ELF file (also used for EFI)
- OF_BOARD - the board figures it out on its own
The last one is currently set up so that no devicetree is needed at all in the U-Boot tree. Most boards do provide one, but some don't. Some don't even provide instructions on how to boot on the board.
The problems with this approach are documented in another patch in this series: "doc: Add documentation about devicetree usage"
In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board can obtain its devicetree at runtime, even it is has a devicetree built in U-Boot. This is because U-Boot may be a second-stage bootloader and its caller may have a better idea about the hardware available in the machine. This is the case with a few QEMU boards, for example.
So it makes no sense to have OF_BOARD as a 'choice'. It should be an option, available with either OF_SEPARATE or OF_EMBED.
This series makes this change, adding various missing devicetree files (and placeholders) to make the build work.
Note: If board maintainers are able to add their own patch to add the files, some patches in this series can be dropped.
It also provides a few qemu clean-ups discovered along the way.
Note: This breaks the qemu-riscv64_spl test, which still needs investigation.
[1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sj...
Changes in v5:
- Bring into the OF_BOARD series
- Rebase to master and drop mention of OF_PRIOR_STAGE, since removed
- Refer to the 'control' DTB in the first paragraph
- Use QEMU instead of qemu
- Merge RISC-V and ARM patches since they are similar
- Add new patches to clean up fdtdec_setup() and surrounds
Changes in v3:
- Clarify the 'bug' refered to at the top
- Reword 'This means that there' paragraph to explain U-Boot-specific things
- Move to doc/develop/devicetree now that OF_CONTROL is in the docs
Changes in v2:
- Fix typos per Sean (thank you!) and a few others
- Add a 'Use of U-Boot /config node' section
- Drop mention of dm-verity since that actually uses the kernel cmdline
- Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph)
- Expand a bit on the reason why the 'Current situation' is bad
- Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...'
- Expand on why we should have rules for other projects in 'Devicetree in another project'
- Add a comment as to why devicetree in U-Boot is not 'bad design'
- Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
- Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1
- Add 'Why does U-Boot have its nodes and properties?'
- Add 'Why not have two devicetrees?'
Ilias Apalodimas (1): sandbox: Remove OF_HOSTFILE
Simon Glass (25): doc: Add documentation about devicetree usage arm: qemu: Mention -nographic in the docs arm: riscv: qemu: Explain how to extract the generated dt arm: qemu: Add a devicetree file for qemu_arm arm: qemu: Add a devicetree file for qemu_arm64 riscv: qemu: Add devicetree files for qemu_riscv32/64 arm: rpi: Add a devicetree file for rpi_4 arm: vexpress: Add a devicetree file for juno arm: xenguest_arm64: Add a fake devicetree file arm: octeontx: Add a fake devicetree file arm: xilinx_versal_virt: Add a devicetree file arm: bcm7xxx: Add a devicetree file arm: qemu-ppce500: Add a devicetree file arm: highbank: Add a fake devicetree file fdt: Make OF_BOARD a bool option Drop CONFIG_BINMAN_STANDALONE_FDT doc: Update info on devicetree update fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() fdt: Drop #ifdefs with MULTI_DTB_FIT fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() fdt: Drop #ifdef around board_fdt_blob_setup() fdt: Use if() for fdtcontroladdr check fdt: Drop OF_CONTROL check in fdtdec_setup() fdt: Drop remaining preprocessor macros in fdtdec_setup() fdt: Don't call board_fdt_blob_setup() without OF_BOARD
Makefile | 7 +- arch/arm/dts/Makefile | 20 +- arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 +++++++++++++++++++++ arch/arm/dts/bcm7xxx.dts | 15 + arch/arm/dts/highbank.dts | 14 + arch/arm/dts/juno-r2.dts | 1038 +++++++++++ arch/arm/dts/octeontx.dts | 14 + arch/arm/dts/qemu-arm.dts | 402 +++++ arch/arm/dts/qemu-arm64.dts | 381 ++++ arch/arm/dts/xenguest-arm64.dts | 15 + arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/qemu-ppce500.dts | 264 +++ arch/riscv/dts/Makefile | 2 +- arch/riscv/dts/qemu-virt.dts | 8 - arch/riscv/dts/qemu-virt32.dts | 217 +++ arch/riscv/dts/qemu-virt64.dts | 217 +++ arch/sandbox/cpu/cpu.c | 21 +- arch/sandbox/include/asm/u-boot-sandbox.h | 8 - configs/bcm7260_defconfig | 1 + configs/bcm7445_defconfig | 1 + configs/highbank_defconfig | 2 +- configs/octeontx2_95xx_defconfig | 1 + configs/octeontx2_96xx_defconfig | 1 + configs/octeontx_81xx_defconfig | 1 + configs/octeontx_83xx_defconfig | 1 + configs/qemu-ppce500_defconfig | 2 + configs/qemu-riscv32_defconfig | 1 + configs/qemu-riscv32_smode_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 4 +- configs/qemu-riscv64_defconfig | 1 + configs/qemu-riscv64_smode_defconfig | 1 + configs/qemu-riscv64_spl_defconfig | 3 +- configs/qemu_arm64_defconfig | 1 + configs/qemu_arm_defconfig | 1 + configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + configs/sandbox64_defconfig | 2 +- configs/sandbox_defconfig | 2 +- configs/sandbox_flattree_defconfig | 2 +- configs/sandbox_noinst_defconfig | 2 +- configs/sandbox_spl_defconfig | 2 +- configs/tools-only_defconfig | 2 +- configs/vexpress_aemv8a_juno_defconfig | 1 + configs/xenguest_arm64_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + doc/board/emulation/qemu-arm.rst | 10 +- doc/board/emulation/qemu-riscv.rst | 3 + doc/develop/devicetree/control.rst | 7 +- doc/develop/devicetree/dt_qemu.rst | 48 + doc/develop/devicetree/dt_update.rst | 498 ++++++ doc/develop/devicetree/index.rst | 2 + dts/Kconfig | 37 +- include/asm-generic/global_data.h | 8 + include/fdtdec.h | 21 +- lib/fdtdec.c | 116 +- scripts/Makefile.spl | 4 +- tools/binman/binman.rst | 20 - 59 files changed, 5560 insertions(+), 164 deletions(-) create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts create mode 100644 arch/arm/dts/bcm7xxx.dts create mode 100644 arch/arm/dts/highbank.dts create mode 100644 arch/arm/dts/juno-r2.dts create mode 100644 arch/arm/dts/octeontx.dts create mode 100644 arch/arm/dts/qemu-arm.dts create mode 100644 arch/arm/dts/qemu-arm64.dts create mode 100644 arch/arm/dts/xenguest-arm64.dts create mode 100644 arch/arm/dts/xilinx-versal-virt.dts create mode 100644 arch/powerpc/dts/qemu-ppce500.dts delete mode 100644 arch/riscv/dts/qemu-virt.dts create mode 100644 arch/riscv/dts/qemu-virt32.dts create mode 100644 arch/riscv/dts/qemu-virt64.dts create mode 100644 doc/develop/devicetree/dt_qemu.rst create mode 100644 doc/develop/devicetree/dt_update.rst
-- 2.33.0.1079.g6e70778dc9-goog
-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that
generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
But trying to do any driver / core work for a board where you don't have the devicetree is currently not possible. The devicetree is a core component and being unable to modify it is simply not practical. We are talking here about an option that can be enabled or disabled. In my case I am able to disable it locally and do my development work.
BTW I've got the bloblist handoff working with a devicetree inside it, for qemu_arm. I need to try it on a real board to figure out what the difference is.
That's great news and much needed for stabilizing the inbound ABI from
prior loader to U-Boot. Let's create another thread to discuss this important topic.
Regards, Simon
Cheers
FF
Le mar. 26 oct. 2021 à 02:24, Simon Glass sjg@chromium.org a écrit :
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so there are only three ways to obtain a devicetree:
- OF_SEPARATE - the normal way, where the devicetree is built and appended to U-Boot
- OF_EMBED - for development purposes, the devicetree is embedded in the ELF file (also used for EFI)
- OF_BOARD - the board figures it out on its own
The last one is currently set up so that no devicetree is needed at all in the U-Boot tree. Most boards do provide one, but some don't. Some don't even provide instructions on how to boot on the board.
The problems with this approach are documented in another patch in this series: "doc: Add documentation about devicetree usage"
In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board can obtain its devicetree at runtime, even it is has a devicetree built in U-Boot. This is because U-Boot may be a second-stage bootloader and
its
caller may have a better idea about the hardware available in the
machine.
This is the case with a few QEMU boards, for example.
So it makes no sense to have OF_BOARD as a 'choice'. It should be an option, available with either OF_SEPARATE or OF_EMBED.
This series makes this change, adding various missing devicetree files (and placeholders) to make the build work.
Note: If board maintainers are able to add their own patch to add the files, some patches in this series can be dropped.
It also provides a few qemu clean-ups discovered along the way.
Note: This breaks the qemu-riscv64_spl test, which still needs investigation.
[1]
https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sj...
Changes in v5:
- Bring into the OF_BOARD series
- Rebase to master and drop mention of OF_PRIOR_STAGE, since removed
- Refer to the 'control' DTB in the first paragraph
- Use QEMU instead of qemu
- Merge RISC-V and ARM patches since they are similar
- Add new patches to clean up fdtdec_setup() and surrounds
Changes in v3:
- Clarify the 'bug' refered to at the top
- Reword 'This means that there' paragraph to explain U-Boot-specific
things
- Move to doc/develop/devicetree now that OF_CONTROL is in the docs
Changes in v2:
- Fix typos per Sean (thank you!) and a few others
- Add a 'Use of U-Boot /config node' section
- Drop mention of dm-verity since that actually uses the kernel cmdline
- Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph)
- Expand a bit on the reason why the 'Current situation' is bad
- Clarify in a second place that Linux and U-Boot use the same
devicetree
in 'To be clear, while U-Boot...'
- Expand on why we should have rules for other projects in 'Devicetree in another project'
- Add a comment as to why devicetree in U-Boot is not 'bad design'
- Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
- Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1
- Add 'Why does U-Boot have its nodes and properties?'
- Add 'Why not have two devicetrees?'
Ilias Apalodimas (1): sandbox: Remove OF_HOSTFILE
Simon Glass (25): doc: Add documentation about devicetree usage arm: qemu: Mention -nographic in the docs arm: riscv: qemu: Explain how to extract the generated dt arm: qemu: Add a devicetree file for qemu_arm arm: qemu: Add a devicetree file for qemu_arm64 riscv: qemu: Add devicetree files for qemu_riscv32/64 arm: rpi: Add a devicetree file for rpi_4 arm: vexpress: Add a devicetree file for juno arm: xenguest_arm64: Add a fake devicetree file arm: octeontx: Add a fake devicetree file arm: xilinx_versal_virt: Add a devicetree file arm: bcm7xxx: Add a devicetree file arm: qemu-ppce500: Add a devicetree file arm: highbank: Add a fake devicetree file fdt: Make OF_BOARD a bool option Drop CONFIG_BINMAN_STANDALONE_FDT doc: Update info on devicetree update fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() fdt: Drop #ifdefs with MULTI_DTB_FIT fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() fdt: Drop #ifdef around board_fdt_blob_setup() fdt: Use if() for fdtcontroladdr check fdt: Drop OF_CONTROL check in fdtdec_setup() fdt: Drop remaining preprocessor macros in fdtdec_setup() fdt: Don't call board_fdt_blob_setup() without OF_BOARD
Makefile | 7 +- arch/arm/dts/Makefile | 20 +- arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 +++++++++++++++++++++ arch/arm/dts/bcm7xxx.dts | 15 + arch/arm/dts/highbank.dts | 14 + arch/arm/dts/juno-r2.dts | 1038 +++++++++++ arch/arm/dts/octeontx.dts | 14 + arch/arm/dts/qemu-arm.dts | 402 +++++ arch/arm/dts/qemu-arm64.dts | 381 ++++ arch/arm/dts/xenguest-arm64.dts | 15 + arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/qemu-ppce500.dts | 264 +++ arch/riscv/dts/Makefile | 2 +- arch/riscv/dts/qemu-virt.dts | 8 - arch/riscv/dts/qemu-virt32.dts | 217 +++ arch/riscv/dts/qemu-virt64.dts | 217 +++ arch/sandbox/cpu/cpu.c | 21 +- arch/sandbox/include/asm/u-boot-sandbox.h | 8 - configs/bcm7260_defconfig | 1 + configs/bcm7445_defconfig | 1 + configs/highbank_defconfig | 2 +- configs/octeontx2_95xx_defconfig | 1 + configs/octeontx2_96xx_defconfig | 1 + configs/octeontx_81xx_defconfig | 1 + configs/octeontx_83xx_defconfig | 1 + configs/qemu-ppce500_defconfig | 2 + configs/qemu-riscv32_defconfig | 1 + configs/qemu-riscv32_smode_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 4 +- configs/qemu-riscv64_defconfig | 1 + configs/qemu-riscv64_smode_defconfig | 1 + configs/qemu-riscv64_spl_defconfig | 3 +- configs/qemu_arm64_defconfig | 1 + configs/qemu_arm_defconfig | 1 + configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + configs/sandbox64_defconfig | 2 +- configs/sandbox_defconfig | 2 +- configs/sandbox_flattree_defconfig | 2 +- configs/sandbox_noinst_defconfig | 2 +- configs/sandbox_spl_defconfig | 2 +- configs/tools-only_defconfig | 2 +- configs/vexpress_aemv8a_juno_defconfig | 1 + configs/xenguest_arm64_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + doc/board/emulation/qemu-arm.rst | 10 +- doc/board/emulation/qemu-riscv.rst | 3 + doc/develop/devicetree/control.rst | 7 +- doc/develop/devicetree/dt_qemu.rst | 48 + doc/develop/devicetree/dt_update.rst | 498 ++++++ doc/develop/devicetree/index.rst | 2 + dts/Kconfig | 37 +- include/asm-generic/global_data.h | 8 + include/fdtdec.h | 21 +- lib/fdtdec.c | 116 +- scripts/Makefile.spl | 4 +- tools/binman/binman.rst | 20 - 59 files changed, 5560 insertions(+), 164 deletions(-) create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts create mode 100644 arch/arm/dts/bcm7xxx.dts create mode 100644 arch/arm/dts/highbank.dts create mode 100644 arch/arm/dts/juno-r2.dts create mode 100644 arch/arm/dts/octeontx.dts create mode 100644 arch/arm/dts/qemu-arm.dts create mode 100644 arch/arm/dts/qemu-arm64.dts create mode 100644 arch/arm/dts/xenguest-arm64.dts create mode 100644 arch/arm/dts/xilinx-versal-virt.dts create mode 100644 arch/powerpc/dts/qemu-ppce500.dts delete mode 100644 arch/riscv/dts/qemu-virt.dts create mode 100644 arch/riscv/dts/qemu-virt32.dts create mode 100644 arch/riscv/dts/qemu-virt64.dts create mode 100644 doc/develop/devicetree/dt_qemu.rst create mode 100644 doc/develop/devicetree/dt_update.rst
-- 2.33.0.1079.g6e70778dc9-goog
-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog francois.ozog@linaro.org wrote:
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on.
We can add a message to U-Boot indicating where the devicetree came from, perhaps? That might be useful given everything that is going on.
As in this case, quite often in these discussions I struggle to understand what is behind the objection. Is it that your customers are demanding that devicetrees become private, secret data, not included in open-source projects? Or is it just the strange case of QEMU that is informing your thinking? I know of at least one project where the first-stage bootloader produces a devicetree and no one has the source for it. I believe TF-A was created for licensing reasons...so can you be a bit clearer about what the problem actually is? If a board is in-tree in U-Boot I would like it to have a devicetree there, at least until we have a better option. At the very least, it MUST be discoverable and it must be possible to undertake U-Boot development easily without a lot of messing around.
But trying to do any driver / core work for a board where you don't have the devicetree is currently not possible. The devicetree is a core component and being unable to modify it is simply not practical. We are talking here about an option that can be enabled or disabled. In my case I am able to disable it locally and do my development work.
BTW I've got the bloblist handoff working with a devicetree inside it, for qemu_arm. I need to try it on a real board to figure out what the difference is.
That's great news and much needed for stabilizing the inbound ABI from prior loader to U-Boot. Let's create another thread to discuss this important topic.
My scenario is not all that advanced and I am using qemu_arm to test the bloblist handoff stuff and include it in CI, with a suitable devicetree and a binman node.
Regards, Simon
Cheers
FF
Le mar. 26 oct. 2021 à 02:24, Simon Glass sjg@chromium.org a écrit :
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so there are only three ways to obtain a devicetree:
- OF_SEPARATE - the normal way, where the devicetree is built and appended to U-Boot
- OF_EMBED - for development purposes, the devicetree is embedded in the ELF file (also used for EFI)
- OF_BOARD - the board figures it out on its own
The last one is currently set up so that no devicetree is needed at all in the U-Boot tree. Most boards do provide one, but some don't. Some don't even provide instructions on how to boot on the board.
The problems with this approach are documented in another patch in this series: "doc: Add documentation about devicetree usage"
In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board can obtain its devicetree at runtime, even it is has a devicetree built in U-Boot. This is because U-Boot may be a second-stage bootloader and its caller may have a better idea about the hardware available in the machine. This is the case with a few QEMU boards, for example.
So it makes no sense to have OF_BOARD as a 'choice'. It should be an option, available with either OF_SEPARATE or OF_EMBED.
This series makes this change, adding various missing devicetree files (and placeholders) to make the build work.
Note: If board maintainers are able to add their own patch to add the files, some patches in this series can be dropped.
It also provides a few qemu clean-ups discovered along the way.
Note: This breaks the qemu-riscv64_spl test, which still needs investigation.
[1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sj...
Changes in v5:
- Bring into the OF_BOARD series
- Rebase to master and drop mention of OF_PRIOR_STAGE, since removed
- Refer to the 'control' DTB in the first paragraph
- Use QEMU instead of qemu
- Merge RISC-V and ARM patches since they are similar
- Add new patches to clean up fdtdec_setup() and surrounds
Changes in v3:
- Clarify the 'bug' refered to at the top
- Reword 'This means that there' paragraph to explain U-Boot-specific things
- Move to doc/develop/devicetree now that OF_CONTROL is in the docs
Changes in v2:
- Fix typos per Sean (thank you!) and a few others
- Add a 'Use of U-Boot /config node' section
- Drop mention of dm-verity since that actually uses the kernel cmdline
- Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph)
- Expand a bit on the reason why the 'Current situation' is bad
- Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...'
- Expand on why we should have rules for other projects in 'Devicetree in another project'
- Add a comment as to why devicetree in U-Boot is not 'bad design'
- Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
- Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1
- Add 'Why does U-Boot have its nodes and properties?'
- Add 'Why not have two devicetrees?'
Ilias Apalodimas (1): sandbox: Remove OF_HOSTFILE
Simon Glass (25): doc: Add documentation about devicetree usage arm: qemu: Mention -nographic in the docs arm: riscv: qemu: Explain how to extract the generated dt arm: qemu: Add a devicetree file for qemu_arm arm: qemu: Add a devicetree file for qemu_arm64 riscv: qemu: Add devicetree files for qemu_riscv32/64 arm: rpi: Add a devicetree file for rpi_4 arm: vexpress: Add a devicetree file for juno arm: xenguest_arm64: Add a fake devicetree file arm: octeontx: Add a fake devicetree file arm: xilinx_versal_virt: Add a devicetree file arm: bcm7xxx: Add a devicetree file arm: qemu-ppce500: Add a devicetree file arm: highbank: Add a fake devicetree file fdt: Make OF_BOARD a bool option Drop CONFIG_BINMAN_STANDALONE_FDT doc: Update info on devicetree update fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() fdt: Drop #ifdefs with MULTI_DTB_FIT fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() fdt: Drop #ifdef around board_fdt_blob_setup() fdt: Use if() for fdtcontroladdr check fdt: Drop OF_CONTROL check in fdtdec_setup() fdt: Drop remaining preprocessor macros in fdtdec_setup() fdt: Don't call board_fdt_blob_setup() without OF_BOARD
Makefile | 7 +- arch/arm/dts/Makefile | 20 +- arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 +++++++++++++++++++++ arch/arm/dts/bcm7xxx.dts | 15 + arch/arm/dts/highbank.dts | 14 + arch/arm/dts/juno-r2.dts | 1038 +++++++++++ arch/arm/dts/octeontx.dts | 14 + arch/arm/dts/qemu-arm.dts | 402 +++++ arch/arm/dts/qemu-arm64.dts | 381 ++++ arch/arm/dts/xenguest-arm64.dts | 15 + arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/qemu-ppce500.dts | 264 +++ arch/riscv/dts/Makefile | 2 +- arch/riscv/dts/qemu-virt.dts | 8 - arch/riscv/dts/qemu-virt32.dts | 217 +++ arch/riscv/dts/qemu-virt64.dts | 217 +++ arch/sandbox/cpu/cpu.c | 21 +- arch/sandbox/include/asm/u-boot-sandbox.h | 8 - configs/bcm7260_defconfig | 1 + configs/bcm7445_defconfig | 1 + configs/highbank_defconfig | 2 +- configs/octeontx2_95xx_defconfig | 1 + configs/octeontx2_96xx_defconfig | 1 + configs/octeontx_81xx_defconfig | 1 + configs/octeontx_83xx_defconfig | 1 + configs/qemu-ppce500_defconfig | 2 + configs/qemu-riscv32_defconfig | 1 + configs/qemu-riscv32_smode_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 4 +- configs/qemu-riscv64_defconfig | 1 + configs/qemu-riscv64_smode_defconfig | 1 + configs/qemu-riscv64_spl_defconfig | 3 +- configs/qemu_arm64_defconfig | 1 + configs/qemu_arm_defconfig | 1 + configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + configs/sandbox64_defconfig | 2 +- configs/sandbox_defconfig | 2 +- configs/sandbox_flattree_defconfig | 2 +- configs/sandbox_noinst_defconfig | 2 +- configs/sandbox_spl_defconfig | 2 +- configs/tools-only_defconfig | 2 +- configs/vexpress_aemv8a_juno_defconfig | 1 + configs/xenguest_arm64_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + doc/board/emulation/qemu-arm.rst | 10 +- doc/board/emulation/qemu-riscv.rst | 3 + doc/develop/devicetree/control.rst | 7 +- doc/develop/devicetree/dt_qemu.rst | 48 + doc/develop/devicetree/dt_update.rst | 498 ++++++ doc/develop/devicetree/index.rst | 2 + dts/Kconfig | 37 +- include/asm-generic/global_data.h | 8 + include/fdtdec.h | 21 +- lib/fdtdec.c | 116 +- scripts/Makefile.spl | 4 +- tools/binman/binman.rst | 20 - 59 files changed, 5560 insertions(+), 164 deletions(-) create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts create mode 100644 arch/arm/dts/bcm7xxx.dts create mode 100644 arch/arm/dts/highbank.dts create mode 100644 arch/arm/dts/juno-r2.dts create mode 100644 arch/arm/dts/octeontx.dts create mode 100644 arch/arm/dts/qemu-arm.dts create mode 100644 arch/arm/dts/qemu-arm64.dts create mode 100644 arch/arm/dts/xenguest-arm64.dts create mode 100644 arch/arm/dts/xilinx-versal-virt.dts create mode 100644 arch/powerpc/dts/qemu-ppce500.dts delete mode 100644 arch/riscv/dts/qemu-virt.dts create mode 100644 arch/riscv/dts/qemu-virt32.dts create mode 100644 arch/riscv/dts/qemu-virt64.dts create mode 100644 doc/develop/devicetree/dt_qemu.rst create mode 100644 doc/develop/devicetree/dt_update.rst
-- 2.33.0.1079.g6e70778dc9-goog
-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
On Wed, Oct 27, 2021 at 12:23:21PM -0600, Simon Glass wrote:
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog francois.ozog@linaro.org wrote:
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on.
That we have to have so many separate rpi build targets, and can't just use rpm_arm64 and add rpi_arm32 is not a good feature. The various rpi configs that use CONFIG_OF_EMBED are on your list of things that need to be cleaned up, yes?
We can add a message to U-Boot indicating where the devicetree came from, perhaps? That might be useful given everything that is going on.
As in this case, quite often in these discussions I struggle to understand what is behind the objection. Is it that your customers are demanding that devicetrees become private, secret data, not included in open-source projects? Or is it just the strange case of QEMU that is informing your thinking? I know of at least one project where the first-stage bootloader produces a devicetree and no one has the source for it. I believe TF-A was created for licensing reasons...so can you be a bit clearer about what the problem actually is? If a board is in-tree in U-Boot I would like it to have a devicetree there, at least until we have a better option. At the very least, it MUST be discoverable and it must be possible to undertake U-Boot development easily without a lot of messing around.
What I don't understand here is why or how U-Boot is supposed to become the source of truth for device trees. The general goal is that the device tree be something that actually comes along on the hardware, because it's stable enough and correct enough that it's not going to be changed from one OS kernel release to the next. That should be where the correct and true tree comes from, the device itself.
Hi Tom,
On Wed, 27 Oct 2021 at 13:25, Tom Rini trini@konsulko.com wrote:
On Wed, Oct 27, 2021 at 12:23:21PM -0600, Simon Glass wrote:
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog francois.ozog@linaro.org wrote:
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on.
That we have to have so many separate rpi build targets, and can't just use rpm_arm64 and add rpi_arm32 is not a good feature. The various rpi configs that use CONFIG_OF_EMBED are on your list of things that need to be cleaned up, yes?
Yes, it should use CONFIG_OF_SEPARATE. It think it didn't for historical reasons, but not sure why.
We can add a message to U-Boot indicating where the devicetree came from, perhaps? That might be useful given everything that is going on.
As in this case, quite often in these discussions I struggle to understand what is behind the objection. Is it that your customers are demanding that devicetrees become private, secret data, not included in open-source projects? Or is it just the strange case of QEMU that is informing your thinking? I know of at least one project where the first-stage bootloader produces a devicetree and no one has the source for it. I believe TF-A was created for licensing reasons...so can you be a bit clearer about what the problem actually is? If a board is in-tree in U-Boot I would like it to have a devicetree there, at least until we have a better option. At the very least, it MUST be discoverable and it must be possible to undertake U-Boot development easily without a lot of messing around.
What I don't understand here is why or how U-Boot is supposed to become the source of truth for device trees. The general goal is that the device tree be something that actually comes along on the hardware, because it's stable enough and correct enough that it's not going to be changed from one OS kernel release to the next. That should be where the correct and true tree comes from, the device itself.
Is that the confusion here? I am not saying that U-Boot becomes the 'source of truth' (horrible term). Where did that idea come from?
By hardware you mean firmware, I think. If you are developing firmware, you need control of the devicetree. It is part of the firmware.
Regards, Simon
On Wed, Nov 03, 2021 at 10:45:11AM -0600, Simon Glass wrote:
Hi Tom,
On Wed, 27 Oct 2021 at 13:25, Tom Rini trini@konsulko.com wrote:
On Wed, Oct 27, 2021 at 12:23:21PM -0600, Simon Glass wrote:
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog francois.ozog@linaro.org wrote:
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on.
That we have to have so many separate rpi build targets, and can't just use rpm_arm64 and add rpi_arm32 is not a good feature. The various rpi configs that use CONFIG_OF_EMBED are on your list of things that need to be cleaned up, yes?
Yes, it should use CONFIG_OF_SEPARATE. It think it didn't for historical reasons, but not sure why.
I think because it wasn't clear enough at the time how to say "just use the dtb given to us as-is".
We can add a message to U-Boot indicating where the devicetree came from, perhaps? That might be useful given everything that is going on.
As in this case, quite often in these discussions I struggle to understand what is behind the objection. Is it that your customers are demanding that devicetrees become private, secret data, not included in open-source projects? Or is it just the strange case of QEMU that is informing your thinking? I know of at least one project where the first-stage bootloader produces a devicetree and no one has the source for it. I believe TF-A was created for licensing reasons...so can you be a bit clearer about what the problem actually is? If a board is in-tree in U-Boot I would like it to have a devicetree there, at least until we have a better option. At the very least, it MUST be discoverable and it must be possible to undertake U-Boot development easily without a lot of messing around.
What I don't understand here is why or how U-Boot is supposed to become the source of truth for device trees. The general goal is that the device tree be something that actually comes along on the hardware, because it's stable enough and correct enough that it's not going to be changed from one OS kernel release to the next. That should be where the correct and true tree comes from, the device itself.
Is that the confusion here? I am not saying that U-Boot becomes the 'source of truth' (horrible term). Where did that idea come from?
By hardware you mean firmware, I think. If you are developing firmware, you need control of the devicetree. It is part of the firmware.
I mean the case where U-Boot is provided the device tree to use, by whatever external and non-U-Boot means. I keep saying "source of truth" as a way to clarify that the correct and only required device tree is given to us at run time. If U-Boot needs to know something, it's already provided there. If it's not there, we don't need to know it. This is also why there's not a reason to normally build a device tree in U-Boot since it will not be used. And if we aren't building it, we don't need it in the source tree either since it's going to introduce confusion. Quoted in part or referenced under doc/ ? OK, that can make sense in some cases.
Hi Simon
Le mer. 27 oct. 2021 à 20:23, Simon Glass sjg@chromium.org a écrit :
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog francois.ozog@linaro.org wrote:
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org
wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that
generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
I am not the only one in disagreement... You just saw Alex Bénée from
Qemu saying the same thing.
I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the
contributors to think that they need to compile the DT for the targeted platforms.
For your advanced scenario, you can still have the dts in the
documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on.
We can add a message to U-Boot indicating where the devicetree came from, perhaps? That might be useful given everything that is going on.
As in this case, quite often in these discussions I struggle to understand what is behind the objection. Is it that your customers are demanding that devicetrees become private, secret data, not included in open-source projects? Or is it just the strange case of QEMU that is informing your thinking? I know of at least one project where the first-stage bootloader produces a devicetree and no one has the source for it. I believe TF-A was created for licensing reasons...so can you be a bit clearer about what the problem actually is?
there are situations where U-Boot must have a dtb. Then those dTB sources are logically found in the dts directory. There are situations where U-Boot should not have a dtb. In that case there should be no element in the dts directory. Otherwise it creates confusion. Now as you point out, we need “playgrounds” to deal with some situation. So having examples in an ad-hoc directory, different from dts is fine. I proposed documentation but you may find a better place. In other words, dts shall host only dt source when U-Boot cannot do but make a dTB for a platform. As you have seen in different mail thread (firmware sustainability and OCP checklist) freedom is important to Linaro and there are no hidden Trojan horse for licensing.
If a board is
in-tree in U-Boot I would like it to have a devicetree there, at least until we have a better option. At the very least, it MUST be discoverable and it must be possible to undertake U-Boot development easily without a lot of messing around.
You can if you keep two dts directories separate: dts for boards for which U-Boot must have one debug-dts for boards for which U-Boot get the DT at runtime but for which you want a playground for debug/easier development.
But trying to do any driver / core work for a board where you don't have the devicetree is currently not possible. The devicetree is a core component and being unable to modify it is simply not practical. We are talking here about an option that can be enabled or disabled. In my case I am able to disable it locally and do my development work.
BTW I've got the bloblist handoff working with a devicetree inside it, for qemu_arm. I need to try it on a real board to figure out what the difference is.
That's great news and much needed for stabilizing the inbound ABI from
prior loader to U-Boot. Let's create another thread to discuss this important topic.
My scenario is not all that advanced and I am using qemu_arm to test the bloblist handoff stuff and include it in CI, with a suitable devicetree and a binman node.
Regards, Simon
Cheers
FF
Le mar. 26 oct. 2021 à 02:24, Simon Glass sjg@chromium.org a écrit
:
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so there are only three ways to obtain a devicetree:
- OF_SEPARATE - the normal way, where the devicetree is built and appended to U-Boot
- OF_EMBED - for development purposes, the devicetree is embedded
in
the ELF file (also used for EFI)
- OF_BOARD - the board figures it out on its own
The last one is currently set up so that no devicetree is needed at
all
in the U-Boot tree. Most boards do provide one, but some don't. Some don't even provide instructions on how to boot on the board.
The problems with this approach are documented in another patch in
this
series: "doc: Add documentation about devicetree usage"
In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any
board
can obtain its devicetree at runtime, even it is has a devicetree
built
in U-Boot. This is because U-Boot may be a second-stage bootloader
and its
caller may have a better idea about the hardware available in the
machine.
This is the case with a few QEMU boards, for example.
So it makes no sense to have OF_BOARD as a 'choice'. It should be an option, available with either OF_SEPARATE or OF_EMBED.
This series makes this change, adding various missing devicetree
files
(and placeholders) to make the build work.
Note: If board maintainers are able to add their own patch to add the files, some patches in this series can be dropped.
It also provides a few qemu clean-ups discovered along the way.
Note: This breaks the qemu-riscv64_spl test, which still needs investigation.
[1]
https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sj...
Changes in v5:
- Bring into the OF_BOARD series
- Rebase to master and drop mention of OF_PRIOR_STAGE, since removed
- Refer to the 'control' DTB in the first paragraph
- Use QEMU instead of qemu
- Merge RISC-V and ARM patches since they are similar
- Add new patches to clean up fdtdec_setup() and surrounds
Changes in v3:
- Clarify the 'bug' refered to at the top
- Reword 'This means that there' paragraph to explain
U-Boot-specific things
- Move to doc/develop/devicetree now that OF_CONTROL is in the docs
Changes in v2:
- Fix typos per Sean (thank you!) and a few others
- Add a 'Use of U-Boot /config node' section
- Drop mention of dm-verity since that actually uses the kernel
cmdline
- Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph)
- Expand a bit on the reason why the 'Current situation' is bad
- Clarify in a second place that Linux and U-Boot use the same
devicetree
in 'To be clear, while U-Boot...'
- Expand on why we should have rules for other projects in 'Devicetree in another project'
- Add a comment as to why devicetree in U-Boot is not 'bad design'
- Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
- Rewrite 'Devicetree generated on-the-fly in another project' to
cover
points raised on v1
- Add 'Why does U-Boot have its nodes and properties?'
- Add 'Why not have two devicetrees?'
Ilias Apalodimas (1): sandbox: Remove OF_HOSTFILE
Simon Glass (25): doc: Add documentation about devicetree usage arm: qemu: Mention -nographic in the docs arm: riscv: qemu: Explain how to extract the generated dt arm: qemu: Add a devicetree file for qemu_arm arm: qemu: Add a devicetree file for qemu_arm64 riscv: qemu: Add devicetree files for qemu_riscv32/64 arm: rpi: Add a devicetree file for rpi_4 arm: vexpress: Add a devicetree file for juno arm: xenguest_arm64: Add a fake devicetree file arm: octeontx: Add a fake devicetree file arm: xilinx_versal_virt: Add a devicetree file arm: bcm7xxx: Add a devicetree file arm: qemu-ppce500: Add a devicetree file arm: highbank: Add a fake devicetree file fdt: Make OF_BOARD a bool option Drop CONFIG_BINMAN_STANDALONE_FDT doc: Update info on devicetree update fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() fdt: Drop #ifdefs with MULTI_DTB_FIT fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() fdt: Drop #ifdef around board_fdt_blob_setup() fdt: Use if() for fdtcontroladdr check fdt: Drop OF_CONTROL check in fdtdec_setup() fdt: Drop remaining preprocessor macros in fdtdec_setup() fdt: Don't call board_fdt_blob_setup() without OF_BOARD
Makefile | 7 +- arch/arm/dts/Makefile | 20 +- arch/arm/dts/bcm2711-rpi-4-b.dts | 1958
+++++++++++++++++++++
arch/arm/dts/bcm7xxx.dts | 15 + arch/arm/dts/highbank.dts | 14 + arch/arm/dts/juno-r2.dts | 1038 +++++++++++ arch/arm/dts/octeontx.dts | 14 + arch/arm/dts/qemu-arm.dts | 402 +++++ arch/arm/dts/qemu-arm64.dts | 381 ++++ arch/arm/dts/xenguest-arm64.dts | 15 + arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/qemu-ppce500.dts | 264 +++ arch/riscv/dts/Makefile | 2 +- arch/riscv/dts/qemu-virt.dts | 8 - arch/riscv/dts/qemu-virt32.dts | 217 +++ arch/riscv/dts/qemu-virt64.dts | 217 +++ arch/sandbox/cpu/cpu.c | 21 +- arch/sandbox/include/asm/u-boot-sandbox.h | 8 - configs/bcm7260_defconfig | 1 + configs/bcm7445_defconfig | 1 + configs/highbank_defconfig | 2 +- configs/octeontx2_95xx_defconfig | 1 + configs/octeontx2_96xx_defconfig | 1 + configs/octeontx_81xx_defconfig | 1 + configs/octeontx_83xx_defconfig | 1 + configs/qemu-ppce500_defconfig | 2 + configs/qemu-riscv32_defconfig | 1 + configs/qemu-riscv32_smode_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 4 +- configs/qemu-riscv64_defconfig | 1 + configs/qemu-riscv64_smode_defconfig | 1 + configs/qemu-riscv64_spl_defconfig | 3 +- configs/qemu_arm64_defconfig | 1 + configs/qemu_arm_defconfig | 1 + configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + configs/sandbox64_defconfig | 2 +- configs/sandbox_defconfig | 2 +- configs/sandbox_flattree_defconfig | 2 +- configs/sandbox_noinst_defconfig | 2 +- configs/sandbox_spl_defconfig | 2 +- configs/tools-only_defconfig | 2 +- configs/vexpress_aemv8a_juno_defconfig | 1 + configs/xenguest_arm64_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + doc/board/emulation/qemu-arm.rst | 10 +- doc/board/emulation/qemu-riscv.rst | 3 + doc/develop/devicetree/control.rst | 7 +- doc/develop/devicetree/dt_qemu.rst | 48 + doc/develop/devicetree/dt_update.rst | 498 ++++++ doc/develop/devicetree/index.rst | 2 + dts/Kconfig | 37 +- include/asm-generic/global_data.h | 8 + include/fdtdec.h | 21 +- lib/fdtdec.c | 116 +- scripts/Makefile.spl | 4 +- tools/binman/binman.rst | 20 - 59 files changed, 5560 insertions(+), 164 deletions(-) create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts create mode 100644 arch/arm/dts/bcm7xxx.dts create mode 100644 arch/arm/dts/highbank.dts create mode 100644 arch/arm/dts/juno-r2.dts create mode 100644 arch/arm/dts/octeontx.dts create mode 100644 arch/arm/dts/qemu-arm.dts create mode 100644 arch/arm/dts/qemu-arm64.dts create mode 100644 arch/arm/dts/xenguest-arm64.dts create mode 100644 arch/arm/dts/xilinx-versal-virt.dts create mode 100644 arch/powerpc/dts/qemu-ppce500.dts delete mode 100644 arch/riscv/dts/qemu-virt.dts create mode 100644 arch/riscv/dts/qemu-virt32.dts create mode 100644 arch/riscv/dts/qemu-virt64.dts create mode 100644 doc/develop/devicetree/dt_qemu.rst create mode 100644 doc/develop/devicetree/dt_update.rst
-- 2.33.0.1079.g6e70778dc9-goog
-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
Hi François,
On Wed, 27 Oct 2021 at 14:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Le mer. 27 oct. 2021 à 20:23, Simon Glass sjg@chromium.org a écrit :
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog francois.ozog@linaro.org wrote:
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on.
We can add a message to U-Boot indicating where the devicetree came from, perhaps? That might be useful given everything that is going on.
As in this case, quite often in these discussions I struggle to understand what is behind the objection. Is it that your customers are demanding that devicetrees become private, secret data, not included in open-source projects? Or is it just the strange case of QEMU that is informing your thinking? I know of at least one project where the first-stage bootloader produces a devicetree and no one has the source for it. I believe TF-A was created for licensing reasons...so can you be a bit clearer about what the problem actually is?
there are situations where U-Boot must have a dtb. Then those dTB sources are logically found in the dts directory. There are situations where U-Boot should not have a dtb. In that case there should be no element in the dts directory. Otherwise it creates confusion. Now as you point out, we need “playgrounds” to deal with some situation. So having examples in an ad-hoc directory, different from dts is fine. I proposed documentation but you may find a better place. In other words, dts shall host only dt source when U-Boot cannot do but make a dTB for a platform. As you have seen in different mail thread (firmware sustainability and OCP checklist) freedom is important to Linaro and there are no hidden Trojan horse for licensing.
I don't understand what you are getting at with the Trojan horse. But you have no objection to requiring boards to supply a DT (whether in documentation or arch/arm/dts) to be in U-Boot?
If a board is in-tree in U-Boot I would like it to have a devicetree there, at least until we have a better option. At the very least, it MUST be discoverable and it must be possible to undertake U-Boot development easily without a lot of messing around.
You can if you keep two dts directories separate: dts for boards for which U-Boot must have one debug-dts for boards for which U-Boot get the DT at runtime but for which you want a playground for debug/easier development.
But trying to do any driver / core work for a board where you don't have the devicetree is currently not possible. The devicetree is a core component and being unable to modify it is simply not practical. We are talking here about an option that can be enabled or disabled. In my case I am able to disable it locally and do my development work.
BTW I've got the bloblist handoff working with a devicetree inside it, for qemu_arm. I need to try it on a real board to figure out what the difference is.
That's great news and much needed for stabilizing the inbound ABI from prior loader to U-Boot. Let's create another thread to discuss this important topic.
My scenario is not all that advanced and I am using qemu_arm to test the bloblist handoff stuff and include it in CI, with a suitable devicetree and a binman node.
Regards, Simon
Cheers
FF
Le mar. 26 oct. 2021 à 02:24, Simon Glass sjg@chromium.org a écrit :
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so there are only three ways to obtain a devicetree:
- OF_SEPARATE - the normal way, where the devicetree is built and appended to U-Boot
- OF_EMBED - for development purposes, the devicetree is embedded in the ELF file (also used for EFI)
- OF_BOARD - the board figures it out on its own
The last one is currently set up so that no devicetree is needed at all in the U-Boot tree. Most boards do provide one, but some don't. Some don't even provide instructions on how to boot on the board.
The problems with this approach are documented in another patch in this series: "doc: Add documentation about devicetree usage"
In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board can obtain its devicetree at runtime, even it is has a devicetree built in U-Boot. This is because U-Boot may be a second-stage bootloader and its caller may have a better idea about the hardware available in the machine. This is the case with a few QEMU boards, for example.
So it makes no sense to have OF_BOARD as a 'choice'. It should be an option, available with either OF_SEPARATE or OF_EMBED.
This series makes this change, adding various missing devicetree files (and placeholders) to make the build work.
Note: If board maintainers are able to add their own patch to add the files, some patches in this series can be dropped.
It also provides a few qemu clean-ups discovered along the way.
Note: This breaks the qemu-riscv64_spl test, which still needs investigation.
[1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sj...
Changes in v5:
- Bring into the OF_BOARD series
- Rebase to master and drop mention of OF_PRIOR_STAGE, since removed
- Refer to the 'control' DTB in the first paragraph
- Use QEMU instead of qemu
- Merge RISC-V and ARM patches since they are similar
- Add new patches to clean up fdtdec_setup() and surrounds
Changes in v3:
- Clarify the 'bug' refered to at the top
- Reword 'This means that there' paragraph to explain U-Boot-specific things
- Move to doc/develop/devicetree now that OF_CONTROL is in the docs
Changes in v2:
- Fix typos per Sean (thank you!) and a few others
- Add a 'Use of U-Boot /config node' section
- Drop mention of dm-verity since that actually uses the kernel cmdline
- Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph)
- Expand a bit on the reason why the 'Current situation' is bad
- Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...'
- Expand on why we should have rules for other projects in 'Devicetree in another project'
- Add a comment as to why devicetree in U-Boot is not 'bad design'
- Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
- Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1
- Add 'Why does U-Boot have its nodes and properties?'
- Add 'Why not have two devicetrees?'
Ilias Apalodimas (1): sandbox: Remove OF_HOSTFILE
Simon Glass (25): doc: Add documentation about devicetree usage arm: qemu: Mention -nographic in the docs arm: riscv: qemu: Explain how to extract the generated dt arm: qemu: Add a devicetree file for qemu_arm arm: qemu: Add a devicetree file for qemu_arm64 riscv: qemu: Add devicetree files for qemu_riscv32/64 arm: rpi: Add a devicetree file for rpi_4 arm: vexpress: Add a devicetree file for juno arm: xenguest_arm64: Add a fake devicetree file arm: octeontx: Add a fake devicetree file arm: xilinx_versal_virt: Add a devicetree file arm: bcm7xxx: Add a devicetree file arm: qemu-ppce500: Add a devicetree file arm: highbank: Add a fake devicetree file fdt: Make OF_BOARD a bool option Drop CONFIG_BINMAN_STANDALONE_FDT doc: Update info on devicetree update fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() fdt: Drop #ifdefs with MULTI_DTB_FIT fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() fdt: Drop #ifdef around board_fdt_blob_setup() fdt: Use if() for fdtcontroladdr check fdt: Drop OF_CONTROL check in fdtdec_setup() fdt: Drop remaining preprocessor macros in fdtdec_setup() fdt: Don't call board_fdt_blob_setup() without OF_BOARD
Makefile | 7 +- arch/arm/dts/Makefile | 20 +- arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 +++++++++++++++++++++ arch/arm/dts/bcm7xxx.dts | 15 + arch/arm/dts/highbank.dts | 14 + arch/arm/dts/juno-r2.dts | 1038 +++++++++++ arch/arm/dts/octeontx.dts | 14 + arch/arm/dts/qemu-arm.dts | 402 +++++ arch/arm/dts/qemu-arm64.dts | 381 ++++ arch/arm/dts/xenguest-arm64.dts | 15 + arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/qemu-ppce500.dts | 264 +++ arch/riscv/dts/Makefile | 2 +- arch/riscv/dts/qemu-virt.dts | 8 - arch/riscv/dts/qemu-virt32.dts | 217 +++ arch/riscv/dts/qemu-virt64.dts | 217 +++ arch/sandbox/cpu/cpu.c | 21 +- arch/sandbox/include/asm/u-boot-sandbox.h | 8 - configs/bcm7260_defconfig | 1 + configs/bcm7445_defconfig | 1 + configs/highbank_defconfig | 2 +- configs/octeontx2_95xx_defconfig | 1 + configs/octeontx2_96xx_defconfig | 1 + configs/octeontx_81xx_defconfig | 1 + configs/octeontx_83xx_defconfig | 1 + configs/qemu-ppce500_defconfig | 2 + configs/qemu-riscv32_defconfig | 1 + configs/qemu-riscv32_smode_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 4 +- configs/qemu-riscv64_defconfig | 1 + configs/qemu-riscv64_smode_defconfig | 1 + configs/qemu-riscv64_spl_defconfig | 3 +- configs/qemu_arm64_defconfig | 1 + configs/qemu_arm_defconfig | 1 + configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + configs/sandbox64_defconfig | 2 +- configs/sandbox_defconfig | 2 +- configs/sandbox_flattree_defconfig | 2 +- configs/sandbox_noinst_defconfig | 2 +- configs/sandbox_spl_defconfig | 2 +- configs/tools-only_defconfig | 2 +- configs/vexpress_aemv8a_juno_defconfig | 1 + configs/xenguest_arm64_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + doc/board/emulation/qemu-arm.rst | 10 +- doc/board/emulation/qemu-riscv.rst | 3 + doc/develop/devicetree/control.rst | 7 +- doc/develop/devicetree/dt_qemu.rst | 48 + doc/develop/devicetree/dt_update.rst | 498 ++++++ doc/develop/devicetree/index.rst | 2 + dts/Kconfig | 37 +- include/asm-generic/global_data.h | 8 + include/fdtdec.h | 21 +- lib/fdtdec.c | 116 +- scripts/Makefile.spl | 4 +- tools/binman/binman.rst | 20 - 59 files changed, 5560 insertions(+), 164 deletions(-) create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts create mode 100644 arch/arm/dts/bcm7xxx.dts create mode 100644 arch/arm/dts/highbank.dts create mode 100644 arch/arm/dts/juno-r2.dts create mode 100644 arch/arm/dts/octeontx.dts create mode 100644 arch/arm/dts/qemu-arm.dts create mode 100644 arch/arm/dts/qemu-arm64.dts create mode 100644 arch/arm/dts/xenguest-arm64.dts create mode 100644 arch/arm/dts/xilinx-versal-virt.dts create mode 100644 arch/powerpc/dts/qemu-ppce500.dts delete mode 100644 arch/riscv/dts/qemu-virt.dts create mode 100644 arch/riscv/dts/qemu-virt32.dts create mode 100644 arch/riscv/dts/qemu-virt64.dts create mode 100644 doc/develop/devicetree/dt_qemu.rst create mode 100644 doc/develop/devicetree/dt_update.rst
-- 2.33.0.1079.g6e70778dc9-goog
-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
Hi Simon
Le mer. 3 nov. 2021 à 02:21, Simon Glass sjg@chromium.org a écrit :
Hi François,
On Wed, 27 Oct 2021 at 14:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Le mer. 27 oct. 2021 à 20:23, Simon Glass sjg@chromium.org a écrit :
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog francois.ozog@linaro.org
wrote:
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog <
francois.ozog@linaro.org> wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that
generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way
to
develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
I am not the only one in disagreement... You just saw Alex Bénée from
Qemu saying the same thing.
I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the
contributors to think that they need to compile the DT for the targeted platforms.
For your advanced scenario, you can still have the dts in the
documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on.
We can add a message to U-Boot indicating where the devicetree came from, perhaps? That might be useful given everything that is going on.
As in this case, quite often in these discussions I struggle to understand what is behind the objection. Is it that your customers are demanding that devicetrees become private, secret data, not included in open-source projects? Or is it just the strange case of QEMU that is informing your thinking? I know of at least one project where the first-stage bootloader produces a devicetree and no one has the source for it. I believe TF-A was created for licensing reasons...so can you be a bit clearer about what the problem actually is?
there are situations where U-Boot must have a dtb. Then those dTB
sources are logically found in the dts directory.
There are situations where U-Boot should not have a dtb. In that case
there should be no element in the dts directory. Otherwise it creates confusion.
Now as you point out, we need “playgrounds” to deal with some situation.
So having examples in an ad-hoc directory, different from dts is fine. I proposed documentation but you may find a better place.
In other words, dts shall host only dt source when U-Boot cannot do but
make a dTB for a platform.
As you have seen in different mail thread (firmware sustainability and
OCP checklist) freedom is important to Linaro and there are no hidden Trojan horse for licensing.
I don't understand what you are getting at with the Trojan horse.
I was referring to your statement that “TFA was created for licensing “ reasons. That’s not the case. It was created to address fragmentation in the secure firmware for which there was no open source at all. SPL is definitely not architected to be the basis of Arm secure firmware { TFA/BL31 (secure monitor), TFA/BL32 (OP-TEE), TFA/SEL2(Hafnium), TFA/SCMI server, SCP…}. That said SPL and TFA/BL2 have similar roles from a 10,000ft perspective. I felt your comment was alluding to TFA was created to promote binary components integration, which is also not the case. Hence my reference to Trojan Horse.
But you have no objection to requiring boards to supply a DT (whether in documentation or arch/arm/dts) to be in U-Boot?
I agree that boards need to properly document their DT. For (a) boards that have defined their standard boot flow to assume U-Boot will only do fix ups and overlays, the DT shall be in the U-Boot documentation part (either in full or pointing to their project documentation), in all other cases (b) it shall be in dts. Boards in the (a) case (may not be exhaustive): Qemu, SystemReady, RPI (it actually assumes it boot a Linux kernel but U-Boot smartly interposes). There may be RISCV boards that comply to EBBR too but I let Heinrich/Atish comment.
If a board is in-tree in U-Boot I would like it to have a devicetree there, at least until we have a better option. At the very least, it MUST be discoverable and it must be possible to undertake U-Boot development easily without a lot of messing around.
You can if you keep two dts directories separate: dts for boards for which U-Boot must have one debug-dts for boards for which U-Boot get the DT at runtime but for
which you want a playground for debug/easier development.
But trying to do any driver / core work for a board where you don't have the devicetree is currently not possible. The devicetree is a core component and being unable to modify it is simply not practical. We are talking here about an option that can be enabled or disabled. In my case I am able to disable it locally and do my development
work.
BTW I've got the bloblist handoff working with a devicetree inside
it,
for qemu_arm. I need to try it on a real board to figure out what the difference is.
That's great news and much needed for stabilizing the inbound ABI
from prior loader to U-Boot. Let's create another thread to discuss this important topic.
My scenario is not all that advanced and I am using qemu_arm to test the bloblist handoff stuff and include it in CI, with a suitable devicetree and a binman node.
Regards, Simon
Cheers
FF
Le mar. 26 oct. 2021 à 02:24, Simon Glass sjg@chromium.org a
écrit :
> > With Ilias' efforts we have dropped OF_PRIOR_STAGE and
OF_HOSTFILE so
> there are only three ways to obtain a devicetree: > > - OF_SEPARATE - the normal way, where the devicetree is built
and
> appended to U-Boot > - OF_EMBED - for development purposes, the devicetree is
embedded in
> the ELF file (also used for EFI) > - OF_BOARD - the board figures it out on its own > > The last one is currently set up so that no devicetree is needed
at all
> in the U-Boot tree. Most boards do provide one, but some don't.
Some
> don't even provide instructions on how to boot on the board. > > The problems with this approach are documented in another patch
in this
> series: "doc: Add documentation about devicetree usage" > > In practice, OF_BOARD is not really distinct from OF_SEPARATE.
Any board
> can obtain its devicetree at runtime, even it is has a devicetree
built
> in U-Boot. This is because U-Boot may be a second-stage
bootloader and its
> caller may have a better idea about the hardware available in the
machine.
> This is the case with a few QEMU boards, for example. > > So it makes no sense to have OF_BOARD as a 'choice'. It should be
an
> option, available with either OF_SEPARATE or OF_EMBED. > > This series makes this change, adding various missing devicetree
files
> (and placeholders) to make the build work. > > Note: If board maintainers are able to add their own patch to add
the
> files, some patches in this series can be dropped. > > It also provides a few qemu clean-ups discovered along the way. > > Note: This breaks the qemu-riscv64_spl test, which still needs > investigation. > > [1]
https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sj...
> > Changes in v5: > - Bring into the OF_BOARD series > - Rebase to master and drop mention of OF_PRIOR_STAGE, since
removed
> - Refer to the 'control' DTB in the first paragraph > - Use QEMU instead of qemu > - Merge RISC-V and ARM patches since they are similar > - Add new patches to clean up fdtdec_setup() and surrounds > > Changes in v3: > - Clarify the 'bug' refered to at the top > - Reword 'This means that there' paragraph to explain
U-Boot-specific things
> - Move to doc/develop/devicetree now that OF_CONTROL is in the
docs
> > Changes in v2: > - Fix typos per Sean (thank you!) and a few others > - Add a 'Use of U-Boot /config node' section > - Drop mention of dm-verity since that actually uses the kernel
cmdline
> - Explain that OF_BOARD will still work after these changes (in > 'Once this bug is fixed...' paragraph) > - Expand a bit on the reason why the 'Current situation' is bad > - Clarify in a second place that Linux and U-Boot use the same
devicetree
> in 'To be clear, while U-Boot...' > - Expand on why we should have rules for other projects in > 'Devicetree in another project' > - Add a comment as to why devicetree in U-Boot is not 'bad design' > - Reword 'in-tree U-Boot devicetree' to 'devicetree source in
U-Boot'
> - Rewrite 'Devicetree generated on-the-fly in another project' to
cover
> points raised on v1 > - Add 'Why does U-Boot have its nodes and properties?' > - Add 'Why not have two devicetrees?' > > Ilias Apalodimas (1): > sandbox: Remove OF_HOSTFILE > > Simon Glass (25): > doc: Add documentation about devicetree usage > arm: qemu: Mention -nographic in the docs > arm: riscv: qemu: Explain how to extract the generated dt > arm: qemu: Add a devicetree file for qemu_arm > arm: qemu: Add a devicetree file for qemu_arm64 > riscv: qemu: Add devicetree files for qemu_riscv32/64 > arm: rpi: Add a devicetree file for rpi_4 > arm: vexpress: Add a devicetree file for juno > arm: xenguest_arm64: Add a fake devicetree file > arm: octeontx: Add a fake devicetree file > arm: xilinx_versal_virt: Add a devicetree file > arm: bcm7xxx: Add a devicetree file > arm: qemu-ppce500: Add a devicetree file > arm: highbank: Add a fake devicetree file > fdt: Make OF_BOARD a bool option > Drop CONFIG_BINMAN_STANDALONE_FDT > doc: Update info on devicetree update > fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() > fdt: Drop #ifdefs with MULTI_DTB_FIT > fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() > fdt: Drop #ifdef around board_fdt_blob_setup() > fdt: Use if() for fdtcontroladdr check > fdt: Drop OF_CONTROL check in fdtdec_setup() > fdt: Drop remaining preprocessor macros in fdtdec_setup() > fdt: Don't call board_fdt_blob_setup() without OF_BOARD > > Makefile | 7 +- > arch/arm/dts/Makefile | 20 +- > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958
+++++++++++++++++++++
> arch/arm/dts/bcm7xxx.dts | 15 + > arch/arm/dts/highbank.dts | 14 + > arch/arm/dts/juno-r2.dts | 1038 +++++++++++ > arch/arm/dts/octeontx.dts | 14 + > arch/arm/dts/qemu-arm.dts | 402 +++++ > arch/arm/dts/qemu-arm64.dts | 381 ++++ > arch/arm/dts/xenguest-arm64.dts | 15 + > arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ > arch/powerpc/dts/Makefile | 1 + > arch/powerpc/dts/qemu-ppce500.dts | 264 +++ > arch/riscv/dts/Makefile | 2 +- > arch/riscv/dts/qemu-virt.dts | 8 - > arch/riscv/dts/qemu-virt32.dts | 217 +++ > arch/riscv/dts/qemu-virt64.dts | 217 +++ > arch/sandbox/cpu/cpu.c | 21 +- > arch/sandbox/include/asm/u-boot-sandbox.h | 8 - > configs/bcm7260_defconfig | 1 + > configs/bcm7445_defconfig | 1 + > configs/highbank_defconfig | 2 +- > configs/octeontx2_95xx_defconfig | 1 + > configs/octeontx2_96xx_defconfig | 1 + > configs/octeontx_81xx_defconfig | 1 + > configs/octeontx_83xx_defconfig | 1 + > configs/qemu-ppce500_defconfig | 2 + > configs/qemu-riscv32_defconfig | 1 + > configs/qemu-riscv32_smode_defconfig | 1 + > configs/qemu-riscv32_spl_defconfig | 4 +- > configs/qemu-riscv64_defconfig | 1 + > configs/qemu-riscv64_smode_defconfig | 1 + > configs/qemu-riscv64_spl_defconfig | 3 +- > configs/qemu_arm64_defconfig | 1 + > configs/qemu_arm_defconfig | 1 + > configs/rpi_4_32b_defconfig | 1 + > configs/rpi_4_defconfig | 1 + > configs/rpi_arm64_defconfig | 1 + > configs/sandbox64_defconfig | 2 +- > configs/sandbox_defconfig | 2 +- > configs/sandbox_flattree_defconfig | 2 +- > configs/sandbox_noinst_defconfig | 2 +- > configs/sandbox_spl_defconfig | 2 +- > configs/tools-only_defconfig | 2 +- > configs/vexpress_aemv8a_juno_defconfig | 1 + > configs/xenguest_arm64_defconfig | 1 + > configs/xilinx_versal_virt_defconfig | 1 + > doc/board/emulation/qemu-arm.rst | 10 +- > doc/board/emulation/qemu-riscv.rst | 3 + > doc/develop/devicetree/control.rst | 7 +- > doc/develop/devicetree/dt_qemu.rst | 48 + > doc/develop/devicetree/dt_update.rst | 498 ++++++ > doc/develop/devicetree/index.rst | 2 + > dts/Kconfig | 37 +- > include/asm-generic/global_data.h | 8 + > include/fdtdec.h | 21 +- > lib/fdtdec.c | 116 +- > scripts/Makefile.spl | 4 +- > tools/binman/binman.rst | 20 - > 59 files changed, 5560 insertions(+), 164 deletions(-) > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > create mode 100644 arch/arm/dts/bcm7xxx.dts > create mode 100644 arch/arm/dts/highbank.dts > create mode 100644 arch/arm/dts/juno-r2.dts > create mode 100644 arch/arm/dts/octeontx.dts > create mode 100644 arch/arm/dts/qemu-arm.dts > create mode 100644 arch/arm/dts/qemu-arm64.dts > create mode 100644 arch/arm/dts/xenguest-arm64.dts > create mode 100644 arch/arm/dts/xilinx-versal-virt.dts > create mode 100644 arch/powerpc/dts/qemu-ppce500.dts > delete mode 100644 arch/riscv/dts/qemu-virt.dts > create mode 100644 arch/riscv/dts/qemu-virt32.dts > create mode 100644 arch/riscv/dts/qemu-virt64.dts > create mode 100644 doc/develop/devicetree/dt_qemu.rst > create mode 100644 doc/develop/devicetree/dt_update.rst > > -- > 2.33.0.1079.g6e70778dc9-goog
>
François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
From: Simon Glass sjg@chromium.org Date: Wed, 27 Oct 2021 12:23:21 -0600
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog francois.ozog@linaro.org wrote:
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on.
Until. The Raspberry Pi foundation releases a new firmware that configures the hardware differently such that the addresses in the U-Boot devicetree are wrong and nothing works anymore. Can't speak for the rpi 1, but this has happened in the past for the rpi 2 and 3 as well as more recently on the rpi 4.
We can add a message to U-Boot indicating where the devicetree came from, perhaps? That might be useful given everything that is going on.
As in this case, quite often in these discussions I struggle to understand what is behind the objection. Is it that your customers are demanding that devicetrees become private, secret data, not included in open-source projects? Or is it just the strange case of QEMU that is informing your thinking? I know of at least one project where the first-stage bootloader produces a devicetree and no one has the source for it. I believe TF-A was created for licensing reasons...so can you be a bit clearer about what the problem actually is? If a board is in-tree in U-Boot I would like it to have a devicetree there, at least until we have a better option. At the very least, it MUST be discoverable and it must be possible to undertake U-Boot development easily without a lot of messing around.
How many people are there out there that work on U-Boot that don't have a Linux source tree checked out? Even I have several of those lying around on my development systems and I am an OpenBSD developer ;).
Hi Mark,
On Wed, 27 Oct 2021 at 16:30, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 27 Oct 2021 12:23:21 -0600
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog francois.ozog@linaro.org wrote:
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on.
Until. The Raspberry Pi foundation releases a new firmware that configures the hardware differently such that the addresses in the U-Boot devicetree are wrong and nothing works anymore. Can't speak for the rpi 1, but this has happened in the past for the rpi 2 and 3 as well as more recently on the rpi 4.
So I update my SD card with a new private-binary bootloader and things stop working? I think I can narrow that one down :-)
We can add a message to U-Boot indicating where the devicetree came from, perhaps? That might be useful given everything that is going on.
As in this case, quite often in these discussions I struggle to understand what is behind the objection. Is it that your customers are demanding that devicetrees become private, secret data, not included in open-source projects? Or is it just the strange case of QEMU that is informing your thinking? I know of at least one project where the first-stage bootloader produces a devicetree and no one has the source for it. I believe TF-A was created for licensing reasons...so can you be a bit clearer about what the problem actually is? If a board is in-tree in U-Boot I would like it to have a devicetree there, at least until we have a better option. At the very least, it MUST be discoverable and it must be possible to undertake U-Boot development easily without a lot of messing around.
How many people are there out there that work on U-Boot that don't have a Linux source tree checked out? Even I have several of those lying around on my development systems and I am an OpenBSD developer ;).
So it is OK to have the DT in Linux but not in U-Boot? I don't even know what to say that. How does that square with your point above?
I am not talking about disabling OF_BOARD, just making it *possible* to do so.
Regards, Simon
From: Simon Glass sjg@chromium.org Date: Tue, 2 Nov 2021 19:20:51 -0600
Hi Mark,
On Wed, 27 Oct 2021 at 16:30, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 27 Oct 2021 12:23:21 -0600
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog francois.ozog@linaro.org wrote:
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on.
Until. The Raspberry Pi foundation releases a new firmware that configures the hardware differently such that the addresses in the U-Boot devicetree are wrong and nothing works anymore. Can't speak for the rpi 1, but this has happened in the past for the rpi 2 and 3 as well as more recently on the rpi 4.
So I update my SD card with a new private-binary bootloader and things stop working? I think I can narrow that one down :-)
We can add a message to U-Boot indicating where the devicetree came from, perhaps? That might be useful given everything that is going on.
As in this case, quite often in these discussions I struggle to understand what is behind the objection. Is it that your customers are demanding that devicetrees become private, secret data, not included in open-source projects? Or is it just the strange case of QEMU that is informing your thinking? I know of at least one project where the first-stage bootloader produces a devicetree and no one has the source for it. I believe TF-A was created for licensing reasons...so can you be a bit clearer about what the problem actually is? If a board is in-tree in U-Boot I would like it to have a devicetree there, at least until we have a better option. At the very least, it MUST be discoverable and it must be possible to undertake U-Boot development easily without a lot of messing around.
How many people are there out there that work on U-Boot that don't have a Linux source tree checked out? Even I have several of those lying around on my development systems and I am an OpenBSD developer ;).
So it is OK to have the DT in Linux but not in U-Boot? I don't even know what to say that. How does that square with your point above?
Ideally the DT's and DT binding would move out of the Linux tree and into a repository of their own. But until that is the case, the Linux tree is the source of truth.
I am not talking about disabling OF_BOARD, just making it *possible* to do so.
And I don't think it makes sense to do so on most boards that have OF_BOARD in their config.
On Wed, Nov 03, 2021 at 09:22:58AM +0100, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Tue, 2 Nov 2021 19:20:51 -0600
Hi Mark,
On Wed, 27 Oct 2021 at 16:30, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 27 Oct 2021 12:23:21 -0600
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog francois.ozog@linaro.org wrote:
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote: > > Hi Simon > > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on.
Until. The Raspberry Pi foundation releases a new firmware that configures the hardware differently such that the addresses in the U-Boot devicetree are wrong and nothing works anymore. Can't speak for the rpi 1, but this has happened in the past for the rpi 2 and 3 as well as more recently on the rpi 4.
So I update my SD card with a new private-binary bootloader and things stop working? I think I can narrow that one down :-)
We can add a message to U-Boot indicating where the devicetree came from, perhaps? That might be useful given everything that is going on.
As in this case, quite often in these discussions I struggle to understand what is behind the objection. Is it that your customers are demanding that devicetrees become private, secret data, not included in open-source projects? Or is it just the strange case of QEMU that is informing your thinking? I know of at least one project where the first-stage bootloader produces a devicetree and no one has the source for it. I believe TF-A was created for licensing reasons...so can you be a bit clearer about what the problem actually is? If a board is in-tree in U-Boot I would like it to have a devicetree there, at least until we have a better option. At the very least, it MUST be discoverable and it must be possible to undertake U-Boot development easily without a lot of messing around.
How many people are there out there that work on U-Boot that don't have a Linux source tree checked out? Even I have several of those lying around on my development systems and I am an OpenBSD developer ;).
So it is OK to have the DT in Linux but not in U-Boot? I don't even know what to say that. How does that square with your point above?
Ideally the DT's and DT binding would move out of the Linux tree and into a repository of their own. But until that is the case, the Linux tree is the source of truth.
Yes, and this is a long known and slowly in progress kinda-sorta thing. A few more people helping to review things, etc, are always appreciated by upstream.
I am not talking about disabling OF_BOARD, just making it *possible* to do so.
And I don't think it makes sense to do so on most boards that have OF_BOARD in their config.
It should probably close to never be done, unless it's some case where it's crazy-hard to update the device tree correctly for the platform. So it's not a problem on Pi as it's just on the FAT32 partition right there, it's not a problem on Apple M1 as ..however you do it.., and so on.
I can almost hear the argument from here about "but I'm doing some work for U-Boot and need to add..." and that's where we need to figure out what to do next. Yes, we likely need to have some bindings of our own, and developing those AND pushing them upstream will require iterating here. So the developer point of view of how do I whack things to supply my own is valid. But it's not the default use case. The default use case is building the firmware that users rarely see, because their system boots to the OS and they get down to using their system.
Hi Tom,
On Wed, 3 Nov 2021 at 10:02, Tom Rini trini@konsulko.com wrote:
On Wed, Nov 03, 2021 at 09:22:58AM +0100, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Tue, 2 Nov 2021 19:20:51 -0600
Hi Mark,
On Wed, 27 Oct 2021 at 16:30, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 27 Oct 2021 12:23:21 -0600
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog francois.ozog@linaro.org wrote:
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote: > > Hi François, > > On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote: > > > > Hi Simon > > > > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. > > I think we are going to have to disagree on this one. I actually used > the qemu one in testing/development recently. We have to have a way to > develop in-tree with U-Boot. It does not impinge on any of your use > cases, so far as I know.
I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on.
Until. The Raspberry Pi foundation releases a new firmware that configures the hardware differently such that the addresses in the U-Boot devicetree are wrong and nothing works anymore. Can't speak for the rpi 1, but this has happened in the past for the rpi 2 and 3 as well as more recently on the rpi 4.
So I update my SD card with a new private-binary bootloader and things stop working? I think I can narrow that one down :-)
We can add a message to U-Boot indicating where the devicetree came from, perhaps? That might be useful given everything that is going on.
As in this case, quite often in these discussions I struggle to understand what is behind the objection. Is it that your customers are demanding that devicetrees become private, secret data, not included in open-source projects? Or is it just the strange case of QEMU that is informing your thinking? I know of at least one project where the first-stage bootloader produces a devicetree and no one has the source for it. I believe TF-A was created for licensing reasons...so can you be a bit clearer about what the problem actually is? If a board is in-tree in U-Boot I would like it to have a devicetree there, at least until we have a better option. At the very least, it MUST be discoverable and it must be possible to undertake U-Boot development easily without a lot of messing around.
How many people are there out there that work on U-Boot that don't have a Linux source tree checked out? Even I have several of those lying around on my development systems and I am an OpenBSD developer ;).
So it is OK to have the DT in Linux but not in U-Boot? I don't even know what to say that. How does that square with your point above?
Ideally the DT's and DT binding would move out of the Linux tree and into a repository of their own. But until that is the case, the Linux tree is the source of truth.
Yes, and this is a long known and slowly in progress kinda-sorta thing. A few more people helping to review things, etc, are always appreciated by upstream.
I am not talking about disabling OF_BOARD, just making it *possible* to do so.
And I don't think it makes sense to do so on most boards that have OF_BOARD in their config.
It should probably close to never be done, unless it's some case where it's crazy-hard to update the device tree correctly for the platform. So it's not a problem on Pi as it's just on the FAT32 partition right there, it's not a problem on Apple M1 as ..however you do it.., and so on.
I can almost hear the argument from here about "but I'm doing some work for U-Boot and need to add..." and that's where we need to figure out what to do next. Yes, we likely need to have some bindings of our own, and developing those AND pushing them upstream will require iterating here. So the developer point of view of how do I whack things to supply my own is valid. But it's not the default use case. The default use case is building the firmware that users rarely see, because their system boots to the OS and they get down to using their system.
I believe that OF_BOARD needs to become a runtime option. If not, there is no way to use the U-Boot deivcetree. I cannot build it in-tree. I cannot make U-Boot use it. It's just a mess. So we are supposed to run dtc manually to ge tthe DT, then copy it manually, then deal with the include files it needs and the C preprocessing it needs for the bindings? Why make this so hard? It just makes no sense to me.
We are making this 'odd' case into the main case. It isn't. If it becomes it one day, I hope we are in a better place with devicetree. Upstreaming bindings is one thing, but we need to develop and test, first.
I really don't understand why this is generating so much discussion. How can we get this moving?
What is so wrong with having a devicetree in U-Boot for building? Why are these boards so special? And what problem does it cause? The only one I have heard is confusion, which I think I have addressed.
Regards, SImon
From: Simon Glass sjg@chromium.org Date: Wed, 3 Nov 2021 10:45:42 -0600
Hi Tom,
On Wed, 3 Nov 2021 at 10:02, Tom Rini trini@konsulko.com wrote:
On Wed, Nov 03, 2021 at 09:22:58AM +0100, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Tue, 2 Nov 2021 19:20:51 -0600
Hi Mark,
On Wed, 27 Oct 2021 at 16:30, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 27 Oct 2021 12:23:21 -0600
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog francois.ozog@linaro.org wrote: > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote: >> >> Hi François, >> >> On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote: >> > >> > Hi Simon >> > >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. >> >> I think we are going to have to disagree on this one. I actually used >> the qemu one in testing/development recently. We have to have a way to >> develop in-tree with U-Boot. It does not impinge on any of your use >> cases, so far as I know. > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. > I understand the advanced debug/development scenario you mention. > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on.
Until. The Raspberry Pi foundation releases a new firmware that configures the hardware differently such that the addresses in the U-Boot devicetree are wrong and nothing works anymore. Can't speak for the rpi 1, but this has happened in the past for the rpi 2 and 3 as well as more recently on the rpi 4.
So I update my SD card with a new private-binary bootloader and things stop working? I think I can narrow that one down :-)
We can add a message to U-Boot indicating where the devicetree came from, perhaps? That might be useful given everything that is going on.
As in this case, quite often in these discussions I struggle to understand what is behind the objection. Is it that your customers are demanding that devicetrees become private, secret data, not included in open-source projects? Or is it just the strange case of QEMU that is informing your thinking? I know of at least one project where the first-stage bootloader produces a devicetree and no one has the source for it. I believe TF-A was created for licensing reasons...so can you be a bit clearer about what the problem actually is? If a board is in-tree in U-Boot I would like it to have a devicetree there, at least until we have a better option. At the very least, it MUST be discoverable and it must be possible to undertake U-Boot development easily without a lot of messing around.
How many people are there out there that work on U-Boot that don't have a Linux source tree checked out? Even I have several of those lying around on my development systems and I am an OpenBSD developer ;).
So it is OK to have the DT in Linux but not in U-Boot? I don't even know what to say that. How does that square with your point above?
Ideally the DT's and DT binding would move out of the Linux tree and into a repository of their own. But until that is the case, the Linux tree is the source of truth.
Yes, and this is a long known and slowly in progress kinda-sorta thing. A few more people helping to review things, etc, are always appreciated by upstream.
I am not talking about disabling OF_BOARD, just making it *possible* to do so.
And I don't think it makes sense to do so on most boards that have OF_BOARD in their config.
It should probably close to never be done, unless it's some case where it's crazy-hard to update the device tree correctly for the platform. So it's not a problem on Pi as it's just on the FAT32 partition right there, it's not a problem on Apple M1 as ..however you do it.., and so on.
I can almost hear the argument from here about "but I'm doing some work for U-Boot and need to add..." and that's where we need to figure out what to do next. Yes, we likely need to have some bindings of our own, and developing those AND pushing them upstream will require iterating here. So the developer point of view of how do I whack things to supply my own is valid. But it's not the default use case. The default use case is building the firmware that users rarely see, because their system boots to the OS and they get down to using their system.
I believe that OF_BOARD needs to become a runtime option.
I'm looking at this from the perspective of the Apple M1. But please no. That would only tempt users to flip the switch resulting in a non-bootable system.
If not, there is no way to use the U-Boot deivcetree.
There is no way to use the U-Boot devicetree on these boards, because it is incomplete. And the code to fill in the missing bits lives somewhere else.
I cannot build it in-tree. I cannot make U-Boot use it. It's just a mess.
Correct. So putting the device tree in the U-Boot repository makes no sense.
So we are supposed to run dtc manually to ge tthe DT, then copy it manually, then deal with the include files it needs and the C preprocessing it needs for the bindings?
Of course not. The repository that contains the DT sources will have the infrastructure to do that for you.
We are making this 'odd' case into the main case. It isn't. If it becomes it one day, I hope we are in a better place with devicetree. Upstreaming bindings is one thing, but we need to develop and test, first.
And the way I test things is that I build the device tree, load it together with the U-Boot binary into m1n1 over serial or USB and run it.
I really don't understand why this is generating so much discussion. How can we get this moving?
Maybe because you're continuously telling is we're doing it wrong and must do it your way?
What is so wrong with having a devicetree in U-Boot for building?
This sounds like you want to make having a devicetree in the actual U-Boot a hard requirement. And that makes no sense to me for the Apple M1 systems.
Why are these boards so special? And what problem does it cause? The only one I have heard is confusion, which I think I have addressed.
They're not special; just different.
On Tue, Nov 02, 2021 at 07:20:51PM -0600, Simon Glass wrote:
Hi Mark,
On Wed, 27 Oct 2021 at 16:30, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 27 Oct 2021 12:23:21 -0600
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog francois.ozog@linaro.org wrote:
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on.
Until. The Raspberry Pi foundation releases a new firmware that configures the hardware differently such that the addresses in the U-Boot devicetree are wrong and nothing works anymore. Can't speak for the rpi 1, but this has happened in the past for the rpi 2 and 3 as well as more recently on the rpi 4.
So I update my SD card with a new private-binary bootloader and things stop working? I think I can narrow that one down :-)
Well, wait, no, this is the point. You can just not update your board. But that all of the users running a more recent release are now broken is the problem. It's already an opt-in thing to use U-Boot on Pis and if we make it even more annoying to be recent, there'll be even less reason to use U-Boot over over the Pi+TianoCore if you want anything more fancy that direct-to-Linux booting.
Hi Tom,
On Wed, 3 Nov 2021 at 09:56, Tom Rini trini@konsulko.com wrote:
On Tue, Nov 02, 2021 at 07:20:51PM -0600, Simon Glass wrote:
Hi Mark,
On Wed, 27 Oct 2021 at 16:30, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 27 Oct 2021 12:23:21 -0600
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog francois.ozog@linaro.org wrote:
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote: > > Hi Simon > > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on.
Until. The Raspberry Pi foundation releases a new firmware that configures the hardware differently such that the addresses in the U-Boot devicetree are wrong and nothing works anymore. Can't speak for the rpi 1, but this has happened in the past for the rpi 2 and 3 as well as more recently on the rpi 4.
So I update my SD card with a new private-binary bootloader and things stop working? I think I can narrow that one down :-)
Well, wait, no, this is the point. You can just not update your board. But that all of the users running a more recent release are now broken is the problem. It's already an opt-in thing to use U-Boot on Pis and if we make it even more annoying to be recent, there'll be even less reason to use U-Boot over over the Pi+TianoCore if you want anything more fancy that direct-to-Linux booting.
This is all totally in the weeds at this point. What are you referring to?
I'm talking about turning off OF_BOARD in my private build of U-Boot so that it picks up the devicetree built with U-Boot. I thought that was what Mark was saying...?
Regards, Simon
Hi,
On 27.10.2021 17.08, Simon Glass wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
How about having the file just contain a single line
#include <generated-qemu-arm.dts>
... where this generated-*.dts is not checked to the source tree. Then of course comments on how to generate it via qemu -dumpdtb + dtc, with appropriate precautions (ie. must be regenerated if qemu command line is changed or qemu is upgraded), intended use case, and so forth.
On Wed, Oct 27, 2021 at 06:36:12PM +0300, Tuomas Tynkkynen wrote:
Hi,
On 27.10.2021 17.08, Simon Glass wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
How about having the file just contain a single line
#include <generated-qemu-arm.dts>
... where this generated-*.dts is not checked to the source tree. Then of course comments on how to generate it via qemu -dumpdtb + dtc, with appropriate precautions (ie. must be regenerated if qemu command line is changed or qemu is upgraded), intended use case, and so forth.
That seems like it would help the development workflow, yes.
On Wed, Oct 27, 2021 at 08:08:19AM -0600, Simon Glass wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@linaro.org wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
I think we are going to have to disagree on this one.
I'm not convinced either that we want or should have checked in device trees for all of the platforms where the source of truth is elsewhere.
I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know.
It's certainly true that the "edit, rebuild, re-pass the dtb" cycle has been sub-optimal since inception. It's not even U-Boot related. I can count a number of times recently working with customers and just for Linux, having to spend a number of hours on the edit, rebuild, really make sure it gets populated where it's supposed to go, verify that yes really our modified dtb is the one present cycle. It's a very generic problem.
On Wed, Oct 27, 2021 at 08:08:19AM -0600, Simon Glass wrote:
[snip]
But trying to do any driver / core work for a board where you don't have the devicetree is currently not possible. The devicetree is a core component and being unable to modify it is simply not practical. We are talking here about an option that can be enabled or disabled. In my case I am able to disable it locally and do my development work.
This certainly is an area where it's easier to work on arm32 platforms, where we aren't getting the DT passed in, than arm64, where we almost certainly are.
Hi Simon
I don't know if this is correct etiquette but at this moment it feels just right to do this: The problem is not confusion it is that the patch set goes in a direction that makes no sense.
On Tue, 26 Oct 2021 at 02:24, Simon Glass sjg@chromium.org wrote:
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so there are only three ways to obtain a devicetree:
- OF_SEPARATE - the normal way, where the devicetree is built and appended to U-Boot
- OF_EMBED - for development purposes, the devicetree is embedded in the ELF file (also used for EFI)
- OF_BOARD - the board figures it out on its own
YES! perfect!
Default config for boards like RPI4, Qemu and SystemReady ones should be OF_BOARD. There may be an override for the advanced developer that need a playground for those boards; with a warning: "for debug purposes, turning on this option for this platform assumes you know exactly what you are doing."
The last one is currently set up so that no devicetree is needed at all
in the U-Boot tree.
Rightfully as you write below "it comes from an entity that "have a better idea about the hardware".
Most boards do provide one, but some don't. Some don't even provide instructions on how to boot on the board.
That is a documentation problem.
The problems with this approach are documented in another patch in this series: "doc: Add documentation about devicetree usage"
In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board can obtain its devicetree at runtime, even it is has a devicetree built in U-Boot.
That statement is I think the start of problems.
This is because U-Boot may be a second-stage bootloader and its caller may have a better idea about the hardware available in the machine. This is the case with a few QEMU boards, for example.
YES! exactly. Why would you ever embed a DT in U-Boot if it comes from an
entity that "have a better idea about the hardware"? For advanced debugging yes. Otherwise no reasons.
So it makes no sense to have OF_BOARD as a 'choice'. It should be an option, available with either OF_SEPARATE or OF_EMBED.
Problem starts to grow.
This series makes this change, adding various missing devicetree files (and placeholders) to make the build work.
Note: If board maintainers are able to add their own patch to add the files, some patches in this series can be dropped.
It also provides a few qemu clean-ups discovered along the way.
Note: This breaks the qemu-riscv64_spl test, which still needs investigation.
[1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sj...
Changes in v5:
- Bring into the OF_BOARD series
- Rebase to master and drop mention of OF_PRIOR_STAGE, since removed
- Refer to the 'control' DTB in the first paragraph
- Use QEMU instead of qemu
- Merge RISC-V and ARM patches since they are similar
- Add new patches to clean up fdtdec_setup() and surrounds
Changes in v3:
- Clarify the 'bug' refered to at the top
- Reword 'This means that there' paragraph to explain U-Boot-specific
things
- Move to doc/develop/devicetree now that OF_CONTROL is in the docs
Changes in v2:
- Fix typos per Sean (thank you!) and a few others
- Add a 'Use of U-Boot /config node' section
- Drop mention of dm-verity since that actually uses the kernel cmdline
- Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph)
- Expand a bit on the reason why the 'Current situation' is bad
- Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...'
- Expand on why we should have rules for other projects in 'Devicetree in another project'
- Add a comment as to why devicetree in U-Boot is not 'bad design'
- Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
- Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1
- Add 'Why does U-Boot have its nodes and properties?'
- Add 'Why not have two devicetrees?'
Ilias Apalodimas (1): sandbox: Remove OF_HOSTFILE
Simon Glass (25): doc: Add documentation about devicetree usage arm: qemu: Mention -nographic in the docs arm: riscv: qemu: Explain how to extract the generated dt arm: qemu: Add a devicetree file for qemu_arm arm: qemu: Add a devicetree file for qemu_arm64 riscv: qemu: Add devicetree files for qemu_riscv32/64 arm: rpi: Add a devicetree file for rpi_4 arm: vexpress: Add a devicetree file for juno arm: xenguest_arm64: Add a fake devicetree file arm: octeontx: Add a fake devicetree file arm: xilinx_versal_virt: Add a devicetree file arm: bcm7xxx: Add a devicetree file arm: qemu-ppce500: Add a devicetree file arm: highbank: Add a fake devicetree file fdt: Make OF_BOARD a bool option Drop CONFIG_BINMAN_STANDALONE_FDT doc: Update info on devicetree update fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() fdt: Drop #ifdefs with MULTI_DTB_FIT fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() fdt: Drop #ifdef around board_fdt_blob_setup() fdt: Use if() for fdtcontroladdr check fdt: Drop OF_CONTROL check in fdtdec_setup() fdt: Drop remaining preprocessor macros in fdtdec_setup() fdt: Don't call board_fdt_blob_setup() without OF_BOARD
Makefile | 7 +- arch/arm/dts/Makefile | 20 +- arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 +++++++++++++++++++++ arch/arm/dts/bcm7xxx.dts | 15 + arch/arm/dts/highbank.dts | 14 + arch/arm/dts/juno-r2.dts | 1038 +++++++++++ arch/arm/dts/octeontx.dts | 14 + arch/arm/dts/qemu-arm.dts | 402 +++++ arch/arm/dts/qemu-arm64.dts | 381 ++++ arch/arm/dts/xenguest-arm64.dts | 15 + arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/qemu-ppce500.dts | 264 +++ arch/riscv/dts/Makefile | 2 +- arch/riscv/dts/qemu-virt.dts | 8 - arch/riscv/dts/qemu-virt32.dts | 217 +++ arch/riscv/dts/qemu-virt64.dts | 217 +++ arch/sandbox/cpu/cpu.c | 21 +- arch/sandbox/include/asm/u-boot-sandbox.h | 8 - configs/bcm7260_defconfig | 1 + configs/bcm7445_defconfig | 1 + configs/highbank_defconfig | 2 +- configs/octeontx2_95xx_defconfig | 1 + configs/octeontx2_96xx_defconfig | 1 + configs/octeontx_81xx_defconfig | 1 + configs/octeontx_83xx_defconfig | 1 + configs/qemu-ppce500_defconfig | 2 + configs/qemu-riscv32_defconfig | 1 + configs/qemu-riscv32_smode_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 4 +- configs/qemu-riscv64_defconfig | 1 + configs/qemu-riscv64_smode_defconfig | 1 + configs/qemu-riscv64_spl_defconfig | 3 +- configs/qemu_arm64_defconfig | 1 + configs/qemu_arm_defconfig | 1 + configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + configs/sandbox64_defconfig | 2 +- configs/sandbox_defconfig | 2 +- configs/sandbox_flattree_defconfig | 2 +- configs/sandbox_noinst_defconfig | 2 +- configs/sandbox_spl_defconfig | 2 +- configs/tools-only_defconfig | 2 +- configs/vexpress_aemv8a_juno_defconfig | 1 + configs/xenguest_arm64_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + doc/board/emulation/qemu-arm.rst | 10 +- doc/board/emulation/qemu-riscv.rst | 3 + doc/develop/devicetree/control.rst | 7 +- doc/develop/devicetree/dt_qemu.rst | 48 + doc/develop/devicetree/dt_update.rst | 498 ++++++ doc/develop/devicetree/index.rst | 2 + dts/Kconfig | 37 +- include/asm-generic/global_data.h | 8 + include/fdtdec.h | 21 +- lib/fdtdec.c | 116 +- scripts/Makefile.spl | 4 +- tools/binman/binman.rst | 20 - 59 files changed, 5560 insertions(+), 164 deletions(-) create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts create mode 100644 arch/arm/dts/bcm7xxx.dts create mode 100644 arch/arm/dts/highbank.dts create mode 100644 arch/arm/dts/juno-r2.dts create mode 100644 arch/arm/dts/octeontx.dts create mode 100644 arch/arm/dts/qemu-arm.dts create mode 100644 arch/arm/dts/qemu-arm64.dts create mode 100644 arch/arm/dts/xenguest-arm64.dts create mode 100644 arch/arm/dts/xilinx-versal-virt.dts create mode 100644 arch/powerpc/dts/qemu-ppce500.dts delete mode 100644 arch/riscv/dts/qemu-virt.dts create mode 100644 arch/riscv/dts/qemu-virt32.dts create mode 100644 arch/riscv/dts/qemu-virt64.dts create mode 100644 doc/develop/devicetree/dt_qemu.rst create mode 100644 doc/develop/devicetree/dt_update.rst
-- 2.33.0.1079.g6e70778dc9-goog
participants (7)
-
François Ozog -
Ilias Apalodimas -
Mark Kettenis -
Peter Maydell -
Simon Glass -
Tom Rini -
Tuomas Tynkkynen