* [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-10-26 0:23 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Linus Walleij, Thomas Fitzsimmons, qemu-devel, Sean Anderson,
Mark Kettenis, Tom Rini, Stephen Warren, Oleksandr Andrushchenko,
Heinrich Schuchardt, Michal Simek, Jerry Van Baren,
Stephen Warren, Andre Przywara, Alexander Graf,
Anastasiia Lukianenko, Albert Aribaud, Matthias Brugger,
Simon Glass, Ilias Apalodimas, Aaron Williams, Tuomas Tynkkynen,
Bin Meng
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-sjg@chromium.org/
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
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH v5 01/26] sandbox: Remove OF_HOSTFILE
2021-10-26 0:23 ` Simon Glass
(?)
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass
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
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-26 0:23 ` Simon Glass
(?)
(?)
@ 2021-10-26 0:23 ` Simon Glass
2021-10-26 14:06 ` Ilias Apalodimas
2021-10-26 14:31 ` François Ozog
-1 siblings, 2 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Marcel Ziswiler
At present some of the ideas and techniques behind devicetree in U-Boot
are assumed, implied or unsaid. Add some documentation to cover how
devicetree is build, how it can be modified and the rules about using
the various CONFIG_OF_... options.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
This patch attracted quite a bit of discussion here:
https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-sjg@chromium.org/
I have not included the text suggested by François. While I agree that
it would be useful to have an introduction in this space, I do not agree
that we should have two devicetrees or that U-Boot should not have its own
things in the devicetree, so it is not clear to me what we should actually
write.
The 'Devicetree Control in U-Boot' docs were recently merged and these
provide some base info, for now.
Changes in 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-deymo@google.com/
+.. _`TF-A`: https://www.trustedfirmware.org/projects/tf-a
+.. _`QEMU ARM`: https://github.com/qemu/qemu/blob/master/hw/arm/virt.c
+.. _`QEMU RISC-V`: https://github.com/qemu/qemu/blob/master/hw/riscv/virt.c
+.. _`/chosen node`: https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
+.. _fdt_add_pubkey: https://patchwork.ozlabs.org/project/uboot/list/?series=157843&state=*
+.. _dtspec: https://www.devicetree.org/specifications/
diff --git a/doc/develop/devicetree/index.rst b/doc/develop/devicetree/index.rst
index fa5db3eb76e..b5b33dfea0f 100644
--- a/doc/develop/devicetree/index.rst
+++ b/doc/develop/devicetree/index.rst
@@ -11,3 +11,4 @@ build-time and runtime configuration.
intro
control
+ dt_update
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-26 0:23 ` [PATCH v5 02/26] doc: Add documentation about devicetree usage Simon Glass
@ 2021-10-26 14:06 ` Ilias Apalodimas
2021-10-26 15:27 ` Simon Glass
2021-10-26 14:31 ` François Ozog
1 sibling, 1 reply; 144+ messages in thread
From: Ilias Apalodimas @ 2021-10-26 14:06 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Heinrich Schuchardt,
Tom Rini, Sean Anderson, Marcel Ziswiler
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-26 14:06 ` Ilias Apalodimas
@ 2021-10-26 15:27 ` Simon Glass
2021-10-27 9:29 ` Ilias Apalodimas
0 siblings, 1 reply; 144+ messages in thread
From: Simon Glass @ 2021-10-26 15:27 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: U-Boot Mailing List, Mark Kettenis, Heinrich Schuchardt,
Tom Rini, Sean Anderson, Marcel Ziswiler
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-26 15:27 ` Simon Glass
@ 2021-10-27 9:29 ` Ilias Apalodimas
0 siblings, 0 replies; 144+ messages in thread
From: Ilias Apalodimas @ 2021-10-27 9:29 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Heinrich Schuchardt,
Tom Rini, Sean Anderson, Marcel Ziswiler
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-26 0:23 ` [PATCH v5 02/26] doc: Add documentation about devicetree usage Simon Glass
2021-10-26 14:06 ` Ilias Apalodimas
@ 2021-10-26 14:31 ` François Ozog
2021-10-26 15:27 ` Simon Glass
1 sibling, 1 reply; 144+ messages in thread
From: François Ozog @ 2021-10-26 14:31 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Heinrich Schuchardt,
Ilias Apalodimas, Tom Rini, Sean Anderson, Marcel Ziswiler
Hi Simon,
On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg@chromium.org> wrote:
> At present some of the ideas and techniques behind devicetree in U-Boot
> are assumed, implied or unsaid. Add some documentation to cover how
> devicetree is build, how it can be modified and the rules about using
> the various CONFIG_OF_... options.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> ---
> This patch attracted quite a bit of discussion here:
>
>
> https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-sjg@chromium.org/
>
> I have not included the text suggested by François. While I agree that
> it would be useful to have an introduction in this space, I do not agree
> that we should have two devicetrees or that U-Boot should not have its own
> things in the devicetree, so it is not clear to me what we should actually
> write.
>
> The 'Devicetree Control in U-Boot' docs were recently merged and these
> provide some base info, for now.
>
> Changes in v5:
> - Bring into the OF_BOARD series
> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed
> - Refer to the 'control' DTB in the first paragraph
> - Use QEMU instead of qemu
>
> Changes in v3:
> - Clarify the 'bug' refered to at the top
> - Reword 'This means that there' paragraph to explain U-Boot-specific
> things
> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs
>
> Changes in v2:
> - Fix typos per Sean (thank you!) and a few others
> - Add a 'Use of U-Boot /config node' section
> - Drop mention of dm-verity since that actually uses the kernel cmdline
> - Explain that OF_BOARD will still work after these changes (in
> 'Once this bug is fixed...' paragraph)
> - Expand a bit on the reason why the 'Current situation' is bad
> - Clarify in a second place that Linux and U-Boot use the same devicetree
> in 'To be clear, while U-Boot...'
> - Expand on why we should have rules for other projects in
> 'Devicetree in another project'
> - Add a comment as to why devicetree in U-Boot is not 'bad design'
> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
> - Rewrite 'Devicetree generated on-the-fly in another project' to cover
> points raised on v1
> - Add 'Why does U-Boot have its nodes and properties?'
> - Add 'Why not have two devicetrees?'
>
> doc/develop/devicetree/dt_update.rst | 556 +++++++++++++++++++++++++++
> doc/develop/devicetree/index.rst | 1 +
> 2 files changed, 557 insertions(+)
> create mode 100644 doc/develop/devicetree/dt_update.rst
>
> diff --git a/doc/develop/devicetree/dt_update.rst
> b/doc/develop/devicetree/dt_update.rst
> new file mode 100644
> index 00000000000..3d4902e3592
> --- /dev/null
> +++ b/doc/develop/devicetree/dt_update.rst
> @@ -0,0 +1,556 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Updating the devicetree
> +=======================
> +
> +U-Boot uses devicetree for runtime configuration and storing required
> blobs or
> +any other information it needs to operate. This is called the 'control'
> +devicetree since it controls U-Boot. It is possible to update the control
> +devicetree separately from actually building U-Boot. This provides a good
> degree
> +of control and flexibility for firmware that uses U-Boot in conjunction
> with
> +other project.
> +
> +There are many reasons why it is useful to modify the devicetree after
> building
> +it:
> +
> +- Configuration can be changed, e.g. which UART to use
> +- A serial number can be added
> +- Public keys can be added to allow image verification
> +- Console output can be changed (e.g. to select serial or vidconsole)
> +
> +This section describes how to work with devicetree to accomplish your
> goals.
> +
> +See also :doc:`../devicetree/control` for a basic summary of the available
> +features.
> +
> +
> +Devicetree source
> +-----------------
> +
> +Every board in U-Boot must include a devicetree sufficient to build and
> boot
> +that board on suitable hardware (or emulation). This is specified using
> the
> +`CONFIG DEFAULT_DEVICE_TREE` option.
> +
> +
> +Current situation (October 2021)
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be
> empty,
> +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an
> enormous
> +amount of confusion and some wasted effort. This was not intended.
> Support for
> +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon.
> +
> +Some of the problems created are:
> +
> +- It is not obvious that the devicetree is coming from another project
> +
> +- There is no way to see even a sample devicetree for these platform in
> U-Boot,
> + so it is hard to know what is going on, e.g. which devices are typically
> + present
> +
> +- The other project may not provide a way to support U-Boot's
> requirements for
> + devicetree, such as the /config node. Note: On the U-Boot mailing
> linst, this
> + was only discovered after weeks of discussion and confusion
> +
> +- For QEMU specifically, consulting two QEMU source files is required,
> for which
> + there are no references in U-Boot documentation. The code is generating
> a
> + devicetree, but it is not clear what controls affect this generation.
> +
> +Specifically on the changes in U-Bootm `CONFIG_OF_BOARD` was added in
> +rpi_patch_ for Raspberry Pi, which does have an in-tree devicetree, but
> this
> +feature has since been used for boards that don't
> +
> +Once this bug is fixed, CONFIG_OF_BOARD will override (at runtime) the
> +evicetree suppled with U-Boot, but will otherwise use CONFIG_OF_SEPARATE
> for the
> +in-tree build. So these two will become options, moving out of the
> 'choice' in
> +`dts/Kconfig`.
> +
> +This means that there is a basic devicetree build in the U-Boot tree, for
> +build-testing, consistency and documentation purposes, but at runtime
> U-Boot can
> +accept its devicetree from another source. The in-tree devicetree may
> contain
> +U-Boot-specific features (in u-boot*.dtsi files) and this may prove
> useful for
> +the other project, so it can ensure that U-Boot functions correctly and
> supports
> +all its expected features.
> +
> +To be clear, while U-Boot has its own copy of the devicetree source for
> each
> +board, this must match the Linux source, perhaps with some u-boot.dtsi
> +additions. The intent here is not to create a separate binding, just to
> provide
> +a representative devicetree in U-Boot.
> +
> +Offending boards are:
> +
> +- rpi_4 and rpi_4_32b (other rpi boards do have an in-tree devicetree)
> +- qemu_arm64
> +- qemu_arm
> +- qemu-ppce500
> +- qemu-riscv32
> +- qemu-riscv32_smode
> +- qemu-riscv64
> +- qemu-riscv64_smode
> +
> +All of these need to have a devicetree added in-tree. This is targeted to
> be
> +fixed in the 2022.01 release.
> +
> +
> +Building the devicetree
> +-----------------------
> +
> +U-Boot automatically builds the devicetree for a board, from the
> +`arch/<arch>/dts` directory. The Makefile in those directories has rules
> for
> +building devicetree files. It is preferable to avoid target-specific
> rules in
> +those files: i.e. all boards for a particular SoC should be built at once,
> +where practical. Apart from simplifying the Makefile, this helps to
> efficiently
> +(and immediately) ensure that changes in one board's DT do not break
> others that
> +are related. Building devicetrees is fast, so performance is seldom a
> concern
> +here.
> +
> +
> +Overriding the default devicetree
> +---------------------------------
> +
> +When building U-Boot, the `DEVICE_TREE` environment variable allows the
> +default devicetree file to be overridden at build time. This can be
> useful if
> +modifications have to be made to the in-tree devicetree file, for the
> benefit
> +of a downstream build system. Note that the in-tree devicetree must be
> +sufficient to build and boot, so this is not a way to bypass that
> requirement.
> +
> +
> +Modifying the devicetree after building
> +---------------------------------------
> +
> +While it is generally painful and hacky to modify the code or rodata of a
> +program after it is built, in many cases it is useful to do so, e.g. to
> add
> +configuration information like serial numbers, enabling/disabling
> features, etc.
> +
> +Devicetree provides a very nice solution to these problems since it is
> +structured data and it is relatively easy to change it, even in binary
> form
> +(see fdtput).
> +
> +U-Boot takes care that the devicetree is easily accessible after the build
> +process. In fact it is placed in a separate file called `u-boot.dtb`. If
> the
> +build system wants to modify or replace that file, it can do so. Then all
> that
> +is needed is to run `binman update` to update the file inside the image.
> If
> +binman is not used, then `u-boot-nodtb.bin` and the new `u-boot.dtb` can
> simply
> +be concatenated to achieve the desired result. U-Boot happily copes with
> the
> +devicetree growing or shrinking.
> +
> +The `u-boot.bin` image contains both pieces. While it is possible to
> locate the
> +devicetree within the image using the signature at the start of the file,
> this
> +is a bit messy.
> +
> +This is why `CONFIG_OF_SEPARATE` should always be used when building
> U-Boot.
> +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the
> U-Boot ELF
> +image as rodata, meaning that it is hard to find it and it cannot
> increase in
> +size.
> +
> +When modifying the devicetree, the different cases to consider are as
> follows:
> +
> +- CONFIG_OF_SEPARATE
> + This is easy, described above. Just change, replace or rebuild the
> + devicetree so it suits your needs, then rerun binman or redo the `cat`
> + operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb`
> +
> +- CONFIG_OF_EMBED
> + This is tricky, since the devicetree cannot easily be located. If the
> EFL
> + file is available, then the _dtb_dt_begin and __dtb_dt_end symbols
> can be
> + examined to find it. While it is possible to contract the file, it is
> not
> + possible to expand the file since that would involve re-linking
> +
> +- CONFIG_OF_BOARD
> + This is a board-specific situation, so needs to be considered on a
> + case-by-case base. The devicetree must be modified so that the correct
> + one is provided to U-Boot. How this is done depends entirely on the
> + implementation of this option for the board. It might require
> injecting the
> + changes into a different project somehow using tooling available
> there, or
> + it might involve merging an overlay file at runtime to obtain the
> desired
> + result.
> +
> +
> +Use of U-Boot /config node
> +--------------------------
> +
> +A common problem with firmware is that many builds are needed to deal
> with the
> +slight variations between different, related models. For example, one
> model may
> +have a TPM and another may not. Devicetree provides an excellent solution
> to
> +this problem, in that the devicetree to actually use on a platform can be
> +injected in the factory based on which model is being manufactured at the
> time.
> +
> +A related problem causing build proliferation is dealing with the
> differences
> +between development firmware, developer-friendly firmware (e.g. with all
> +security features present but with the ability to access the command
> line),
> +test firmware (which runs tests used in the factory), final production
> firmware
> +(before signing), signed firmware (where the signatures have been
> inserted) and
> +the like. Ideally all or most of these should use the same U-Boot build,
> with
> +just some options to determine the features available. For example, being
> able
> +to control whether the UART console or JTAG are available, on any image,
> is a
> +great debugging aid.
> +
> +When the firmware consists of multiple parts, it is helpful that all
> operate
> +the same way at runtime, regardless of how they were built. This can be
> achieved
> +by passing the runtime configuration (e.g. 'enable UART console) along
> the chain
> +through each firmware stage. It is frustrating to have to replicate a bug
> on
> +production firmware which does happen on developer firmware, because they
> are
> +completely different builds.
> +
> +The /config node provides useful functionality for this. It allows the
> different
> +controls to be 'factored out' of the U-Boot binary, so they can be
> controlled
> +separately from the initial source-code build. The node can be easily
> updated by
> +a build or factory tool and can control various features in U-Boot. It is
> +similar in concept to a Kconfig option, except that it can be changed
> after
> +U-Boot is built.
> +
> +The /config node is similar in concept to the `/chosen node`_ except that
> it is
> +for passing information *into* firmware instead of from firmware to the
> +Operating System. Also, while Linux has a (sometimes extremely long)
> command
> +line, U-Boot does not support this. The devicetree provides a more
> structured
> +approach in any case.
> +
> +
> +Devicetree in another project
> +-----------------------------
> +
> +In some cases U-Boot receive its devicetree at runtime from a program
> that calls
> +it. For example ARM's Trusted Firmware A (`TF-A`_) may have a devicetree
> that it
> +passes to U-Boot. This overrides any devicetree build by U-Boot. When
> packaging
> +the firmware, the U-Boot devicetree may in fact be left out if it can be
> +guaranteed that it will receive one from another project.
> +
> +In this case, the devicetree in the other project must track U-Boot's use
> of
> +device tree, for the following reasons:
> +
> +- U-Boot only has one devicetree. See `Why not have two devicetrees?`_.
> +- For a consistent firmware build, decisions made in early stages should
> be
> + communicated to later ones at runtime. For example, if the serial
> console is
> + enabled in an early stage, it should be enabled in U-Boot too.
> +- U-Boot is quite capable of managing its own copy of the devicetree. If
> + another project wants to bypass this (often for good reason), it is
> reasonable
> + that it should take on the (fairly small) requirements that U-Boot
> features
> + that rely on devicetree are still available
> +- The point here is not that *U-Boot needs this extra node*, or *U-Boot
> needs
> + to have this public key*. These features are present in U-Boot in
> service of
> + the entire firmware system. If the U-Boot features are used, but cannot
> be
> + supported in the normal way, then there is pressure to implement these
> + features in other ways. In the end, we would have a different mechanism
> for
> + every other project that uses U-Boot. This introduces duplicate ways of
> doing
> + the same thing, needlessly increases the complexity of the U-Boot
> source code,
> + forces authors to consider parallel implementations when writing new
> features,
> + makes U-Boot harder to test, complicates documentation and confuses the
> + runtime flow of U-Boot. If every board did things its own way rather
> than
> + contributing to the common code, U-Boot would lose a lot of its
> cross-platform
> + value.
> +
> +The above does not indicate *bad design* within U-Boot. Devicetree is a
> core
> +component of U-Boot and U-Boot makes use of it to the full. It solves a
> myriad
> +of problems that would otherwise need their own special C struct, binary
> format,
> +special property, tooling for viewing and updating, etc.
> +
> +Specifically, the other project must provide a way to add configuration
> and
> +other information to the devicetree for use by U-Boot, such as the
> /config node.
> +Note that the U-Boot in-tree devicetree source must be sufficient to
> build and
> +boot, so this is not a way to bypass that requirement.
> +
> +If binman is used, the devicetree source in U-Boot must contain the binman
> +definition so that a valid image can be build. This helps people discover
> what
> +other firmware components are needed and seek out appropriate
> documentation.
> +
> +If verified boot is used, the project must provide a way to inject a
> public key,
> +certificate or other material into the U-Boot devicetree so that it is
> available
> +to U-Boot at runtime. See `Signing with U-Boot devicetree`_. This may be
> +through tooling in the project itself or by making use of U-Boot's
> tooling.
> +
> +
> +Devicetree generated on-the-fly in another project
> +--------------------------------------------------
> +
> +In some rare cases, another project may wish to create a devicetree for
> U-Boot
> +entirely on-the-fly, then pass it to U-Boot at runtime. The only known
> example
> +of this at the time of writing (2021) is QEMU, for ARM (`QEMU ARM`_) and
> +RISC-V (`QEMU RISC-V`_).
> +
> +In effect, when the board boots, U-Boot is *downstream* of the other
> project.
> +It is entirely reliant on that project for its correct operation.
> +
> +This does not mean to imply that the other project is creating its own,
> +incompatible devicetree. In fact QEMU generates a valid devicetree which
> is
> +suitable for both U-Boot and Linux. It is quite normal for a devicetree
> to be
> +present in flash and be made available to U-Boot at runtime. What matters
> is
> +where the devicetree comes from. If the other project builds a devicetree
> for
> +U-Boot then it needs to support adding the things needed by U-Boot
> features.
> +Without them, for example:
> +
> +- U-Boot may not boot because too many devices are enabled before
> relocation
> +- U-Boot may not have access to the developer or production public keys
> used for
> + signing
> +- U-Boot may not support controlling whether the console is enabled
> +- U-Boot may not be know which MMC device to boot from
> +- U-Boot may not be able to find other firmware components that it needs
> to load
> +
> +Normally, supporting U-Boot's features is trivial, since the devicetree
> compiler
> +(dtc) can compile the source, including any U-Boot pieces. So the burden
> is
> +extremely low.
> +
> +In this case, the devicetree in the other project must track U-Boot's use
> of
> +device tree, so that it remains compatible. See `Devicetree in another
> project`_
> +for reasons why.
> +
> +If a particular version of the project is needed for a particular version
> of
> +U-Boot, that must be documented in both projects.
> +
> +Further, it must provide a way to add configuration and other information
> to
> +the devicetree for use by U-Boot, such as the `/config` node and the tags
> used
> +by driver model. Note that the U-Boot in-tree devicetree must be
> sufficient to
> +build and boot, so this is not a way to bypass that requirement.
> +
> +More specifically, tooling or command-line arguments must provide a way to
> +add a `/config` node or items within that node, so that U-Boot can
> receive a
> +suitable configuration. It must provide a way of adding `u-boot,dm-...`
> tags for
> +correct operation of driver model. These options can then be used as part
> of the
> +build process, which puts the firmware image together. For binman, a way
> must be
> +provided to add the binman definition into the devicetree in the same way.
> +
> +One way to do this is to allow a .dtsi file to be merged in with the
> generated
> +devicetree.
> +
> +Note that the burden goes both ways. If a new feature is added to U-Boot
> which
> +needs support in another project, then the author of the U-Boot patch
> must add
> +any required support to the other project.
> +
> +
> +Passing the devicetree through to Linux
> +---------------------------------------
> +
> +Ideally U-Boot and Linux use the same devicetree source, even though it is
> +hosted in separate projects. U-Boot adds some extra pieces, such as the
> +`config/` node and tags like `u-boot,dm-spl`. Linux adds some extra
> pieces, such
> +as `linux,default-trigger` and `linux,code`. This should not interfere
> with
> +each other.
> +
> +In principle it is possible for U-Boot's control devicetree to be passed
> to
> +Linux. This is, after all, one of the goals of devicetree and the original
> +Open Firmware project, to have the firmware provide the hardware
> description to
> +the Operating System.
> +
> +For boards where this approach is used, care must be taken. U-Boot
> typically
> +needs to 'fix up' the devicetree before passing it to Linux, e.g. to add
> +information about the memory map, about which serial console is used,
> provide
> +the kernel address space layout randomization (KASLR) seed or select
> whether the
> +console should be silenced for a faster boot.
> +
> +Fix-ups involve modifying the devicetree. If the control devicetree is
> used,
> +that means the control devicetree could be modified, while U-Boot is
> using it.
> +Removing a device and reinserting it can cause problems if the devicetree
> offset
> +has changed, for example, since the device will be unable to locates its
> +devicetree properties at the expected devicetree offset, which is a fixed
> +integer.
> +
> +To deal with this, it is recommended to employ one or more of the
> following
> +approaches:
> +
> +- Make a copy of the devicetree and 'fix up' the copy, leaving the control
> + devicetree alone
> +- Enable `CONFIG_OF_LIVE` so that U-Boot makes its own copy of the
> devicetree
> + during relocation; fixups then happen on the original flat tree
> +- Ensure that fix-ups happen after all loading has happened and U-Boot has
> + completed image verification
> +
> +In practice,the last point is typically observed, since boot_prep_linux()
> is
> +called just before jumping to Linux, long after signature verification,
> for
> +example. But it is important to make sure that this line is not blurred,
> +particularly if untrusted user data is involved.
> +
> +
> +Devicetree use cases that must be supported
> +-------------------------------------------
> +
> +Regardless of how the devicetree is provided to U-Boot at runtime, various
> +U-Boot features must be fully supported. This section describes some of
> these
> +features and the implications for other projects.
> +
> +If U-Boot uses its own in-tree devicetree these features are supported
> +automatically.
> +
> +
> +Signing with U-Boot devicetree
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +U-Boot supports signing a payload so that it can be verified to have been
> +created by a party owning a private key. This is called verified boot in
> U-Boot
> +(see doc/uImage.FIT/verified-boot.txt).
> +
> +Typically this works by creating a FIT and then running the `mkimage`
> tool to
> +add signatures for particular images. As part of this process, `mkimage`
> writes
> +a public key to the U-Boot devicetree, although this can be done
> separately.
> +See fdt_add_pubkey_ for patches for a suitable tool, for example.
> +
> +As with all configuration information, if another project is providing the
> +devicetree to U-Boot, it must provide a way to add this public key into
> the
> +devicetree it passes to U-Boot. This could be via a tooling option,
> making use
> +of `mkimage`, or allowing a .dtsi file to be merged in with what is
> generated in
> +the other project.
> +
> +
> +Providing the binman image definition
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +In complex systems U-Boot must locate and make use of other firmware
> components,
> +such as images for the user interface, files containing peripheral
> firmware,
> +multiple copies of U-Boot for use with A/B boot, etc. U-Boot uses
> +:doc:`Binman <../package/binman>` as a standard way of putting an image
> +together.
> +
> +Typically this works by running binman with the devicetree as an input, to
> +create the file image. Binman then outputs an updated devicetree which is
> +packed in the firmware image, so U-Boot can access the binman definition
> and
> +locate all the components.
> +
> +As with all configuration information, if another project is providing the
> +devicetree to U-Boot, it must provide a way to add this binman definition
> into
> +the devicetree it passes to U-Boot. This could be via a tooling option,
> making
> +use of `binman`, or alowing a .dtsi file to be merged in with what is
> generated
> +in the other project.
> +
> +
> +Protecting the devicetree
> +-------------------------
> +
> +U-Boot relies heavily on devicetree for correct operation. A corrupt or
> invalid
> +device can cause U-Boot to fail to start, behave incorrectly, crash (e.g.
> if
> +`CONFIG_OF_LIBFDT_ASSUME_MASK` is adjusted, or fail to boot an Operating
> System.
> +Within U-Boot, the devicetree is as important as any other part of the
> source
> +code. At ruuntime, the devicetree can be considered to be structured
> rodata.
> +
> +With secure systems, care must be taken that the devicetree is valid:
> +
> +- If the code / rodata has a hash or signature, the devicetree should
> also, if
> + they are packaged separately.
> +- If the code / rodata is write-protected when running, the devicetree
> should be
> + also. Note that U-Boot relocates its code and devicetree, so this is
> not as
> + simple as it sounds. U-Boot must write-protect these items after
> relocating.
> +
> +
> +Why does U-Boot have its nodes and properties?
> +----------------------------------------------
> +
> +See also :doc:`../devicetree/intro`.
> +
> +There has been pushback at the concept that U-Boot dares have its own
> nodes and
> +properties in the devicetree.
> +
> +Apart from these nodes and properties, U-Boot uses the same bindings as
> Linux.
> +A `u-boot.dtsi` file helps to keep U-Boot-specific changes in separate
> files,
> +making it easier to keep devicetree source files in U-Boot in sync with
> Linux.
> +
> +As a counter-example, the Zephyr OS project takes a different approach.
> It uses
> +entirely different bindings, in general, making no effort to sync
> devicetree
> +source files with Linux. U-Boot strives to be compatible with Linux in a
> number
> +of ways, such as source code style and common APIs, to aid porting of code
> +between the projects. Devicetree is another way where U-Boot and Linux
> follow a
> +similar approach.
> +
> +Fundamentally, the idea that U-Boot cannot have its own tags flies in the
> face
> +of the devicetree specification (see dtspec_), which says:
> +
> + Nonstandard property names should specify a **unique string prefix**,
> such as
> + a stock ticker symbol, identifying the name of the company **or
> organization**
> + that defined the property. Examples:
> +
> + - fsl,channel-fifo-len
> + - ibm,ppc-interrupt-server#s
> + - **linux**,network-index
> +
> +It is also fundamentally unbalanced. Linux has many tags of its own (some
> 36 in
> +version 5.13) and at least one Linux-specific node, even if you ignore
> things
> +like flash partitions which clearly provide configuration information to
> Linux.
> +
> +Practically speaking there are many reasons why U-Boot has its own nodes
> and
> +properties. Some examples:
> +
> +- Binding every device before relocation even if it won't be used,
> consumes time
> + and memory: tags on each node can specify which are needed in SPL or
> before
> + relocation. Linux has no such constraints.
> +
> +- Requiring the full clock tree to be up and running just to get the
> debug UART
> + running is inefficient. It is also and self-defeating, since if that
> much
> + code is working properly, you probably don't need the debug UART. A
> devicetree
> + property to provide the UART input-clock frequency is a simple solution.
> +
> +- U-Boot does not have a user space to provide policy and configuration.
> It
> + cannot do what Linux does and run programs and look up filesystems to
> figure
> + out how to boot.
> +
> +
> +Why not have two devicetrees?
> +-----------------------------
> +
> +Setting aside the argument for restricting U-Boot from having its own
> nodes and
> +properties, another idea proposed is to have two devicetrees, one for the
> +U-Boot-specific bits (here called `special`) and one for everything else
> (here
> +called `linux`).
> +
> +On the positive side, it might quieten the discussion alluded to in the
> section
> +above. But there are many negatives to consider and many open questions to
> +resolve.
> +
> +- **Bindings** - Presumably the special devicetree would have its own
> bindings.
> + It would not be necessary to put a `u-boot,` prefix on anything. People
> coming
> + across the devicetree source would wonder how it fits in with the Linux
> + devicetree.
> +
> +- **Access** - U-Boot has a nice `ofnode` API for accessing the
> devicetree. This
> + would need to be expanded to support two trees. Features which need to
> access
> + both (such as a device driver which reads the special devicetree to get
> some
> + configuration info) could become quite confusing to read and write.
> +
> +- **Merging** - Can the two devicetree be merged if a platform desires
> it? If
> + so, how is this managed in tooling? Does it happen during the build, in
> which
> + case they are not really separate at all. Or does U-Boot merge them at
> + runtime, in which case this adds time and memory?
> +
> +- **Efficiency** - A second device tree adds more code and more code
> paths. It
> + requires that both be made available to the code in U-Boot, e.g. via a
> + separate pointer or argument or API. Overall the separation would
> certainly
> + not speed up U-Boot, nor decrease its size.
> +
> +- **Source code** - At present `u-boot.dtsi` files provide the pieces
> needed for
> + U-Boot for a particular board. Would we use these same files for the
> special
> + devicetree?
> +
> +- **Complexity** - Two devicetrees complicates the build system since it
> must
> + build and package them both. Errors must be reported in such a way that
> it
> + is obvious which one is failing.
> +
> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver
> model
> + are currently placed in the nodes they relate to. How would these tags
> + reference a node that is in a separate devicetree? What extra
> validation would
> + be needed?
> +
> +- **Storage** - How would the two devicetrees be stored in the image? At
> present
> + we simply concatenate the U-Boot binary and the devicetree. We could
> add the
> + special devicetree before the Linux one, so two are concatenated, but
> it is
> + not pretty. We could use binman to support more complex arrangements,
> but only
> + some boards use this at present, so it would be a big change.
> +
> +- **API** - How would another project provide two devicetree files to
> U-Boot at
> + runtime? Presumably this would just be too painful. But if it doesn't,
> it
> + would be unable to configure run-time features of U-Boot during the
> boot.
> +
> +- **Confusion** - No other project has two devicetrees. U-Boot would be
> in the
> + unfortunate position of having to describe this fact to new users,
> along with
> + the (arguably contrived) reason for the arrangement.
> +
>
False:
1) projects in trustedfirmware.org are built to have multiple FDT objects,
some for "dynamic" configuration purposes.
2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition
to operating system
As Ilias said, this is not about documentation about the current use of DT
in U-Boot, but justification of your views on DT.
If taken by the letter, I feel (may be wrong though) that your views
prevent establish the DT lifecycle and usage as per the desire of vendors,
partners and customers that supports Arm SystemReady standards.
+- **Signing flow** - The current signing flow is simple as it involves
> running
> + `mkimage` with the U-Boot devicetree. This would have to be updated to
> use the
> + special devicetree. Some way of telling the user that they have done it
> wrong
> + would have to be invented.
> +
> +Overall, adding a second devicetree would create enormous confusion and
> +complexity. It seems a lot cheaper to solve this by a change of attitude.
> +
> +
> +.. _rpi_patch:
> https://patchwork.ozlabs.org/project/uboot/patch/20170402082520.32546-1-deymo@google.com/
> +.. _`TF-A`: https://www.trustedfirmware.org/projects/tf-a
> +.. _`QEMU ARM`: https://github.com/qemu/qemu/blob/master/hw/arm/virt.c
> +.. _`QEMU RISC-V`:
> https://github.com/qemu/qemu/blob/master/hw/riscv/virt.c
> +.. _`/chosen node`:
> https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> +.. _fdt_add_pubkey:
> https://patchwork.ozlabs.org/project/uboot/list/?series=157843&state=*
> +.. _dtspec: https://www.devicetree.org/specifications/
> diff --git a/doc/develop/devicetree/index.rst
> b/doc/develop/devicetree/index.rst
> index fa5db3eb76e..b5b33dfea0f 100644
> --- a/doc/develop/devicetree/index.rst
> +++ b/doc/develop/devicetree/index.rst
> @@ -11,3 +11,4 @@ build-time and runtime configuration.
>
> intro
> control
> + dt_update
> --
> 2.33.0.1079.g6e70778dc9-goog
>
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-26 14:31 ` François Ozog
@ 2021-10-26 15:27 ` Simon Glass
2021-10-26 15:57 ` François Ozog
0 siblings, 1 reply; 144+ messages in thread
From: Simon Glass @ 2021-10-26 15:27 UTC (permalink / raw)
To: François Ozog
Cc: U-Boot Mailing List, Mark Kettenis, Heinrich Schuchardt,
Ilias Apalodimas, Tom Rini, Sean Anderson, Marcel Ziswiler
Hi François,
On Tue, 26 Oct 2021 at 08:31, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon,
>
> On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg@chromium.org> wrote:
>>
>> At present some of the ideas and techniques behind devicetree in U-Boot
>> are assumed, implied or unsaid. Add some documentation to cover how
>> devicetree is build, how it can be modified and the rules about using
>> the various CONFIG_OF_... options.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>> ---
>> This patch attracted quite a bit of discussion here:
>>
>> https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-sjg@chromium.org/
>>
>> I have not included the text suggested by François. While I agree that
>> it would be useful to have an introduction in this space, I do not agree
>> that we should have two devicetrees or that U-Boot should not have its own
>> things in the devicetree, so it is not clear to me what we should actually
>> write.
>>
>> The 'Devicetree Control in U-Boot' docs were recently merged and these
>> provide some base info, for now.
>>
>> Changes in v5:
>> - Bring into the OF_BOARD series
>> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed
>> - Refer to the 'control' DTB in the first paragraph
>> - Use QEMU instead of qemu
>>
>> Changes in v3:
>> - Clarify the 'bug' refered to at the top
>> - Reword 'This means that there' paragraph to explain U-Boot-specific things
>> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs
>>
>> Changes in v2:
>> - Fix typos per Sean (thank you!) and a few others
>> - Add a 'Use of U-Boot /config node' section
>> - Drop mention of dm-verity since that actually uses the kernel cmdline
>> - Explain that OF_BOARD will still work after these changes (in
>> 'Once this bug is fixed...' paragraph)
>> - Expand a bit on the reason why the 'Current situation' is bad
>> - Clarify in a second place that Linux and U-Boot use the same devicetree
>> in 'To be clear, while U-Boot...'
>> - Expand on why we should have rules for other projects in
>> 'Devicetree in another project'
>> - Add a comment as to why devicetree in U-Boot is not 'bad design'
>> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
>> - Rewrite 'Devicetree generated on-the-fly in another project' to cover
>> points raised on v1
>> - Add 'Why does U-Boot have its nodes and properties?'
>> - Add 'Why not have two devicetrees?'
>>
>> doc/develop/devicetree/dt_update.rst | 556 +++++++++++++++++++++++++++
>> doc/develop/devicetree/index.rst | 1 +
>> 2 files changed, 557 insertions(+)
>> create mode 100644 doc/develop/devicetree/dt_update.rst
>>
>> diff --git a/doc/develop/devicetree/dt_update.rst b/doc/develop/devicetree/dt_update.rst
>> new file mode 100644
>> index 00000000000..3d4902e3592
>> --- /dev/null
>> +++ b/doc/develop/devicetree/dt_update.rst
>> @@ -0,0 +1,556 @@
>> +.. SPDX-License-Identifier: GPL-2.0+
>> +
>> +Updating the devicetree
>> +=======================
>> +
>> +U-Boot uses devicetree for runtime configuration and storing required blobs or
>> +any other information it needs to operate. This is called the 'control'
>> +devicetree since it controls U-Boot. It is possible to update the control
>> +devicetree separately from actually building U-Boot. This provides a good degree
>> +of control and flexibility for firmware that uses U-Boot in conjunction with
>> +other project.
>> +
>> +There are many reasons why it is useful to modify the devicetree after building
>> +it:
>> +
>> +- Configuration can be changed, e.g. which UART to use
>> +- A serial number can be added
>> +- Public keys can be added to allow image verification
>> +- Console output can be changed (e.g. to select serial or vidconsole)
>> +
>> +This section describes how to work with devicetree to accomplish your goals.
>> +
>> +See also :doc:`../devicetree/control` for a basic summary of the available
>> +features.
>> +
>> +
>> +Devicetree source
>> +-----------------
>> +
>> +Every board in U-Boot must include a devicetree sufficient to build and boot
>> +that board on suitable hardware (or emulation). This is specified using the
>> +`CONFIG DEFAULT_DEVICE_TREE` option.
>> +
>> +
>> +Current situation (October 2021)
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty,
>> +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an enormous
>> +amount of confusion and some wasted effort. This was not intended. Support for
>> +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon.
>> +
>> +Some of the problems created are:
>> +
>> +- It is not obvious that the devicetree is coming from another project
>> +
>> +- There is no way to see even a sample devicetree for these platform in U-Boot,
>> + so it is hard to know what is going on, e.g. which devices are typically
>> + present
>> +
>> +- The other project may not provide a way to support U-Boot's requirements for
>> + devicetree, such as the /config node. Note: On the U-Boot mailing linst, this
>> + was only discovered after weeks of discussion and confusion
>> +
>> +- For QEMU specifically, consulting two QEMU source files is required, for which
>> + there are no references in U-Boot documentation. The code is generating a
>> + devicetree, but it is not clear what controls affect this generation.
>> +
>> +Specifically on the changes in U-Bootm `CONFIG_OF_BOARD` was added in
>> +rpi_patch_ for Raspberry Pi, which does have an in-tree devicetree, but this
>> +feature has since been used for boards that don't
>> +
>> +Once this bug is fixed, CONFIG_OF_BOARD will override (at runtime) the
>> +evicetree suppled with U-Boot, but will otherwise use CONFIG_OF_SEPARATE for the
>> +in-tree build. So these two will become options, moving out of the 'choice' in
>> +`dts/Kconfig`.
>> +
>> +This means that there is a basic devicetree build in the U-Boot tree, for
>> +build-testing, consistency and documentation purposes, but at runtime U-Boot can
>> +accept its devicetree from another source. The in-tree devicetree may contain
>> +U-Boot-specific features (in u-boot*.dtsi files) and this may prove useful for
>> +the other project, so it can ensure that U-Boot functions correctly and supports
>> +all its expected features.
>> +
>> +To be clear, while U-Boot has its own copy of the devicetree source for each
>> +board, this must match the Linux source, perhaps with some u-boot.dtsi
>> +additions. The intent here is not to create a separate binding, just to provide
>> +a representative devicetree in U-Boot.
>> +
>> +Offending boards are:
>> +
>> +- rpi_4 and rpi_4_32b (other rpi boards do have an in-tree devicetree)
>> +- qemu_arm64
>> +- qemu_arm
>> +- qemu-ppce500
>> +- qemu-riscv32
>> +- qemu-riscv32_smode
>> +- qemu-riscv64
>> +- qemu-riscv64_smode
>> +
>> +All of these need to have a devicetree added in-tree. This is targeted to be
>> +fixed in the 2022.01 release.
>> +
>> +
>> +Building the devicetree
>> +-----------------------
>> +
>> +U-Boot automatically builds the devicetree for a board, from the
>> +`arch/<arch>/dts` directory. The Makefile in those directories has rules for
>> +building devicetree files. It is preferable to avoid target-specific rules in
>> +those files: i.e. all boards for a particular SoC should be built at once,
>> +where practical. Apart from simplifying the Makefile, this helps to efficiently
>> +(and immediately) ensure that changes in one board's DT do not break others that
>> +are related. Building devicetrees is fast, so performance is seldom a concern
>> +here.
>> +
>> +
>> +Overriding the default devicetree
>> +---------------------------------
>> +
>> +When building U-Boot, the `DEVICE_TREE` environment variable allows the
>> +default devicetree file to be overridden at build time. This can be useful if
>> +modifications have to be made to the in-tree devicetree file, for the benefit
>> +of a downstream build system. Note that the in-tree devicetree must be
>> +sufficient to build and boot, so this is not a way to bypass that requirement.
>> +
>> +
>> +Modifying the devicetree after building
>> +---------------------------------------
>> +
>> +While it is generally painful and hacky to modify the code or rodata of a
>> +program after it is built, in many cases it is useful to do so, e.g. to add
>> +configuration information like serial numbers, enabling/disabling features, etc.
>> +
>> +Devicetree provides a very nice solution to these problems since it is
>> +structured data and it is relatively easy to change it, even in binary form
>> +(see fdtput).
>> +
>> +U-Boot takes care that the devicetree is easily accessible after the build
>> +process. In fact it is placed in a separate file called `u-boot.dtb`. If the
>> +build system wants to modify or replace that file, it can do so. Then all that
>> +is needed is to run `binman update` to update the file inside the image. If
>> +binman is not used, then `u-boot-nodtb.bin` and the new `u-boot.dtb` can simply
>> +be concatenated to achieve the desired result. U-Boot happily copes with the
>> +devicetree growing or shrinking.
>> +
>> +The `u-boot.bin` image contains both pieces. While it is possible to locate the
>> +devicetree within the image using the signature at the start of the file, this
>> +is a bit messy.
>> +
>> +This is why `CONFIG_OF_SEPARATE` should always be used when building U-Boot.
>> +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot ELF
>> +image as rodata, meaning that it is hard to find it and it cannot increase in
>> +size.
>> +
>> +When modifying the devicetree, the different cases to consider are as follows:
>> +
>> +- CONFIG_OF_SEPARATE
>> + This is easy, described above. Just change, replace or rebuild the
>> + devicetree so it suits your needs, then rerun binman or redo the `cat`
>> + operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb`
>> +
>> +- CONFIG_OF_EMBED
>> + This is tricky, since the devicetree cannot easily be located. If the EFL
>> + file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can be
>> + examined to find it. While it is possible to contract the file, it is not
>> + possible to expand the file since that would involve re-linking
>> +
>> +- CONFIG_OF_BOARD
>> + This is a board-specific situation, so needs to be considered on a
>> + case-by-case base. The devicetree must be modified so that the correct
>> + one is provided to U-Boot. How this is done depends entirely on the
>> + implementation of this option for the board. It might require injecting the
>> + changes into a different project somehow using tooling available there, or
>> + it might involve merging an overlay file at runtime to obtain the desired
>> + result.
>> +
>> +
>> +Use of U-Boot /config node
>> +--------------------------
>> +
>> +A common problem with firmware is that many builds are needed to deal with the
>> +slight variations between different, related models. For example, one model may
>> +have a TPM and another may not. Devicetree provides an excellent solution to
>> +this problem, in that the devicetree to actually use on a platform can be
>> +injected in the factory based on which model is being manufactured at the time.
>> +
>> +A related problem causing build proliferation is dealing with the differences
>> +between development firmware, developer-friendly firmware (e.g. with all
>> +security features present but with the ability to access the command line),
>> +test firmware (which runs tests used in the factory), final production firmware
>> +(before signing), signed firmware (where the signatures have been inserted) and
>> +the like. Ideally all or most of these should use the same U-Boot build, with
>> +just some options to determine the features available. For example, being able
>> +to control whether the UART console or JTAG are available, on any image, is a
>> +great debugging aid.
>> +
>> +When the firmware consists of multiple parts, it is helpful that all operate
>> +the same way at runtime, regardless of how they were built. This can be achieved
>> +by passing the runtime configuration (e.g. 'enable UART console) along the chain
>> +through each firmware stage. It is frustrating to have to replicate a bug on
>> +production firmware which does happen on developer firmware, because they are
>> +completely different builds.
>> +
>> +The /config node provides useful functionality for this. It allows the different
>> +controls to be 'factored out' of the U-Boot binary, so they can be controlled
>> +separately from the initial source-code build. The node can be easily updated by
>> +a build or factory tool and can control various features in U-Boot. It is
>> +similar in concept to a Kconfig option, except that it can be changed after
>> +U-Boot is built.
>> +
>> +The /config node is similar in concept to the `/chosen node`_ except that it is
>> +for passing information *into* firmware instead of from firmware to the
>> +Operating System. Also, while Linux has a (sometimes extremely long) command
>> +line, U-Boot does not support this. The devicetree provides a more structured
>> +approach in any case.
>> +
>> +
>> +Devicetree in another project
>> +-----------------------------
>> +
>> +In some cases U-Boot receive its devicetree at runtime from a program that calls
>> +it. For example ARM's Trusted Firmware A (`TF-A`_) may have a devicetree that it
>> +passes to U-Boot. This overrides any devicetree build by U-Boot. When packaging
>> +the firmware, the U-Boot devicetree may in fact be left out if it can be
>> +guaranteed that it will receive one from another project.
>> +
>> +In this case, the devicetree in the other project must track U-Boot's use of
>> +device tree, for the following reasons:
>> +
>> +- U-Boot only has one devicetree. See `Why not have two devicetrees?`_.
>> +- For a consistent firmware build, decisions made in early stages should be
>> + communicated to later ones at runtime. For example, if the serial console is
>> + enabled in an early stage, it should be enabled in U-Boot too.
>> +- U-Boot is quite capable of managing its own copy of the devicetree. If
>> + another project wants to bypass this (often for good reason), it is reasonable
>> + that it should take on the (fairly small) requirements that U-Boot features
>> + that rely on devicetree are still available
>> +- The point here is not that *U-Boot needs this extra node*, or *U-Boot needs
>> + to have this public key*. These features are present in U-Boot in service of
>> + the entire firmware system. If the U-Boot features are used, but cannot be
>> + supported in the normal way, then there is pressure to implement these
>> + features in other ways. In the end, we would have a different mechanism for
>> + every other project that uses U-Boot. This introduces duplicate ways of doing
>> + the same thing, needlessly increases the complexity of the U-Boot source code,
>> + forces authors to consider parallel implementations when writing new features,
>> + makes U-Boot harder to test, complicates documentation and confuses the
>> + runtime flow of U-Boot. If every board did things its own way rather than
>> + contributing to the common code, U-Boot would lose a lot of its cross-platform
>> + value.
>> +
>> +The above does not indicate *bad design* within U-Boot. Devicetree is a core
>> +component of U-Boot and U-Boot makes use of it to the full. It solves a myriad
>> +of problems that would otherwise need their own special C struct, binary format,
>> +special property, tooling for viewing and updating, etc.
>> +
>> +Specifically, the other project must provide a way to add configuration and
>> +other information to the devicetree for use by U-Boot, such as the /config node.
>> +Note that the U-Boot in-tree devicetree source must be sufficient to build and
>> +boot, so this is not a way to bypass that requirement.
>> +
>> +If binman is used, the devicetree source in U-Boot must contain the binman
>> +definition so that a valid image can be build. This helps people discover what
>> +other firmware components are needed and seek out appropriate documentation.
>> +
>> +If verified boot is used, the project must provide a way to inject a public key,
>> +certificate or other material into the U-Boot devicetree so that it is available
>> +to U-Boot at runtime. See `Signing with U-Boot devicetree`_. This may be
>> +through tooling in the project itself or by making use of U-Boot's tooling.
>> +
>> +
>> +Devicetree generated on-the-fly in another project
>> +--------------------------------------------------
>> +
>> +In some rare cases, another project may wish to create a devicetree for U-Boot
>> +entirely on-the-fly, then pass it to U-Boot at runtime. The only known example
>> +of this at the time of writing (2021) is QEMU, for ARM (`QEMU ARM`_) and
>> +RISC-V (`QEMU RISC-V`_).
>> +
>> +In effect, when the board boots, U-Boot is *downstream* of the other project.
>> +It is entirely reliant on that project for its correct operation.
>> +
>> +This does not mean to imply that the other project is creating its own,
>> +incompatible devicetree. In fact QEMU generates a valid devicetree which is
>> +suitable for both U-Boot and Linux. It is quite normal for a devicetree to be
>> +present in flash and be made available to U-Boot at runtime. What matters is
>> +where the devicetree comes from. If the other project builds a devicetree for
>> +U-Boot then it needs to support adding the things needed by U-Boot features.
>> +Without them, for example:
>> +
>> +- U-Boot may not boot because too many devices are enabled before relocation
>> +- U-Boot may not have access to the developer or production public keys used for
>> + signing
>> +- U-Boot may not support controlling whether the console is enabled
>> +- U-Boot may not be know which MMC device to boot from
>> +- U-Boot may not be able to find other firmware components that it needs to load
>> +
>> +Normally, supporting U-Boot's features is trivial, since the devicetree compiler
>> +(dtc) can compile the source, including any U-Boot pieces. So the burden is
>> +extremely low.
>> +
>> +In this case, the devicetree in the other project must track U-Boot's use of
>> +device tree, so that it remains compatible. See `Devicetree in another project`_
>> +for reasons why.
>> +
>> +If a particular version of the project is needed for a particular version of
>> +U-Boot, that must be documented in both projects.
>> +
>> +Further, it must provide a way to add configuration and other information to
>> +the devicetree for use by U-Boot, such as the `/config` node and the tags used
>> +by driver model. Note that the U-Boot in-tree devicetree must be sufficient to
>> +build and boot, so this is not a way to bypass that requirement.
>> +
>> +More specifically, tooling or command-line arguments must provide a way to
>> +add a `/config` node or items within that node, so that U-Boot can receive a
>> +suitable configuration. It must provide a way of adding `u-boot,dm-...` tags for
>> +correct operation of driver model. These options can then be used as part of the
>> +build process, which puts the firmware image together. For binman, a way must be
>> +provided to add the binman definition into the devicetree in the same way.
>> +
>> +One way to do this is to allow a .dtsi file to be merged in with the generated
>> +devicetree.
>> +
>> +Note that the burden goes both ways. If a new feature is added to U-Boot which
>> +needs support in another project, then the author of the U-Boot patch must add
>> +any required support to the other project.
>> +
>> +
>> +Passing the devicetree through to Linux
>> +---------------------------------------
>> +
>> +Ideally U-Boot and Linux use the same devicetree source, even though it is
>> +hosted in separate projects. U-Boot adds some extra pieces, such as the
>> +`config/` node and tags like `u-boot,dm-spl`. Linux adds some extra pieces, such
>> +as `linux,default-trigger` and `linux,code`. This should not interfere with
>> +each other.
>> +
>> +In principle it is possible for U-Boot's control devicetree to be passed to
>> +Linux. This is, after all, one of the goals of devicetree and the original
>> +Open Firmware project, to have the firmware provide the hardware description to
>> +the Operating System.
>> +
>> +For boards where this approach is used, care must be taken. U-Boot typically
>> +needs to 'fix up' the devicetree before passing it to Linux, e.g. to add
>> +information about the memory map, about which serial console is used, provide
>> +the kernel address space layout randomization (KASLR) seed or select whether the
>> +console should be silenced for a faster boot.
>> +
>> +Fix-ups involve modifying the devicetree. If the control devicetree is used,
>> +that means the control devicetree could be modified, while U-Boot is using it.
>> +Removing a device and reinserting it can cause problems if the devicetree offset
>> +has changed, for example, since the device will be unable to locates its
>> +devicetree properties at the expected devicetree offset, which is a fixed
>> +integer.
>> +
>> +To deal with this, it is recommended to employ one or more of the following
>> +approaches:
>> +
>> +- Make a copy of the devicetree and 'fix up' the copy, leaving the control
>> + devicetree alone
>> +- Enable `CONFIG_OF_LIVE` so that U-Boot makes its own copy of the devicetree
>> + during relocation; fixups then happen on the original flat tree
>> +- Ensure that fix-ups happen after all loading has happened and U-Boot has
>> + completed image verification
>> +
>> +In practice,the last point is typically observed, since boot_prep_linux() is
>> +called just before jumping to Linux, long after signature verification, for
>> +example. But it is important to make sure that this line is not blurred,
>> +particularly if untrusted user data is involved.
>> +
>> +
>> +Devicetree use cases that must be supported
>> +-------------------------------------------
>> +
>> +Regardless of how the devicetree is provided to U-Boot at runtime, various
>> +U-Boot features must be fully supported. This section describes some of these
>> +features and the implications for other projects.
>> +
>> +If U-Boot uses its own in-tree devicetree these features are supported
>> +automatically.
>> +
>> +
>> +Signing with U-Boot devicetree
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +U-Boot supports signing a payload so that it can be verified to have been
>> +created by a party owning a private key. This is called verified boot in U-Boot
>> +(see doc/uImage.FIT/verified-boot.txt).
>> +
>> +Typically this works by creating a FIT and then running the `mkimage` tool to
>> +add signatures for particular images. As part of this process, `mkimage` writes
>> +a public key to the U-Boot devicetree, although this can be done separately.
>> +See fdt_add_pubkey_ for patches for a suitable tool, for example.
>> +
>> +As with all configuration information, if another project is providing the
>> +devicetree to U-Boot, it must provide a way to add this public key into the
>> +devicetree it passes to U-Boot. This could be via a tooling option, making use
>> +of `mkimage`, or allowing a .dtsi file to be merged in with what is generated in
>> +the other project.
>> +
>> +
>> +Providing the binman image definition
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +In complex systems U-Boot must locate and make use of other firmware components,
>> +such as images for the user interface, files containing peripheral firmware,
>> +multiple copies of U-Boot for use with A/B boot, etc. U-Boot uses
>> +:doc:`Binman <../package/binman>` as a standard way of putting an image
>> +together.
>> +
>> +Typically this works by running binman with the devicetree as an input, to
>> +create the file image. Binman then outputs an updated devicetree which is
>> +packed in the firmware image, so U-Boot can access the binman definition and
>> +locate all the components.
>> +
>> +As with all configuration information, if another project is providing the
>> +devicetree to U-Boot, it must provide a way to add this binman definition into
>> +the devicetree it passes to U-Boot. This could be via a tooling option, making
>> +use of `binman`, or alowing a .dtsi file to be merged in with what is generated
>> +in the other project.
>> +
>> +
>> +Protecting the devicetree
>> +-------------------------
>> +
>> +U-Boot relies heavily on devicetree for correct operation. A corrupt or invalid
>> +device can cause U-Boot to fail to start, behave incorrectly, crash (e.g. if
>> +`CONFIG_OF_LIBFDT_ASSUME_MASK` is adjusted, or fail to boot an Operating System.
>> +Within U-Boot, the devicetree is as important as any other part of the source
>> +code. At ruuntime, the devicetree can be considered to be structured rodata.
>> +
>> +With secure systems, care must be taken that the devicetree is valid:
>> +
>> +- If the code / rodata has a hash or signature, the devicetree should also, if
>> + they are packaged separately.
>> +- If the code / rodata is write-protected when running, the devicetree should be
>> + also. Note that U-Boot relocates its code and devicetree, so this is not as
>> + simple as it sounds. U-Boot must write-protect these items after relocating.
>> +
>> +
>> +Why does U-Boot have its nodes and properties?
>> +----------------------------------------------
>> +
>> +See also :doc:`../devicetree/intro`.
>> +
>> +There has been pushback at the concept that U-Boot dares have its own nodes and
>> +properties in the devicetree.
>> +
>> +Apart from these nodes and properties, U-Boot uses the same bindings as Linux.
>> +A `u-boot.dtsi` file helps to keep U-Boot-specific changes in separate files,
>> +making it easier to keep devicetree source files in U-Boot in sync with Linux.
>> +
>> +As a counter-example, the Zephyr OS project takes a different approach. It uses
>> +entirely different bindings, in general, making no effort to sync devicetree
>> +source files with Linux. U-Boot strives to be compatible with Linux in a number
>> +of ways, such as source code style and common APIs, to aid porting of code
>> +between the projects. Devicetree is another way where U-Boot and Linux follow a
>> +similar approach.
>> +
>> +Fundamentally, the idea that U-Boot cannot have its own tags flies in the face
>> +of the devicetree specification (see dtspec_), which says:
>> +
>> + Nonstandard property names should specify a **unique string prefix**, such as
>> + a stock ticker symbol, identifying the name of the company **or organization**
>> + that defined the property. Examples:
>> +
>> + - fsl,channel-fifo-len
>> + - ibm,ppc-interrupt-server#s
>> + - **linux**,network-index
>> +
>> +It is also fundamentally unbalanced. Linux has many tags of its own (some 36 in
>> +version 5.13) and at least one Linux-specific node, even if you ignore things
>> +like flash partitions which clearly provide configuration information to Linux.
>> +
>> +Practically speaking there are many reasons why U-Boot has its own nodes and
>> +properties. Some examples:
>> +
>> +- Binding every device before relocation even if it won't be used, consumes time
>> + and memory: tags on each node can specify which are needed in SPL or before
>> + relocation. Linux has no such constraints.
>> +
>> +- Requiring the full clock tree to be up and running just to get the debug UART
>> + running is inefficient. It is also and self-defeating, since if that much
>> + code is working properly, you probably don't need the debug UART. A devicetree
>> + property to provide the UART input-clock frequency is a simple solution.
>> +
>> +- U-Boot does not have a user space to provide policy and configuration. It
>> + cannot do what Linux does and run programs and look up filesystems to figure
>> + out how to boot.
>> +
>> +
>> +Why not have two devicetrees?
>> +-----------------------------
>> +
>> +Setting aside the argument for restricting U-Boot from having its own nodes and
>> +properties, another idea proposed is to have two devicetrees, one for the
>> +U-Boot-specific bits (here called `special`) and one for everything else (here
>> +called `linux`).
>> +
>> +On the positive side, it might quieten the discussion alluded to in the section
>> +above. But there are many negatives to consider and many open questions to
>> +resolve.
>> +
>> +- **Bindings** - Presumably the special devicetree would have its own bindings.
>> + It would not be necessary to put a `u-boot,` prefix on anything. People coming
>> + across the devicetree source would wonder how it fits in with the Linux
>> + devicetree.
>> +
>> +- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This
>> + would need to be expanded to support two trees. Features which need to access
>> + both (such as a device driver which reads the special devicetree to get some
>> + configuration info) could become quite confusing to read and write.
>> +
>> +- **Merging** - Can the two devicetree be merged if a platform desires it? If
>> + so, how is this managed in tooling? Does it happen during the build, in which
>> + case they are not really separate at all. Or does U-Boot merge them at
>> + runtime, in which case this adds time and memory?
>> +
>> +- **Efficiency** - A second device tree adds more code and more code paths. It
>> + requires that both be made available to the code in U-Boot, e.g. via a
>> + separate pointer or argument or API. Overall the separation would certainly
>> + not speed up U-Boot, nor decrease its size.
>> +
>> +- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for
>> + U-Boot for a particular board. Would we use these same files for the special
>> + devicetree?
>> +
>> +- **Complexity** - Two devicetrees complicates the build system since it must
>> + build and package them both. Errors must be reported in such a way that it
>> + is obvious which one is failing.
>> +
>> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model
>> + are currently placed in the nodes they relate to. How would these tags
>> + reference a node that is in a separate devicetree? What extra validation would
>> + be needed?
>> +
>> +- **Storage** - How would the two devicetrees be stored in the image? At present
>> + we simply concatenate the U-Boot binary and the devicetree. We could add the
>> + special devicetree before the Linux one, so two are concatenated, but it is
>> + not pretty. We could use binman to support more complex arrangements, but only
>> + some boards use this at present, so it would be a big change.
>> +
>> +- **API** - How would another project provide two devicetree files to U-Boot at
>> + runtime? Presumably this would just be too painful. But if it doesn't, it
>> + would be unable to configure run-time features of U-Boot during the boot.
>> +
>> +- **Confusion** - No other project has two devicetrees. U-Boot would be in the
>> + unfortunate position of having to describe this fact to new users, along with
>> + the (arguably contrived) reason for the arrangement.
>> +
>
> False:
> 1) projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes.
Can you provided a link and I can update this.
> 2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system
> As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT.
> If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
I have gone to great efforts to document things here, as they work in
U-Boot today. As you know, U-Boot supports separate control and active
devicetrees. But if you are wanting to change to multiple control
trees within U-Boot, I'd say the answer is "no, thank you". If there
is a use case for that, please can you be specific about what we
cannot do with a combined devicetree?
Regards,
Simon
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-26 15:27 ` Simon Glass
@ 2021-10-26 15:57 ` François Ozog
2021-10-27 14:13 ` Simon Glass
0 siblings, 1 reply; 144+ messages in thread
From: François Ozog @ 2021-10-26 15:57 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Heinrich Schuchardt,
Ilias Apalodimas, Tom Rini, Sean Anderson, Marcel Ziswiler
On Tue, 26 Oct 2021 at 17:27, Simon Glass <sjg@chromium.org> wrote:
> Hi François,
>
> On Tue, 26 Oct 2021 at 08:31, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> > Hi Simon,
> >
> > On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg@chromium.org> wrote:
> >>
> >> At present some of the ideas and techniques behind devicetree in U-Boot
> >> are assumed, implied or unsaid. Add some documentation to cover how
> >> devicetree is build, how it can be modified and the rules about using
> >> the various CONFIG_OF_... options.
> >>
> >> Signed-off-by: Simon Glass <sjg@chromium.org>
> >> Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> >> ---
> >> This patch attracted quite a bit of discussion here:
> >>
> >>
> https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-sjg@chromium.org/
> >>
> >> I have not included the text suggested by François. While I agree that
> >> it would be useful to have an introduction in this space, I do not agree
> >> that we should have two devicetrees or that U-Boot should not have its
> own
> >> things in the devicetree, so it is not clear to me what we should
> actually
> >> write.
> >>
> >> The 'Devicetree Control in U-Boot' docs were recently merged and these
> >> provide some base info, for now.
> >>
> >> Changes in v5:
> >> - Bring into the OF_BOARD series
> >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed
> >> - Refer to the 'control' DTB in the first paragraph
> >> - Use QEMU instead of qemu
> >>
> >> Changes in v3:
> >> - Clarify the 'bug' refered to at the top
> >> - Reword 'This means that there' paragraph to explain U-Boot-specific
> things
> >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs
> >>
> >> Changes in v2:
> >> - Fix typos per Sean (thank you!) and a few others
> >> - Add a 'Use of U-Boot /config node' section
> >> - Drop mention of dm-verity since that actually uses the kernel cmdline
> >> - Explain that OF_BOARD will still work after these changes (in
> >> 'Once this bug is fixed...' paragraph)
> >> - Expand a bit on the reason why the 'Current situation' is bad
> >> - Clarify in a second place that Linux and U-Boot use the same
> devicetree
> >> in 'To be clear, while U-Boot...'
> >> - Expand on why we should have rules for other projects in
> >> 'Devicetree in another project'
> >> - Add a comment as to why devicetree in U-Boot is not 'bad design'
> >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
> >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover
> >> points raised on v1
> >> - Add 'Why does U-Boot have its nodes and properties?'
> >> - Add 'Why not have two devicetrees?'
> >>
> >> doc/develop/devicetree/dt_update.rst | 556 +++++++++++++++++++++++++++
> >> doc/develop/devicetree/index.rst | 1 +
> >> 2 files changed, 557 insertions(+)
> >> create mode 100644 doc/develop/devicetree/dt_update.rst
> >>
> >> diff --git a/doc/develop/devicetree/dt_update.rst
> b/doc/develop/devicetree/dt_update.rst
> >> new file mode 100644
> >> index 00000000000..3d4902e3592
> >> --- /dev/null
> >> +++ b/doc/develop/devicetree/dt_update.rst
> >> @@ -0,0 +1,556 @@
> >> +.. SPDX-License-Identifier: GPL-2.0+
> >> +
> >> +Updating the devicetree
> >> +=======================
> >> +
> >> +U-Boot uses devicetree for runtime configuration and storing required
> blobs or
> >> +any other information it needs to operate. This is called the 'control'
> >> +devicetree since it controls U-Boot. It is possible to update the
> control
> >> +devicetree separately from actually building U-Boot. This provides a
> good degree
> >> +of control and flexibility for firmware that uses U-Boot in
> conjunction with
> >> +other project.
> >> +
> >> +There are many reasons why it is useful to modify the devicetree after
> building
> >> +it:
> >> +
> >> +- Configuration can be changed, e.g. which UART to use
> >> +- A serial number can be added
> >> +- Public keys can be added to allow image verification
> >> +- Console output can be changed (e.g. to select serial or vidconsole)
> >> +
> >> +This section describes how to work with devicetree to accomplish your
> goals.
> >> +
> >> +See also :doc:`../devicetree/control` for a basic summary of the
> available
> >> +features.
> >> +
> >> +
> >> +Devicetree source
> >> +-----------------
> >> +
> >> +Every board in U-Boot must include a devicetree sufficient to build
> and boot
> >> +that board on suitable hardware (or emulation). This is specified
> using the
> >> +`CONFIG DEFAULT_DEVICE_TREE` option.
> >> +
> >> +
> >> +Current situation (October 2021)
> >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> +
> >> +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to
> be empty,
> >> +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an
> enormous
> >> +amount of confusion and some wasted effort. This was not intended.
> Support for
> >> +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon.
> >> +
> >> +Some of the problems created are:
> >> +
> >> +- It is not obvious that the devicetree is coming from another project
> >> +
> >> +- There is no way to see even a sample devicetree for these platform
> in U-Boot,
> >> + so it is hard to know what is going on, e.g. which devices are
> typically
> >> + present
> >> +
> >> +- The other project may not provide a way to support U-Boot's
> requirements for
> >> + devicetree, such as the /config node. Note: On the U-Boot mailing
> linst, this
> >> + was only discovered after weeks of discussion and confusion
> >> +
> >> +- For QEMU specifically, consulting two QEMU source files is required,
> for which
> >> + there are no references in U-Boot documentation. The code is
> generating a
> >> + devicetree, but it is not clear what controls affect this generation.
> >> +
> >> +Specifically on the changes in U-Bootm `CONFIG_OF_BOARD` was added in
> >> +rpi_patch_ for Raspberry Pi, which does have an in-tree devicetree,
> but this
> >> +feature has since been used for boards that don't
> >> +
> >> +Once this bug is fixed, CONFIG_OF_BOARD will override (at runtime) the
> >> +evicetree suppled with U-Boot, but will otherwise use
> CONFIG_OF_SEPARATE for the
> >> +in-tree build. So these two will become options, moving out of the
> 'choice' in
> >> +`dts/Kconfig`.
> >> +
> >> +This means that there is a basic devicetree build in the U-Boot tree,
> for
> >> +build-testing, consistency and documentation purposes, but at runtime
> U-Boot can
> >> +accept its devicetree from another source. The in-tree devicetree may
> contain
> >> +U-Boot-specific features (in u-boot*.dtsi files) and this may prove
> useful for
> >> +the other project, so it can ensure that U-Boot functions correctly
> and supports
> >> +all its expected features.
> >> +
> >> +To be clear, while U-Boot has its own copy of the devicetree source
> for each
> >> +board, this must match the Linux source, perhaps with some u-boot.dtsi
> >> +additions. The intent here is not to create a separate binding, just
> to provide
> >> +a representative devicetree in U-Boot.
> >> +
> >> +Offending boards are:
> >> +
> >> +- rpi_4 and rpi_4_32b (other rpi boards do have an in-tree devicetree)
> >> +- qemu_arm64
> >> +- qemu_arm
> >> +- qemu-ppce500
> >> +- qemu-riscv32
> >> +- qemu-riscv32_smode
> >> +- qemu-riscv64
> >> +- qemu-riscv64_smode
> >> +
> >> +All of these need to have a devicetree added in-tree. This is targeted
> to be
> >> +fixed in the 2022.01 release.
> >> +
> >> +
> >> +Building the devicetree
> >> +-----------------------
> >> +
> >> +U-Boot automatically builds the devicetree for a board, from the
> >> +`arch/<arch>/dts` directory. The Makefile in those directories has
> rules for
> >> +building devicetree files. It is preferable to avoid target-specific
> rules in
> >> +those files: i.e. all boards for a particular SoC should be built at
> once,
> >> +where practical. Apart from simplifying the Makefile, this helps to
> efficiently
> >> +(and immediately) ensure that changes in one board's DT do not break
> others that
> >> +are related. Building devicetrees is fast, so performance is seldom a
> concern
> >> +here.
> >> +
> >> +
> >> +Overriding the default devicetree
> >> +---------------------------------
> >> +
> >> +When building U-Boot, the `DEVICE_TREE` environment variable allows the
> >> +default devicetree file to be overridden at build time. This can be
> useful if
> >> +modifications have to be made to the in-tree devicetree file, for the
> benefit
> >> +of a downstream build system. Note that the in-tree devicetree must be
> >> +sufficient to build and boot, so this is not a way to bypass that
> requirement.
> >> +
> >> +
> >> +Modifying the devicetree after building
> >> +---------------------------------------
> >> +
> >> +While it is generally painful and hacky to modify the code or rodata
> of a
> >> +program after it is built, in many cases it is useful to do so, e.g.
> to add
> >> +configuration information like serial numbers, enabling/disabling
> features, etc.
> >> +
> >> +Devicetree provides a very nice solution to these problems since it is
> >> +structured data and it is relatively easy to change it, even in binary
> form
> >> +(see fdtput).
> >> +
> >> +U-Boot takes care that the devicetree is easily accessible after the
> build
> >> +process. In fact it is placed in a separate file called `u-boot.dtb`.
> If the
> >> +build system wants to modify or replace that file, it can do so. Then
> all that
> >> +is needed is to run `binman update` to update the file inside the
> image. If
> >> +binman is not used, then `u-boot-nodtb.bin` and the new `u-boot.dtb`
> can simply
> >> +be concatenated to achieve the desired result. U-Boot happily copes
> with the
> >> +devicetree growing or shrinking.
> >> +
> >> +The `u-boot.bin` image contains both pieces. While it is possible to
> locate the
> >> +devicetree within the image using the signature at the start of the
> file, this
> >> +is a bit messy.
> >> +
> >> +This is why `CONFIG_OF_SEPARATE` should always be used when building
> U-Boot.
> >> +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the
> U-Boot ELF
> >> +image as rodata, meaning that it is hard to find it and it cannot
> increase in
> >> +size.
> >> +
> >> +When modifying the devicetree, the different cases to consider are as
> follows:
> >> +
> >> +- CONFIG_OF_SEPARATE
> >> + This is easy, described above. Just change, replace or rebuild the
> >> + devicetree so it suits your needs, then rerun binman or redo the
> `cat`
> >> + operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb`
> >> +
> >> +- CONFIG_OF_EMBED
> >> + This is tricky, since the devicetree cannot easily be located. If
> the EFL
> >> + file is available, then the _dtb_dt_begin and __dtb_dt_end symbols
> can be
> >> + examined to find it. While it is possible to contract the file, it
> is not
> >> + possible to expand the file since that would involve re-linking
> >> +
> >> +- CONFIG_OF_BOARD
> >> + This is a board-specific situation, so needs to be considered on a
> >> + case-by-case base. The devicetree must be modified so that the
> correct
> >> + one is provided to U-Boot. How this is done depends entirely on the
> >> + implementation of this option for the board. It might require
> injecting the
> >> + changes into a different project somehow using tooling available
> there, or
> >> + it might involve merging an overlay file at runtime to obtain the
> desired
> >> + result.
> >> +
> >> +
> >> +Use of U-Boot /config node
> >> +--------------------------
> >> +
> >> +A common problem with firmware is that many builds are needed to deal
> with the
> >> +slight variations between different, related models. For example, one
> model may
> >> +have a TPM and another may not. Devicetree provides an excellent
> solution to
> >> +this problem, in that the devicetree to actually use on a platform can
> be
> >> +injected in the factory based on which model is being manufactured at
> the time.
> >> +
> >> +A related problem causing build proliferation is dealing with the
> differences
> >> +between development firmware, developer-friendly firmware (e.g. with
> all
> >> +security features present but with the ability to access the command
> line),
> >> +test firmware (which runs tests used in the factory), final production
> firmware
> >> +(before signing), signed firmware (where the signatures have been
> inserted) and
> >> +the like. Ideally all or most of these should use the same U-Boot
> build, with
> >> +just some options to determine the features available. For example,
> being able
> >> +to control whether the UART console or JTAG are available, on any
> image, is a
> >> +great debugging aid.
> >> +
> >> +When the firmware consists of multiple parts, it is helpful that all
> operate
> >> +the same way at runtime, regardless of how they were built. This can
> be achieved
> >> +by passing the runtime configuration (e.g. 'enable UART console) along
> the chain
> >> +through each firmware stage. It is frustrating to have to replicate a
> bug on
> >> +production firmware which does happen on developer firmware, because
> they are
> >> +completely different builds.
> >> +
> >> +The /config node provides useful functionality for this. It allows the
> different
> >> +controls to be 'factored out' of the U-Boot binary, so they can be
> controlled
> >> +separately from the initial source-code build. The node can be easily
> updated by
> >> +a build or factory tool and can control various features in U-Boot. It
> is
> >> +similar in concept to a Kconfig option, except that it can be changed
> after
> >> +U-Boot is built.
> >> +
> >> +The /config node is similar in concept to the `/chosen node`_ except
> that it is
> >> +for passing information *into* firmware instead of from firmware to the
> >> +Operating System. Also, while Linux has a (sometimes extremely long)
> command
> >> +line, U-Boot does not support this. The devicetree provides a more
> structured
> >> +approach in any case.
> >> +
> >> +
> >> +Devicetree in another project
> >> +-----------------------------
> >> +
> >> +In some cases U-Boot receive its devicetree at runtime from a program
> that calls
> >> +it. For example ARM's Trusted Firmware A (`TF-A`_) may have a
> devicetree that it
> >> +passes to U-Boot. This overrides any devicetree build by U-Boot. When
> packaging
> >> +the firmware, the U-Boot devicetree may in fact be left out if it can
> be
> >> +guaranteed that it will receive one from another project.
> >> +
> >> +In this case, the devicetree in the other project must track U-Boot's
> use of
> >> +device tree, for the following reasons:
> >> +
> >> +- U-Boot only has one devicetree. See `Why not have two devicetrees?`_.
> >> +- For a consistent firmware build, decisions made in early stages
> should be
> >> + communicated to later ones at runtime. For example, if the serial
> console is
> >> + enabled in an early stage, it should be enabled in U-Boot too.
> >> +- U-Boot is quite capable of managing its own copy of the devicetree.
> If
> >> + another project wants to bypass this (often for good reason), it is
> reasonable
> >> + that it should take on the (fairly small) requirements that U-Boot
> features
> >> + that rely on devicetree are still available
> >> +- The point here is not that *U-Boot needs this extra node*, or
> *U-Boot needs
> >> + to have this public key*. These features are present in U-Boot in
> service of
> >> + the entire firmware system. If the U-Boot features are used, but
> cannot be
> >> + supported in the normal way, then there is pressure to implement
> these
> >> + features in other ways. In the end, we would have a different
> mechanism for
> >> + every other project that uses U-Boot. This introduces duplicate ways
> of doing
> >> + the same thing, needlessly increases the complexity of the U-Boot
> source code,
> >> + forces authors to consider parallel implementations when writing new
> features,
> >> + makes U-Boot harder to test, complicates documentation and confuses
> the
> >> + runtime flow of U-Boot. If every board did things its own way rather
> than
> >> + contributing to the common code, U-Boot would lose a lot of its
> cross-platform
> >> + value.
> >> +
> >> +The above does not indicate *bad design* within U-Boot. Devicetree is
> a core
> >> +component of U-Boot and U-Boot makes use of it to the full. It solves
> a myriad
> >> +of problems that would otherwise need their own special C struct,
> binary format,
> >> +special property, tooling for viewing and updating, etc.
> >> +
> >> +Specifically, the other project must provide a way to add
> configuration and
> >> +other information to the devicetree for use by U-Boot, such as the
> /config node.
> >> +Note that the U-Boot in-tree devicetree source must be sufficient to
> build and
> >> +boot, so this is not a way to bypass that requirement.
> >> +
> >> +If binman is used, the devicetree source in U-Boot must contain the
> binman
> >> +definition so that a valid image can be build. This helps people
> discover what
> >> +other firmware components are needed and seek out appropriate
> documentation.
> >> +
> >> +If verified boot is used, the project must provide a way to inject a
> public key,
> >> +certificate or other material into the U-Boot devicetree so that it is
> available
> >> +to U-Boot at runtime. See `Signing with U-Boot devicetree`_. This may
> be
> >> +through tooling in the project itself or by making use of U-Boot's
> tooling.
> >> +
> >> +
> >> +Devicetree generated on-the-fly in another project
> >> +--------------------------------------------------
> >> +
> >> +In some rare cases, another project may wish to create a devicetree
> for U-Boot
> >> +entirely on-the-fly, then pass it to U-Boot at runtime. The only known
> example
> >> +of this at the time of writing (2021) is QEMU, for ARM (`QEMU ARM`_)
> and
> >> +RISC-V (`QEMU RISC-V`_).
> >> +
> >> +In effect, when the board boots, U-Boot is *downstream* of the other
> project.
> >> +It is entirely reliant on that project for its correct operation.
> >> +
> >> +This does not mean to imply that the other project is creating its own,
> >> +incompatible devicetree. In fact QEMU generates a valid devicetree
> which is
> >> +suitable for both U-Boot and Linux. It is quite normal for a
> devicetree to be
> >> +present in flash and be made available to U-Boot at runtime. What
> matters is
> >> +where the devicetree comes from. If the other project builds a
> devicetree for
> >> +U-Boot then it needs to support adding the things needed by U-Boot
> features.
> >> +Without them, for example:
> >> +
> >> +- U-Boot may not boot because too many devices are enabled before
> relocation
> >> +- U-Boot may not have access to the developer or production public
> keys used for
> >> + signing
> >> +- U-Boot may not support controlling whether the console is enabled
> >> +- U-Boot may not be know which MMC device to boot from
> >> +- U-Boot may not be able to find other firmware components that it
> needs to load
> >> +
> >> +Normally, supporting U-Boot's features is trivial, since the
> devicetree compiler
> >> +(dtc) can compile the source, including any U-Boot pieces. So the
> burden is
> >> +extremely low.
> >> +
> >> +In this case, the devicetree in the other project must track U-Boot's
> use of
> >> +device tree, so that it remains compatible. See `Devicetree in another
> project`_
> >> +for reasons why.
> >> +
> >> +If a particular version of the project is needed for a particular
> version of
> >> +U-Boot, that must be documented in both projects.
> >> +
> >> +Further, it must provide a way to add configuration and other
> information to
> >> +the devicetree for use by U-Boot, such as the `/config` node and the
> tags used
> >> +by driver model. Note that the U-Boot in-tree devicetree must be
> sufficient to
> >> +build and boot, so this is not a way to bypass that requirement.
> >> +
> >> +More specifically, tooling or command-line arguments must provide a
> way to
> >> +add a `/config` node or items within that node, so that U-Boot can
> receive a
> >> +suitable configuration. It must provide a way of adding
> `u-boot,dm-...` tags for
> >> +correct operation of driver model. These options can then be used as
> part of the
> >> +build process, which puts the firmware image together. For binman, a
> way must be
> >> +provided to add the binman definition into the devicetree in the same
> way.
> >> +
> >> +One way to do this is to allow a .dtsi file to be merged in with the
> generated
> >> +devicetree.
> >> +
> >> +Note that the burden goes both ways. If a new feature is added to
> U-Boot which
> >> +needs support in another project, then the author of the U-Boot patch
> must add
> >> +any required support to the other project.
> >> +
> >> +
> >> +Passing the devicetree through to Linux
> >> +---------------------------------------
> >> +
> >> +Ideally U-Boot and Linux use the same devicetree source, even though
> it is
> >> +hosted in separate projects. U-Boot adds some extra pieces, such as the
> >> +`config/` node and tags like `u-boot,dm-spl`. Linux adds some extra
> pieces, such
> >> +as `linux,default-trigger` and `linux,code`. This should not interfere
> with
> >> +each other.
> >> +
> >> +In principle it is possible for U-Boot's control devicetree to be
> passed to
> >> +Linux. This is, after all, one of the goals of devicetree and the
> original
> >> +Open Firmware project, to have the firmware provide the hardware
> description to
> >> +the Operating System.
> >> +
> >> +For boards where this approach is used, care must be taken. U-Boot
> typically
> >> +needs to 'fix up' the devicetree before passing it to Linux, e.g. to
> add
> >> +information about the memory map, about which serial console is used,
> provide
> >> +the kernel address space layout randomization (KASLR) seed or select
> whether the
> >> +console should be silenced for a faster boot.
> >> +
> >> +Fix-ups involve modifying the devicetree. If the control devicetree is
> used,
> >> +that means the control devicetree could be modified, while U-Boot is
> using it.
> >> +Removing a device and reinserting it can cause problems if the
> devicetree offset
> >> +has changed, for example, since the device will be unable to locates
> its
> >> +devicetree properties at the expected devicetree offset, which is a
> fixed
> >> +integer.
> >> +
> >> +To deal with this, it is recommended to employ one or more of the
> following
> >> +approaches:
> >> +
> >> +- Make a copy of the devicetree and 'fix up' the copy, leaving the
> control
> >> + devicetree alone
> >> +- Enable `CONFIG_OF_LIVE` so that U-Boot makes its own copy of the
> devicetree
> >> + during relocation; fixups then happen on the original flat tree
> >> +- Ensure that fix-ups happen after all loading has happened and U-Boot
> has
> >> + completed image verification
> >> +
> >> +In practice,the last point is typically observed, since
> boot_prep_linux() is
> >> +called just before jumping to Linux, long after signature
> verification, for
> >> +example. But it is important to make sure that this line is not
> blurred,
> >> +particularly if untrusted user data is involved.
> >> +
> >> +
> >> +Devicetree use cases that must be supported
> >> +-------------------------------------------
> >> +
> >> +Regardless of how the devicetree is provided to U-Boot at runtime,
> various
> >> +U-Boot features must be fully supported. This section describes some
> of these
> >> +features and the implications for other projects.
> >> +
> >> +If U-Boot uses its own in-tree devicetree these features are supported
> >> +automatically.
> >> +
> >> +
> >> +Signing with U-Boot devicetree
> >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> +
> >> +U-Boot supports signing a payload so that it can be verified to have
> been
> >> +created by a party owning a private key. This is called verified boot
> in U-Boot
> >> +(see doc/uImage.FIT/verified-boot.txt).
> >> +
> >> +Typically this works by creating a FIT and then running the `mkimage`
> tool to
> >> +add signatures for particular images. As part of this process,
> `mkimage` writes
> >> +a public key to the U-Boot devicetree, although this can be done
> separately.
> >> +See fdt_add_pubkey_ for patches for a suitable tool, for example.
> >> +
> >> +As with all configuration information, if another project is providing
> the
> >> +devicetree to U-Boot, it must provide a way to add this public key
> into the
> >> +devicetree it passes to U-Boot. This could be via a tooling option,
> making use
> >> +of `mkimage`, or allowing a .dtsi file to be merged in with what is
> generated in
> >> +the other project.
> >> +
> >> +
> >> +Providing the binman image definition
> >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> +
> >> +In complex systems U-Boot must locate and make use of other firmware
> components,
> >> +such as images for the user interface, files containing peripheral
> firmware,
> >> +multiple copies of U-Boot for use with A/B boot, etc. U-Boot uses
> >> +:doc:`Binman <../package/binman>` as a standard way of putting an image
> >> +together.
> >> +
> >> +Typically this works by running binman with the devicetree as an
> input, to
> >> +create the file image. Binman then outputs an updated devicetree which
> is
> >> +packed in the firmware image, so U-Boot can access the binman
> definition and
> >> +locate all the components.
> >> +
> >> +As with all configuration information, if another project is providing
> the
> >> +devicetree to U-Boot, it must provide a way to add this binman
> definition into
> >> +the devicetree it passes to U-Boot. This could be via a tooling
> option, making
> >> +use of `binman`, or alowing a .dtsi file to be merged in with what is
> generated
> >> +in the other project.
> >> +
> >> +
> >> +Protecting the devicetree
> >> +-------------------------
> >> +
> >> +U-Boot relies heavily on devicetree for correct operation. A corrupt
> or invalid
> >> +device can cause U-Boot to fail to start, behave incorrectly, crash
> (e.g. if
> >> +`CONFIG_OF_LIBFDT_ASSUME_MASK` is adjusted, or fail to boot an
> Operating System.
> >> +Within U-Boot, the devicetree is as important as any other part of the
> source
> >> +code. At ruuntime, the devicetree can be considered to be structured
> rodata.
> >> +
> >> +With secure systems, care must be taken that the devicetree is valid:
> >> +
> >> +- If the code / rodata has a hash or signature, the devicetree should
> also, if
> >> + they are packaged separately.
> >> +- If the code / rodata is write-protected when running, the devicetree
> should be
> >> + also. Note that U-Boot relocates its code and devicetree, so this is
> not as
> >> + simple as it sounds. U-Boot must write-protect these items after
> relocating.
> >> +
> >> +
> >> +Why does U-Boot have its nodes and properties?
> >> +----------------------------------------------
> >> +
> >> +See also :doc:`../devicetree/intro`.
> >> +
> >> +There has been pushback at the concept that U-Boot dares have its own
> nodes and
> >> +properties in the devicetree.
> >> +
> >> +Apart from these nodes and properties, U-Boot uses the same bindings
> as Linux.
> >> +A `u-boot.dtsi` file helps to keep U-Boot-specific changes in separate
> files,
> >> +making it easier to keep devicetree source files in U-Boot in sync
> with Linux.
> >> +
> >> +As a counter-example, the Zephyr OS project takes a different
> approach. It uses
> >> +entirely different bindings, in general, making no effort to sync
> devicetree
> >> +source files with Linux. U-Boot strives to be compatible with Linux in
> a number
> >> +of ways, such as source code style and common APIs, to aid porting of
> code
> >> +between the projects. Devicetree is another way where U-Boot and Linux
> follow a
> >> +similar approach.
> >> +
> >> +Fundamentally, the idea that U-Boot cannot have its own tags flies in
> the face
> >> +of the devicetree specification (see dtspec_), which says:
> >> +
> >> + Nonstandard property names should specify a **unique string
> prefix**, such as
> >> + a stock ticker symbol, identifying the name of the company **or
> organization**
> >> + that defined the property. Examples:
> >> +
> >> + - fsl,channel-fifo-len
> >> + - ibm,ppc-interrupt-server#s
> >> + - **linux**,network-index
> >> +
> >> +It is also fundamentally unbalanced. Linux has many tags of its own
> (some 36 in
> >> +version 5.13) and at least one Linux-specific node, even if you ignore
> things
> >> +like flash partitions which clearly provide configuration information
> to Linux.
> >> +
> >> +Practically speaking there are many reasons why U-Boot has its own
> nodes and
> >> +properties. Some examples:
> >> +
> >> +- Binding every device before relocation even if it won't be used,
> consumes time
> >> + and memory: tags on each node can specify which are needed in SPL or
> before
> >> + relocation. Linux has no such constraints.
> >> +
> >> +- Requiring the full clock tree to be up and running just to get the
> debug UART
> >> + running is inefficient. It is also and self-defeating, since if that
> much
> >> + code is working properly, you probably don't need the debug UART. A
> devicetree
> >> + property to provide the UART input-clock frequency is a simple
> solution.
> >> +
> >> +- U-Boot does not have a user space to provide policy and
> configuration. It
> >> + cannot do what Linux does and run programs and look up filesystems
> to figure
> >> + out how to boot.
> >> +
> >> +
> >> +Why not have two devicetrees?
> >> +-----------------------------
> >> +
> >> +Setting aside the argument for restricting U-Boot from having its own
> nodes and
> >> +properties, another idea proposed is to have two devicetrees, one for
> the
> >> +U-Boot-specific bits (here called `special`) and one for everything
> else (here
> >> +called `linux`).
> >> +
> >> +On the positive side, it might quieten the discussion alluded to in
> the section
> >> +above. But there are many negatives to consider and many open
> questions to
> >> +resolve.
> >> +
> >> +- **Bindings** - Presumably the special devicetree would have its own
> bindings.
> >> + It would not be necessary to put a `u-boot,` prefix on anything.
> People coming
> >> + across the devicetree source would wonder how it fits in with the
> Linux
> >> + devicetree.
> >> +
> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the
> devicetree. This
> >> + would need to be expanded to support two trees. Features which need
> to access
> >> + both (such as a device driver which reads the special devicetree to
> get some
> >> + configuration info) could become quite confusing to read and write.
> >> +
> >> +- **Merging** - Can the two devicetree be merged if a platform desires
> it? If
> >> + so, how is this managed in tooling? Does it happen during the build,
> in which
> >> + case they are not really separate at all. Or does U-Boot merge them
> at
> >> + runtime, in which case this adds time and memory?
> >> +
> >> +- **Efficiency** - A second device tree adds more code and more code
> paths. It
> >> + requires that both be made available to the code in U-Boot, e.g. via
> a
> >> + separate pointer or argument or API. Overall the separation would
> certainly
> >> + not speed up U-Boot, nor decrease its size.
> >> +
> >> +- **Source code** - At present `u-boot.dtsi` files provide the pieces
> needed for
> >> + U-Boot for a particular board. Would we use these same files for the
> special
> >> + devicetree?
> >> +
> >> +- **Complexity** - Two devicetrees complicates the build system since
> it must
> >> + build and package them both. Errors must be reported in such a way
> that it
> >> + is obvious which one is failing.
> >> +
> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver
> model
> >> + are currently placed in the nodes they relate to. How would these
> tags
> >> + reference a node that is in a separate devicetree? What extra
> validation would
> >> + be needed?
> >> +
> >> +- **Storage** - How would the two devicetrees be stored in the image?
> At present
> >> + we simply concatenate the U-Boot binary and the devicetree. We could
> add the
> >> + special devicetree before the Linux one, so two are concatenated,
> but it is
> >> + not pretty. We could use binman to support more complex
> arrangements, but only
> >> + some boards use this at present, so it would be a big change.
> >> +
> >> +- **API** - How would another project provide two devicetree files to
> U-Boot at
> >> + runtime? Presumably this would just be too painful. But if it
> doesn't, it
> >> + would be unable to configure run-time features of U-Boot during the
> boot.
> >> +
> >> +- **Confusion** - No other project has two devicetrees. U-Boot would
> be in the
> >> + unfortunate position of having to describe this fact to new users,
> along with
> >> + the (arguably contrived) reason for the arrangement.
> >> +
> >
> > False:
> > 1) projects in trustedfirmware.org are built to have multiple FDT
> objects, some for "dynamic" configuration purposes.
>
> Can you provided a link and I can update this.
>
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
Bindings:
for FCONF:
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_properties.html
for FF-A:
https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
For chain-of-trust:
https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.html
For some code:
https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fiptool/tbbr_config.c
From there you can wander and see how dynamic config sections of the FIP
can contain component specific DTs.
U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
>
> > 2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in
> addition to operating system
> > As Ilias said, this is not about documentation about the current use of
> DT in U-Boot, but justification of your views on DT.
> > If taken by the letter, I feel (may be wrong though) that your views
> prevent establish the DT lifecycle and usage as per the desire of vendors,
> partners and customers that supports Arm SystemReady standards.
>
> I have gone to great efforts to document things here, as they work in
> U-Boot today. As you know, U-Boot supports separate control and active
> devicetrees.
I don't know what is an active device tree. Is it the device tree to be
passed to OS?
> But if you are wanting to change to multiple control
> trees within U-Boot, I'd say the answer is "no, thank you".
I see only one control DT.
There is a possibility to store it securely in NT_FW_CONFIG section of a
FIP. it also has associated signature plus hash mechanisms to attest
authenticity of it (do not need signature in DT to allow verification:
this is the associated content certificate section that contains the valid
hashes).
You can certain have a similar mechanism for binman.
> If there
> is a use case for that, please can you be specific about what we
> cannot do with a combined devicetree?
>
> Regards,
> Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-26 15:57 ` François Ozog
@ 2021-10-27 14:13 ` Simon Glass
2021-10-27 15:38 ` François Ozog
0 siblings, 1 reply; 144+ messages in thread
From: Simon Glass @ 2021-10-27 14:13 UTC (permalink / raw)
To: François Ozog
Cc: U-Boot Mailing List, Mark Kettenis, Heinrich Schuchardt,
Ilias Apalodimas, Tom Rini, Sean Anderson, Marcel Ziswiler
Hi François,
On Tue, 26 Oct 2021 at 09:57, François Ozog <francois.ozog@linaro.org> wrote:
>
>
>
> On Tue, 26 Oct 2021 at 17:27, Simon Glass <sjg@chromium.org> wrote:
>>
>> Hi François,
>>
>> On Tue, 26 Oct 2021 at 08:31, François Ozog <francois.ozog@linaro.org> wrote:
>> >
>> > Hi Simon,
>> >
>> > On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg@chromium.org> wrote:
>> >>
>> >> At present some of the ideas and techniques behind devicetree in U-Boot
>> >> are assumed, implied or unsaid. Add some documentation to cover how
>> >> devicetree is build, how it can be modified and the rules about using
>> >> the various CONFIG_OF_... options.
>> >>
[..]
>> >> +Why not have two devicetrees?
>> >> +-----------------------------
>> >> +
>> >> +Setting aside the argument for restricting U-Boot from having its own nodes and
>> >> +properties, another idea proposed is to have two devicetrees, one for the
>> >> +U-Boot-specific bits (here called `special`) and one for everything else (here
>> >> +called `linux`).
>> >> +
>> >> +On the positive side, it might quieten the discussion alluded to in the section
>> >> +above. But there are many negatives to consider and many open questions to
>> >> +resolve.
>> >> +
>> >> +- **Bindings** - Presumably the special devicetree would have its own bindings.
>> >> + It would not be necessary to put a `u-boot,` prefix on anything. People coming
>> >> + across the devicetree source would wonder how it fits in with the Linux
>> >> + devicetree.
>> >> +
>> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This
>> >> + would need to be expanded to support two trees. Features which need to access
>> >> + both (such as a device driver which reads the special devicetree to get some
>> >> + configuration info) could become quite confusing to read and write.
>> >> +
>> >> +- **Merging** - Can the two devicetree be merged if a platform desires it? If
>> >> + so, how is this managed in tooling? Does it happen during the build, in which
>> >> + case they are not really separate at all. Or does U-Boot merge them at
>> >> + runtime, in which case this adds time and memory?
>> >> +
>> >> +- **Efficiency** - A second device tree adds more code and more code paths. It
>> >> + requires that both be made available to the code in U-Boot, e.g. via a
>> >> + separate pointer or argument or API. Overall the separation would certainly
>> >> + not speed up U-Boot, nor decrease its size.
>> >> +
>> >> +- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for
>> >> + U-Boot for a particular board. Would we use these same files for the special
>> >> + devicetree?
>> >> +
>> >> +- **Complexity** - Two devicetrees complicates the build system since it must
>> >> + build and package them both. Errors must be reported in such a way that it
>> >> + is obvious which one is failing.
>> >> +
>> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model
>> >> + are currently placed in the nodes they relate to. How would these tags
>> >> + reference a node that is in a separate devicetree? What extra validation would
>> >> + be needed?
>> >> +
>> >> +- **Storage** - How would the two devicetrees be stored in the image? At present
>> >> + we simply concatenate the U-Boot binary and the devicetree. We could add the
>> >> + special devicetree before the Linux one, so two are concatenated, but it is
>> >> + not pretty. We could use binman to support more complex arrangements, but only
>> >> + some boards use this at present, so it would be a big change.
>> >> +
>> >> +- **API** - How would another project provide two devicetree files to U-Boot at
>> >> + runtime? Presumably this would just be too painful. But if it doesn't, it
>> >> + would be unable to configure run-time features of U-Boot during the boot.
>> >> +
>> >> +- **Confusion** - No other project has two devicetrees. U-Boot would be in the
>> >> + unfortunate position of having to describe this fact to new users, along with
>> >> + the (arguably contrived) reason for the arrangement.
>> >> +
>> >
>> > False:
>> > 1) projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes.
>>
>> Can you provided a link and I can update this.
>
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> Bindings:
> for FCONF: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_properties.html
> for FF-A: https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
> For chain-of-trust: https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.html
>
> For some code:
> https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fiptool/tbbr_config.c
> From there you can wander and see how dynamic config sections of the FIP can contain component specific DTs.
> U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
OK I can mention that TF-A supports multiple devicetrees if you like,
but I'm not sure we are talking about the same thing.
U-Boot also supports multiple devicetrees in the build - e.g. SPL and
U-Boot proper. With binman you can create several copies of them for
use with A/B boot, for example. But only one is used as a control DTB
by a particular U-Boot phase at a time. Do you see what I mean?
>>
>> > 2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system
>> > As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT.
>> > If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
>>
>> I have gone to great efforts to document things here, as they work in
>> U-Boot today. As you know, U-Boot supports separate control and active
>> devicetrees.
>
> I don't know what is an active device tree. Is it the device tree to be passed to OS?
Yes that's right.
>>
>> But if you are wanting to change to multiple control
>> trees within U-Boot, I'd say the answer is "no, thank you".
>
> I see only one control DT.
OK good.
> There is a possibility to store it securely in NT_FW_CONFIG section of a FIP. it also has associated signature plus hash mechanisms to attest authenticity of it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes).
What does NT mean? I suppose FW means firmware.
It doesn't really matter where it is stored, so long as U-Boot can access it.
> You can certain have a similar mechanism for binman.
Note that binman is a packaging tool. Perhaps you should add FIP
support to it if FIP is going to be required too now?
What I would like, to package up the firmware for ANY board, after all
the building is done in various projects:
binman -b <board>
>>
>> If there
>> is a use case for that, please can you be specific about what we
>> cannot do with a combined devicetree?
Regards,
SImon
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-27 14:13 ` Simon Glass
@ 2021-10-27 15:38 ` François Ozog
2021-10-27 18:32 ` Simon Glass
2021-10-27 19:48 ` Tom Rini
0 siblings, 2 replies; 144+ messages in thread
From: François Ozog @ 2021-10-27 15:38 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Heinrich Schuchardt,
Ilias Apalodimas, Tom Rini, Sean Anderson, Marcel Ziswiler
Hi Simon,
On Wed, 27 Oct 2021 at 16:13, Simon Glass <sjg@chromium.org> wrote:
> Hi François,
>
> On Tue, 26 Oct 2021 at 09:57, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> >
> >
> > On Tue, 26 Oct 2021 at 17:27, Simon Glass <sjg@chromium.org> wrote:
> >>
> >> Hi François,
> >>
> >> On Tue, 26 Oct 2021 at 08:31, François Ozog <francois.ozog@linaro.org>
> wrote:
> >> >
> >> > Hi Simon,
> >> >
> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg@chromium.org> wrote:
> >> >>
> >> >> At present some of the ideas and techniques behind devicetree in
> U-Boot
> >> >> are assumed, implied or unsaid. Add some documentation to cover how
> >> >> devicetree is build, how it can be modified and the rules about using
> >> >> the various CONFIG_OF_... options.
> >> >>
>
> [..]
>
> >> >> +Why not have two devicetrees?
> >> >> +-----------------------------
> >> >> +
> >> >> +Setting aside the argument for restricting U-Boot from having its
> own nodes and
> >> >> +properties, another idea proposed is to have two devicetrees, one
> for the
> >> >> +U-Boot-specific bits (here called `special`) and one for everything
> else (here
> >> >> +called `linux`).
> >> >> +
> >> >> +On the positive side, it might quieten the discussion alluded to in
> the section
> >> >> +above. But there are many negatives to consider and many open
> questions to
> >> >> +resolve.
> >> >> +
> >> >> +- **Bindings** - Presumably the special devicetree would have its
> own bindings.
> >> >> + It would not be necessary to put a `u-boot,` prefix on anything.
> People coming
> >> >> + across the devicetree source would wonder how it fits in with the
> Linux
> >> >> + devicetree.
> >> >> +
> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the
> devicetree. This
> >> >> + would need to be expanded to support two trees. Features which
> need to access
> >> >> + both (such as a device driver which reads the special devicetree
> to get some
> >> >> + configuration info) could become quite confusing to read and
> write.
> >> >> +
> >> >> +- **Merging** - Can the two devicetree be merged if a platform
> desires it? If
> >> >> + so, how is this managed in tooling? Does it happen during the
> build, in which
> >> >> + case they are not really separate at all. Or does U-Boot merge
> them at
> >> >> + runtime, in which case this adds time and memory?
> >> >> +
> >> >> +- **Efficiency** - A second device tree adds more code and more
> code paths. It
> >> >> + requires that both be made available to the code in U-Boot, e.g.
> via a
> >> >> + separate pointer or argument or API. Overall the separation would
> certainly
> >> >> + not speed up U-Boot, nor decrease its size.
> >> >> +
> >> >> +- **Source code** - At present `u-boot.dtsi` files provide the
> pieces needed for
> >> >> + U-Boot for a particular board. Would we use these same files for
> the special
> >> >> + devicetree?
> >> >> +
> >> >> +- **Complexity** - Two devicetrees complicates the build system
> since it must
> >> >> + build and package them both. Errors must be reported in such a
> way that it
> >> >> + is obvious which one is failing.
> >> >> +
> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by
> driver model
> >> >> + are currently placed in the nodes they relate to. How would these
> tags
> >> >> + reference a node that is in a separate devicetree? What extra
> validation would
> >> >> + be needed?
> >> >> +
> >> >> +- **Storage** - How would the two devicetrees be stored in the
> image? At present
> >> >> + we simply concatenate the U-Boot binary and the devicetree. We
> could add the
> >> >> + special devicetree before the Linux one, so two are concatenated,
> but it is
> >> >> + not pretty. We could use binman to support more complex
> arrangements, but only
> >> >> + some boards use this at present, so it would be a big change.
> >> >> +
> >> >> +- **API** - How would another project provide two devicetree files
> to U-Boot at
> >> >> + runtime? Presumably this would just be too painful. But if it
> doesn't, it
> >> >> + would be unable to configure run-time features of U-Boot during
> the boot.
> >> >> +
> >> >> +- **Confusion** - No other project has two devicetrees. U-Boot
> would be in the
> >> >> + unfortunate position of having to describe this fact to new
> users, along with
> >> >> + the (arguably contrived) reason for the arrangement.
> >> >> +
> >> >
> >> > False:
> >> > 1) projects in trustedfirmware.org are built to have multiple FDT
> objects, some for "dynamic" configuration purposes.
> >>
> >> Can you provided a link and I can update this.
> >
> >
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> > Bindings:
> > for FCONF:
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_properties.html
> > for FF-A:
> https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
> > For chain-of-trust:
> https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.html
> >
> > For some code:
> >
> https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fiptool/tbbr_config.c
> > From there you can wander and see how dynamic config sections of the FIP
> can contain component specific DTs.
> > U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
>
> OK I can mention that TF-A supports multiple devicetrees if you like,
> but I'm not sure we are talking about the same thing.
>
> If I take a possible scenario: OP-TEE to deal with 3 different device
trees:
- the one that will be passed to the OS and for which it may want to do
some fixups
- the one that it is using to run (it may have secure devices that are
entirely not visible to any normal world OS)
- the one that it gets from the FIP and contains runtime configuration
parameters, accessed through FCONF library)
> U-Boot also supports multiple devicetrees in the build - e.g. SPL and
> U-Boot proper. With binman you can create several copies of them for
> use with A/B boot, for example. But only one is used as a control DTB
> by a particular U-Boot phase at a time. Do you see what I mean?
>
> >>
> >> > 2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in
> addition to operating system
> >> > As Ilias said, this is not about documentation about the current use
> of DT in U-Boot, but justification of your views on DT.
> >> > If taken by the letter, I feel (may be wrong though) that your views
> prevent establish the DT lifecycle and usage as per the desire of vendors,
> partners and customers that supports Arm SystemReady standards.
> >>
> >> I have gone to great efforts to document things here, as they work in
> >> U-Boot today. As you know, U-Boot supports separate control and active
> >> devicetrees.
> >
> > I don't know what is an active device tree. Is it the device tree to be
> passed to OS?
>
> Yes that's right.
>
> >>
> >> But if you are wanting to change to multiple control
> >> trees within U-Boot, I'd say the answer is "no, thank you".
> >
> > I see only one control DT.
>
> OK good.
>
> > There is a possibility to store it securely in NT_FW_CONFIG section of a
> FIP. it also has associated signature plus hash mechanisms to attest
> authenticity of it (do not need signature in DT to allow verification:
> this is the associated content certificate section that contains the valid
> hashes).
>
> What does NT mean? I suppose FW means firmware.
>
Non Trusted; it means normal world as opposed to secure world.
It feels unfortunate to say non trusted while it is trusted but running
outside secure world ;-)
>
> It doesn't really matter where it is stored, so long as U-Boot can access
> it.
>
> > You can certain have a similar mechanism for binman.
>
> Note that binman is a packaging tool. Perhaps you should add FIP
> support to it if FIP is going to be required too now?
>
> There may be a need for a FIP explanation. I'll check with other guys to
propose text.
> What I would like, to package up the firmware for ANY board, after all
> the building is done in various projects:
>
> binman -b <board>
>
> FIP deals with a number of firmwares like the SCP and MCP ones running on
other micro-controllers of a board.
So in a sense it is an arm targeted tool.
If you want to package firmware for arm boards with binman you will have to
deal with those firmwares as well as secure world and its trusted services
as secure partitions that are being developed (including when
virtualization is in operation in the secure world).
So in a word, trying to do this is a big undertaking, but you can try.
In a short term future (see Alibaba and Marvell announcements) you will
have to deal with Arm v9 realms and associated firmware.
> >>
> >> If there
> >> is a use case for that, please can you be specific about what we
> >> cannot do with a combined devicetree?
>
> Regards,
> SImon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-27 15:38 ` François Ozog
@ 2021-10-27 18:32 ` Simon Glass
2021-10-27 19:12 ` Ilias Apalodimas
2021-10-27 19:46 ` François Ozog
2021-10-27 19:48 ` Tom Rini
1 sibling, 2 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-27 18:32 UTC (permalink / raw)
To: François Ozog
Cc: U-Boot Mailing List, Mark Kettenis, Heinrich Schuchardt,
Ilias Apalodimas, Tom Rini, Sean Anderson, Marcel Ziswiler
Hi François,
On Wed, 27 Oct 2021 at 09:38, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon,
>
> On Wed, 27 Oct 2021 at 16:13, Simon Glass <sjg@chromium.org> wrote:
>>
>> Hi François,
>>
>> On Tue, 26 Oct 2021 at 09:57, François Ozog <francois.ozog@linaro.org> wrote:
>> >
>> >
>> >
>> > On Tue, 26 Oct 2021 at 17:27, Simon Glass <sjg@chromium.org> wrote:
>> >>
>> >> Hi François,
>> >>
>> >> On Tue, 26 Oct 2021 at 08:31, François Ozog <francois.ozog@linaro.org> wrote:
>> >> >
>> >> > Hi Simon,
>> >> >
>> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg@chromium.org> wrote:
>> >> >>
>> >> >> At present some of the ideas and techniques behind devicetree in U-Boot
>> >> >> are assumed, implied or unsaid. Add some documentation to cover how
>> >> >> devicetree is build, how it can be modified and the rules about using
>> >> >> the various CONFIG_OF_... options.
>> >> >>
>>
>> [..]
>>
>> >> >> +Why not have two devicetrees?
>> >> >> +-----------------------------
>> >> >> +
>> >> >> +Setting aside the argument for restricting U-Boot from having its own nodes and
>> >> >> +properties, another idea proposed is to have two devicetrees, one for the
>> >> >> +U-Boot-specific bits (here called `special`) and one for everything else (here
>> >> >> +called `linux`).
>> >> >> +
>> >> >> +On the positive side, it might quieten the discussion alluded to in the section
>> >> >> +above. But there are many negatives to consider and many open questions to
>> >> >> +resolve.
>> >> >> +
>> >> >> +- **Bindings** - Presumably the special devicetree would have its own bindings.
>> >> >> + It would not be necessary to put a `u-boot,` prefix on anything. People coming
>> >> >> + across the devicetree source would wonder how it fits in with the Linux
>> >> >> + devicetree.
>> >> >> +
>> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This
>> >> >> + would need to be expanded to support two trees. Features which need to access
>> >> >> + both (such as a device driver which reads the special devicetree to get some
>> >> >> + configuration info) could become quite confusing to read and write.
>> >> >> +
>> >> >> +- **Merging** - Can the two devicetree be merged if a platform desires it? If
>> >> >> + so, how is this managed in tooling? Does it happen during the build, in which
>> >> >> + case they are not really separate at all. Or does U-Boot merge them at
>> >> >> + runtime, in which case this adds time and memory?
>> >> >> +
>> >> >> +- **Efficiency** - A second device tree adds more code and more code paths. It
>> >> >> + requires that both be made available to the code in U-Boot, e.g. via a
>> >> >> + separate pointer or argument or API. Overall the separation would certainly
>> >> >> + not speed up U-Boot, nor decrease its size.
>> >> >> +
>> >> >> +- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for
>> >> >> + U-Boot for a particular board. Would we use these same files for the special
>> >> >> + devicetree?
>> >> >> +
>> >> >> +- **Complexity** - Two devicetrees complicates the build system since it must
>> >> >> + build and package them both. Errors must be reported in such a way that it
>> >> >> + is obvious which one is failing.
>> >> >> +
>> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model
>> >> >> + are currently placed in the nodes they relate to. How would these tags
>> >> >> + reference a node that is in a separate devicetree? What extra validation would
>> >> >> + be needed?
>> >> >> +
>> >> >> +- **Storage** - How would the two devicetrees be stored in the image? At present
>> >> >> + we simply concatenate the U-Boot binary and the devicetree. We could add the
>> >> >> + special devicetree before the Linux one, so two are concatenated, but it is
>> >> >> + not pretty. We could use binman to support more complex arrangements, but only
>> >> >> + some boards use this at present, so it would be a big change.
>> >> >> +
>> >> >> +- **API** - How would another project provide two devicetree files to U-Boot at
>> >> >> + runtime? Presumably this would just be too painful. But if it doesn't, it
>> >> >> + would be unable to configure run-time features of U-Boot during the boot.
>> >> >> +
>> >> >> +- **Confusion** - No other project has two devicetrees. U-Boot would be in the
>> >> >> + unfortunate position of having to describe this fact to new users, along with
>> >> >> + the (arguably contrived) reason for the arrangement.
>> >> >> +
>> >> >
>> >> > False:
>> >> > 1) projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes.
>> >>
>> >> Can you provided a link and I can update this.
>> >
>> > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
>> > Bindings:
>> > for FCONF: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_properties.html
>> > for FF-A: https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
>> > For chain-of-trust: https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.html
>> >
>> > For some code:
>> > https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fiptool/tbbr_config.c
>> > From there you can wander and see how dynamic config sections of the FIP can contain component specific DTs.
>> > U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
>>
>> OK I can mention that TF-A supports multiple devicetrees if you like,
>> but I'm not sure we are talking about the same thing.
>>
> If I take a possible scenario: OP-TEE to deal with 3 different device trees:
> - the one that will be passed to the OS and for which it may want to do some fixups
> - the one that it is using to run (it may have secure devices that are entirely not visible to any normal world OS)
> - the one that it gets from the FIP and contains runtime configuration parameters, accessed through FCONF library)
>
>>
>> U-Boot also supports multiple devicetrees in the build - e.g. SPL and
>> U-Boot proper. With binman you can create several copies of them for
>> use with A/B boot, for example. But only one is used as a control DTB
>> by a particular U-Boot phase at a time. Do you see what I mean?
>>
>> >>
>> >> > 2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system
>> >> > As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT.
>> >> > If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
>> >>
>> >> I have gone to great efforts to document things here, as they work in
>> >> U-Boot today. As you know, U-Boot supports separate control and active
>> >> devicetrees.
>> >
>> > I don't know what is an active device tree. Is it the device tree to be passed to OS?
>>
>> Yes that's right.
>>
>> >>
>> >> But if you are wanting to change to multiple control
>> >> trees within U-Boot, I'd say the answer is "no, thank you".
>> >
>> > I see only one control DT.
>>
>> OK good.
>>
>> > There is a possibility to store it securely in NT_FW_CONFIG section of a FIP. it also has associated signature plus hash mechanisms to attest authenticity of it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes).
>>
>> What does NT mean? I suppose FW means firmware.
>
> Non Trusted; it means normal world as opposed to secure world.
> It feels unfortunate to say non trusted while it is trusted but running outside secure world ;-)
OK, good, so long as it doesn't mean Windows NT I am happy.
>>
>>
>> It doesn't really matter where it is stored, so long as U-Boot can access it.
>>
>> > You can certain have a similar mechanism for binman.
>>
>> Note that binman is a packaging tool. Perhaps you should add FIP
>> support to it if FIP is going to be required too now?
>>
> There may be a need for a FIP explanation. I'll check with other guys to propose text.
I mean add an entry type to binman for FIP. It supports CBFS already,
for example.
>
>>
>> What I would like, to package up the firmware for ANY board, after all
>> the building is done in various projects:
>>
>> binman -b <board>
>>
> FIP deals with a number of firmwares like the SCP and MCP ones running on other micro-controllers of a board.
> So in a sense it is an arm targeted tool.
> If you want to package firmware for arm boards with binman you will have to deal with those firmwares as well as secure world and its trusted services as secure partitions that are being developed (including when virtualization is in operation in the secure world).
> So in a word, trying to do this is a big undertaking, but you can try.
Binman supports adding firmware for microcontrollers. For example, see here:
https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/dts/flashmap-16mb-x86-rw.dtsi#L64
That is a Chrome OS EC binary, one of three in the image.
This is not ARM-specific. That image is actually for x86 Apollo Lake.
> In a short term future (see Alibaba and Marvell announcements) you will have to deal with Arm v9 realms and associated firmware.
Why me? Perhaps Linaro could take this on instead of working in a
separate tool and domain? You guys could really pull things together
and reduce the fragmentation, if you took it on.
Honestly it is hard enough to even get Linaro people to write a test
for code they have written. What gives?
>>
>> >>
>> >> If there
>> >> is a use case for that, please can you be specific about what we
>> >> cannot do with a combined devicetree?
Regards,
SImon
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-27 18:32 ` Simon Glass
@ 2021-10-27 19:12 ` Ilias Apalodimas
2021-10-27 19:52 ` Simon Glass
2021-10-27 19:46 ` François Ozog
1 sibling, 1 reply; 144+ messages in thread
From: Ilias Apalodimas @ 2021-10-27 19:12 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, U-Boot Mailing List, Mark Kettenis,
Heinrich Schuchardt, Tom Rini, Sean Anderson, Marcel Ziswiler
On Wed, 27 Oct 2021 at 21:33, Simon Glass <sjg@chromium.org> wrote:
>
> Hi François,
>
> On Wed, 27 Oct 2021 at 09:38, François Ozog <francois.ozog@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Wed, 27 Oct 2021 at 16:13, Simon Glass <sjg@chromium.org> wrote:
> >>
> >> Hi François,
> >>
> >> On Tue, 26 Oct 2021 at 09:57, François Ozog <francois.ozog@linaro.org> wrote:
> >> >
> >> >
> >> >
> >> > On Tue, 26 Oct 2021 at 17:27, Simon Glass <sjg@chromium.org> wrote:
> >> >>
> >> >> Hi François,
> >> >>
> >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog <francois.ozog@linaro.org> wrote:
> >> >> >
> >> >> > Hi Simon,
> >> >> >
> >> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg@chromium.org> wrote:
> >> >> >>
> >> >> >> At present some of the ideas and techniques behind devicetree in U-Boot
> >> >> >> are assumed, implied or unsaid. Add some documentation to cover how
> >> >> >> devicetree is build, how it can be modified and the rules about using
> >> >> >> the various CONFIG_OF_... options.
> >> >> >>
> >>
> >> [..]
> >>
> >> >> >> +Why not have two devicetrees?
> >> >> >> +-----------------------------
> >> >> >> +
> >> >> >> +Setting aside the argument for restricting U-Boot from having its own nodes and
> >> >> >> +properties, another idea proposed is to have two devicetrees, one for the
> >> >> >> +U-Boot-specific bits (here called `special`) and one for everything else (here
> >> >> >> +called `linux`).
> >> >> >> +
> >> >> >> +On the positive side, it might quieten the discussion alluded to in the section
> >> >> >> +above. But there are many negatives to consider and many open questions to
> >> >> >> +resolve.
> >> >> >> +
> >> >> >> +- **Bindings** - Presumably the special devicetree would have its own bindings.
> >> >> >> + It would not be necessary to put a `u-boot,` prefix on anything. People coming
> >> >> >> + across the devicetree source would wonder how it fits in with the Linux
> >> >> >> + devicetree.
> >> >> >> +
> >> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This
> >> >> >> + would need to be expanded to support two trees. Features which need to access
> >> >> >> + both (such as a device driver which reads the special devicetree to get some
> >> >> >> + configuration info) could become quite confusing to read and write.
> >> >> >> +
> >> >> >> +- **Merging** - Can the two devicetree be merged if a platform desires it? If
> >> >> >> + so, how is this managed in tooling? Does it happen during the build, in which
> >> >> >> + case they are not really separate at all. Or does U-Boot merge them at
> >> >> >> + runtime, in which case this adds time and memory?
> >> >> >> +
> >> >> >> +- **Efficiency** - A second device tree adds more code and more code paths. It
> >> >> >> + requires that both be made available to the code in U-Boot, e.g. via a
> >> >> >> + separate pointer or argument or API. Overall the separation would certainly
> >> >> >> + not speed up U-Boot, nor decrease its size.
> >> >> >> +
> >> >> >> +- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for
> >> >> >> + U-Boot for a particular board. Would we use these same files for the special
> >> >> >> + devicetree?
> >> >> >> +
> >> >> >> +- **Complexity** - Two devicetrees complicates the build system since it must
> >> >> >> + build and package them both. Errors must be reported in such a way that it
> >> >> >> + is obvious which one is failing.
> >> >> >> +
> >> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model
> >> >> >> + are currently placed in the nodes they relate to. How would these tags
> >> >> >> + reference a node that is in a separate devicetree? What extra validation would
> >> >> >> + be needed?
> >> >> >> +
> >> >> >> +- **Storage** - How would the two devicetrees be stored in the image? At present
> >> >> >> + we simply concatenate the U-Boot binary and the devicetree. We could add the
> >> >> >> + special devicetree before the Linux one, so two are concatenated, but it is
> >> >> >> + not pretty. We could use binman to support more complex arrangements, but only
> >> >> >> + some boards use this at present, so it would be a big change.
> >> >> >> +
> >> >> >> +- **API** - How would another project provide two devicetree files to U-Boot at
> >> >> >> + runtime? Presumably this would just be too painful. But if it doesn't, it
> >> >> >> + would be unable to configure run-time features of U-Boot during the boot.
> >> >> >> +
> >> >> >> +- **Confusion** - No other project has two devicetrees. U-Boot would be in the
> >> >> >> + unfortunate position of having to describe this fact to new users, along with
> >> >> >> + the (arguably contrived) reason for the arrangement.
> >> >> >> +
> >> >> >
> >> >> > False:
> >> >> > 1) projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes.
> >> >>
> >> >> Can you provided a link and I can update this.
> >> >
> >> > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> >> > Bindings:
> >> > for FCONF: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_properties.html
> >> > for FF-A: https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
> >> > For chain-of-trust: https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.html
> >> >
> >> > For some code:
> >> > https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fiptool/tbbr_config.c
> >> > From there you can wander and see how dynamic config sections of the FIP can contain component specific DTs.
> >> > U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
> >>
> >> OK I can mention that TF-A supports multiple devicetrees if you like,
> >> but I'm not sure we are talking about the same thing.
> >>
> > If I take a possible scenario: OP-TEE to deal with 3 different device trees:
> > - the one that will be passed to the OS and for which it may want to do some fixups
> > - the one that it is using to run (it may have secure devices that are entirely not visible to any normal world OS)
> > - the one that it gets from the FIP and contains runtime configuration parameters, accessed through FCONF library)
> >
> >>
> >> U-Boot also supports multiple devicetrees in the build - e.g. SPL and
> >> U-Boot proper. With binman you can create several copies of them for
> >> use with A/B boot, for example. But only one is used as a control DTB
> >> by a particular U-Boot phase at a time. Do you see what I mean?
> >>
> >> >>
> >> >> > 2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system
> >> >> > As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT.
> >> >> > If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
> >> >>
> >> >> I have gone to great efforts to document things here, as they work in
> >> >> U-Boot today. As you know, U-Boot supports separate control and active
> >> >> devicetrees.
> >> >
> >> > I don't know what is an active device tree. Is it the device tree to be passed to OS?
> >>
> >> Yes that's right.
> >>
> >> >>
> >> >> But if you are wanting to change to multiple control
> >> >> trees within U-Boot, I'd say the answer is "no, thank you".
> >> >
> >> > I see only one control DT.
> >>
> >> OK good.
> >>
> >> > There is a possibility to store it securely in NT_FW_CONFIG section of a FIP. it also has associated signature plus hash mechanisms to attest authenticity of it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes).
> >>
> >> What does NT mean? I suppose FW means firmware.
> >
> > Non Trusted; it means normal world as opposed to secure world.
> > It feels unfortunate to say non trusted while it is trusted but running outside secure world ;-)
>
> OK, good, so long as it doesn't mean Windows NT I am happy.
>
> >>
> >>
> >> It doesn't really matter where it is stored, so long as U-Boot can access it.
> >>
> >> > You can certain have a similar mechanism for binman.
> >>
> >> Note that binman is a packaging tool. Perhaps you should add FIP
> >> support to it if FIP is going to be required too now?
> >>
> > There may be a need for a FIP explanation. I'll check with other guys to propose text.
>
> I mean add an entry type to binman for FIP. It supports CBFS already,
> for example.
>
> >
> >>
> >> What I would like, to package up the firmware for ANY board, after all
> >> the building is done in various projects:
> >>
> >> binman -b <board>
> >>
> > FIP deals with a number of firmwares like the SCP and MCP ones running on other micro-controllers of a board.
> > So in a sense it is an arm targeted tool.
> > If you want to package firmware for arm boards with binman you will have to deal with those firmwares as well as secure world and its trusted services as secure partitions that are being developed (including when virtualization is in operation in the secure world).
> > So in a word, trying to do this is a big undertaking, but you can try.
>
> Binman supports adding firmware for microcontrollers. For example, see here:
>
> https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/dts/flashmap-16mb-x86-rw.dtsi#L64
>
> That is a Chrome OS EC binary, one of three in the image.
>
> This is not ARM-specific. That image is actually for x86 Apollo Lake.
>
> > In a short term future (see Alibaba and Marvell announcements) you will have to deal with Arm v9 realms and associated firmware.
>
> Why me? Perhaps Linaro could take this on instead of working in a
> separate tool and domain? You guys could really pull things together
> and reduce the fragmentation, if you took it on.
>
> Honestly it is hard enough to even get Linaro people to write a test
> for code they have written. What gives?
That's completely inaccurate. We've added selftests for *every*
single feature we've sent for EFI up to now. Functionality wise the
past 2 years we've added
- EFI variables
- EFI secure boot
- capsule updates
- initrd loading
- efi TCG protocol
- ESRT tables
- RNG protocol
5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests
3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi()
1170fee695197 efi_selftest: fix variables test for GetNextVariableName()
ce62b0f8f45f1 test/py: Fix efidebug related tests
450596f2ac3fd test/py: efi_capsule: test for FIT image capsule
de489d82e3189 test: test the ESRT creation
57be8cdce35 test/py: efi_secboot: small rework for adding a new test
e1174c566a61c test/py: efi_secboot: add test for intermediate certificates
479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
and I am pretty sure I am forgetting more on functionality and selftests.
So basically we've either contributed new selftests for *everything*
we've or fixed the existing ones. The only thing that's not merged is
the TCG selftests which are on upstream review.
Regards
/Ilias
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-27 19:12 ` Ilias Apalodimas
@ 2021-10-27 19:52 ` Simon Glass
2021-10-29 10:20 ` Ilias Apalodimas
2021-10-29 17:07 ` François Ozog
0 siblings, 2 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-27 19:52 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: François Ozog, U-Boot Mailing List, Mark Kettenis,
Heinrich Schuchardt, Tom Rini, Sean Anderson, Marcel Ziswiler
Hi Ilias,
On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> On Wed, 27 Oct 2021 at 21:33, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi François,
> >
> > On Wed, 27 Oct 2021 at 09:38, François Ozog <francois.ozog@linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Wed, 27 Oct 2021 at 16:13, Simon Glass <sjg@chromium.org> wrote:
> > >>
> > >> Hi François,
> > >>
> > >> On Tue, 26 Oct 2021 at 09:57, François Ozog <francois.ozog@linaro.org> wrote:
> > >> >
> > >> >
> > >> >
> > >> > On Tue, 26 Oct 2021 at 17:27, Simon Glass <sjg@chromium.org> wrote:
> > >> >>
> > >> >> Hi François,
> > >> >>
> > >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog <francois.ozog@linaro.org> wrote:
> > >> >> >
> > >> >> > Hi Simon,
> > >> >> >
> > >> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg@chromium.org> wrote:
> > >> >> >>
> > >> >> >> At present some of the ideas and techniques behind devicetree in U-Boot
> > >> >> >> are assumed, implied or unsaid. Add some documentation to cover how
> > >> >> >> devicetree is build, how it can be modified and the rules about using
> > >> >> >> the various CONFIG_OF_... options.
> > >> >> >>
> > >>
> > >> [..]
> > >>
> > >> >> >> +Why not have two devicetrees?
> > >> >> >> +-----------------------------
> > >> >> >> +
> > >> >> >> +Setting aside the argument for restricting U-Boot from having its own nodes and
> > >> >> >> +properties, another idea proposed is to have two devicetrees, one for the
> > >> >> >> +U-Boot-specific bits (here called `special`) and one for everything else (here
> > >> >> >> +called `linux`).
> > >> >> >> +
> > >> >> >> +On the positive side, it might quieten the discussion alluded to in the section
> > >> >> >> +above. But there are many negatives to consider and many open questions to
> > >> >> >> +resolve.
> > >> >> >> +
> > >> >> >> +- **Bindings** - Presumably the special devicetree would have its own bindings.
> > >> >> >> + It would not be necessary to put a `u-boot,` prefix on anything. People coming
> > >> >> >> + across the devicetree source would wonder how it fits in with the Linux
> > >> >> >> + devicetree.
> > >> >> >> +
> > >> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This
> > >> >> >> + would need to be expanded to support two trees. Features which need to access
> > >> >> >> + both (such as a device driver which reads the special devicetree to get some
> > >> >> >> + configuration info) could become quite confusing to read and write.
> > >> >> >> +
> > >> >> >> +- **Merging** - Can the two devicetree be merged if a platform desires it? If
> > >> >> >> + so, how is this managed in tooling? Does it happen during the build, in which
> > >> >> >> + case they are not really separate at all. Or does U-Boot merge them at
> > >> >> >> + runtime, in which case this adds time and memory?
> > >> >> >> +
> > >> >> >> +- **Efficiency** - A second device tree adds more code and more code paths. It
> > >> >> >> + requires that both be made available to the code in U-Boot, e.g. via a
> > >> >> >> + separate pointer or argument or API. Overall the separation would certainly
> > >> >> >> + not speed up U-Boot, nor decrease its size.
> > >> >> >> +
> > >> >> >> +- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for
> > >> >> >> + U-Boot for a particular board. Would we use these same files for the special
> > >> >> >> + devicetree?
> > >> >> >> +
> > >> >> >> +- **Complexity** - Two devicetrees complicates the build system since it must
> > >> >> >> + build and package them both. Errors must be reported in such a way that it
> > >> >> >> + is obvious which one is failing.
> > >> >> >> +
> > >> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model
> > >> >> >> + are currently placed in the nodes they relate to. How would these tags
> > >> >> >> + reference a node that is in a separate devicetree? What extra validation would
> > >> >> >> + be needed?
> > >> >> >> +
> > >> >> >> +- **Storage** - How would the two devicetrees be stored in the image? At present
> > >> >> >> + we simply concatenate the U-Boot binary and the devicetree. We could add the
> > >> >> >> + special devicetree before the Linux one, so two are concatenated, but it is
> > >> >> >> + not pretty. We could use binman to support more complex arrangements, but only
> > >> >> >> + some boards use this at present, so it would be a big change.
> > >> >> >> +
> > >> >> >> +- **API** - How would another project provide two devicetree files to U-Boot at
> > >> >> >> + runtime? Presumably this would just be too painful. But if it doesn't, it
> > >> >> >> + would be unable to configure run-time features of U-Boot during the boot.
> > >> >> >> +
> > >> >> >> +- **Confusion** - No other project has two devicetrees. U-Boot would be in the
> > >> >> >> + unfortunate position of having to describe this fact to new users, along with
> > >> >> >> + the (arguably contrived) reason for the arrangement.
> > >> >> >> +
> > >> >> >
> > >> >> > False:
> > >> >> > 1) projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes.
> > >> >>
> > >> >> Can you provided a link and I can update this.
> > >> >
> > >> > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> > >> > Bindings:
> > >> > for FCONF: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_properties.html
> > >> > for FF-A: https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
> > >> > For chain-of-trust: https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.html
> > >> >
> > >> > For some code:
> > >> > https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fiptool/tbbr_config.c
> > >> > From there you can wander and see how dynamic config sections of the FIP can contain component specific DTs.
> > >> > U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
> > >>
> > >> OK I can mention that TF-A supports multiple devicetrees if you like,
> > >> but I'm not sure we are talking about the same thing.
> > >>
> > > If I take a possible scenario: OP-TEE to deal with 3 different device trees:
> > > - the one that will be passed to the OS and for which it may want to do some fixups
> > > - the one that it is using to run (it may have secure devices that are entirely not visible to any normal world OS)
> > > - the one that it gets from the FIP and contains runtime configuration parameters, accessed through FCONF library)
> > >
> > >>
> > >> U-Boot also supports multiple devicetrees in the build - e.g. SPL and
> > >> U-Boot proper. With binman you can create several copies of them for
> > >> use with A/B boot, for example. But only one is used as a control DTB
> > >> by a particular U-Boot phase at a time. Do you see what I mean?
> > >>
> > >> >>
> > >> >> > 2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system
> > >> >> > As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT.
> > >> >> > If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
> > >> >>
> > >> >> I have gone to great efforts to document things here, as they work in
> > >> >> U-Boot today. As you know, U-Boot supports separate control and active
> > >> >> devicetrees.
> > >> >
> > >> > I don't know what is an active device tree. Is it the device tree to be passed to OS?
> > >>
> > >> Yes that's right.
> > >>
> > >> >>
> > >> >> But if you are wanting to change to multiple control
> > >> >> trees within U-Boot, I'd say the answer is "no, thank you".
> > >> >
> > >> > I see only one control DT.
> > >>
> > >> OK good.
> > >>
> > >> > There is a possibility to store it securely in NT_FW_CONFIG section of a FIP. it also has associated signature plus hash mechanisms to attest authenticity of it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes).
> > >>
> > >> What does NT mean? I suppose FW means firmware.
> > >
> > > Non Trusted; it means normal world as opposed to secure world.
> > > It feels unfortunate to say non trusted while it is trusted but running outside secure world ;-)
> >
> > OK, good, so long as it doesn't mean Windows NT I am happy.
> >
> > >>
> > >>
> > >> It doesn't really matter where it is stored, so long as U-Boot can access it.
> > >>
> > >> > You can certain have a similar mechanism for binman.
> > >>
> > >> Note that binman is a packaging tool. Perhaps you should add FIP
> > >> support to it if FIP is going to be required too now?
> > >>
> > > There may be a need for a FIP explanation. I'll check with other guys to propose text.
> >
> > I mean add an entry type to binman for FIP. It supports CBFS already,
> > for example.
> >
> > >
> > >>
> > >> What I would like, to package up the firmware for ANY board, after all
> > >> the building is done in various projects:
> > >>
> > >> binman -b <board>
> > >>
> > > FIP deals with a number of firmwares like the SCP and MCP ones running on other micro-controllers of a board.
> > > So in a sense it is an arm targeted tool.
> > > If you want to package firmware for arm boards with binman you will have to deal with those firmwares as well as secure world and its trusted services as secure partitions that are being developed (including when virtualization is in operation in the secure world).
> > > So in a word, trying to do this is a big undertaking, but you can try.
> >
> > Binman supports adding firmware for microcontrollers. For example, see here:
> >
> > https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/dts/flashmap-16mb-x86-rw.dtsi#L64
> >
> > That is a Chrome OS EC binary, one of three in the image.
> >
> > This is not ARM-specific. That image is actually for x86 Apollo Lake.
> >
> > > In a short term future (see Alibaba and Marvell announcements) you will have to deal with Arm v9 realms and associated firmware.
> >
> > Why me? Perhaps Linaro could take this on instead of working in a
> > separate tool and domain? You guys could really pull things together
> > and reduce the fragmentation, if you took it on.
> >
> > Honestly it is hard enough to even get Linaro people to write a test
> > for code they have written. What gives?
>
> That's completely inaccurate. We've added selftests for *every*
> single feature we've sent for EFI up to now. Functionality wise the
> past 2 years we've added
> - EFI variables
> - EFI secure boot
> - capsule updates
> - initrd loading
> - efi TCG protocol
> - ESRT tables
> - RNG protocol
>
> 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests
> 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi()
> 1170fee695197 efi_selftest: fix variables test for GetNextVariableName()
> ce62b0f8f45f1 test/py: Fix efidebug related tests
> 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule
> de489d82e3189 test: test the ESRT creation
> 57be8cdce35 test/py: efi_secboot: small rework for adding a new test
> e1174c566a61c test/py: efi_secboot: add test for intermediate certificates
> 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
>
> and I am pretty sure I am forgetting more on functionality and selftests.
>
> So basically we've either contributed new selftests for *everything*
> we've or fixed the existing ones. The only thing that's not merged is
> the TCG selftests which are on upstream review.
Er, I didn't say or mean that no tests were written, just that there
is too much push-back on it. Heinrich put a huge amount of effort into
the tests and basically created a strong base for it. Congrats and
huge kudos to him. As to Linaro, no offence intended, and it is great
that all these tests have been added. Thank you for your efforts and
it is very helpful. But I think you miss my point. Or perhaps you
don't even agree with it? I sent an email about this on one patch just
a day or two ago.
As to the leadership side (my bigger point), Linaro is leading us all
down this fragmented path, with TF-A, FIP, more and more binaries and
larger firmware diagrams. Or do you disagree with that too?
I'm sorry if you find this a bit sharp. But someone needs to be
pointing these things out. I don't know who else is doing so. ARM
firmware has got noticeably more complicated and fragmented in the
last five years, hasn't it? What can Linaro do to address that? I am
very happy to help and provide part of the solution, but it needs a
shared vision.
It's not even just a Linaro/ARM problem. On the x86 side it is fast
becoming a living nightmare.
Perhaps the problem here is just the pandemic response and the
inability for people to get into a room and brainstorm / collaborate /
hack on ideas? I know you have made big efforts to engage, Ilias. We
have spoken many times and I'm sure f2f would be easier.
Regards,
Simon
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-27 19:52 ` Simon Glass
@ 2021-10-29 10:20 ` Ilias Apalodimas
2021-11-01 15:19 ` Tom Rini
2021-11-02 14:53 ` Simon Glass
2021-10-29 17:07 ` François Ozog
1 sibling, 2 replies; 144+ messages in thread
From: Ilias Apalodimas @ 2021-10-29 10:20 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, U-Boot Mailing List, Mark Kettenis,
Heinrich Schuchardt, Tom Rini, Sean Anderson, Marcel Ziswiler
Hi Simon,
[...]
> > >
> > > Why me? Perhaps Linaro could take this on instead of working in a
> > > separate tool and domain? You guys could really pull things together
> > > and reduce the fragmentation, if you took it on.
> > >
> > > Honestly it is hard enough to even get Linaro people to write a test
> > > for code they have written. What gives?
> >
> > That's completely inaccurate. We've added selftests for *every*
> > single feature we've sent for EFI up to now. Functionality wise the
> > past 2 years we've added
> > - EFI variables
> > - EFI secure boot
> > - capsule updates
> > - initrd loading
> > - efi TCG protocol
> > - ESRT tables
> > - RNG protocol
> >
> > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests
> > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi()
> > 1170fee695197 efi_selftest: fix variables test for GetNextVariableName()
> > ce62b0f8f45f1 test/py: Fix efidebug related tests
> > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule
> > de489d82e3189 test: test the ESRT creation
> > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test
> > e1174c566a61c test/py: efi_secboot: add test for intermediate certificates
> > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
> >
> > and I am pretty sure I am forgetting more on functionality and selftests.
> >
> > So basically we've either contributed new selftests for *everything*
> > we've or fixed the existing ones. The only thing that's not merged is
> > the TCG selftests which are on upstream review.
>
> Er, I didn't say or mean that no tests were written, just that there
> is too much push-back on it. Heinrich put a huge amount of effort into
There's no pushback at all, apart from the TPM one. (and for a very good
reason I've explained over and over again). In fact we add the sefltests
as part of our patchsets.
> the tests and basically created a strong base for it. Congrats and
> huge kudos to him. As to Linaro, no offence intended, and it is great
> that all these tests have been added. Thank you for your efforts and
> it is very helpful. But I think you miss my point. Or perhaps you
> don't even agree with it? I sent an email about this on one patch just
> a day or two ago.
I guess you mean [1]. I've lost count of how many times I responded to
this. Threads [2], [3] and [4] are just a few examples, so I just got
tired or replying the same thing over and over.
So bottom line, we are contributing selftests as always, we just don't agree
with the way *you* want this specific TPM test, trying to force us into sandbox.
So instead of respecting what we have (which btw is acceptable from u-boot's
perspective and cleans up a lot of the TPM crud along the way), you went ahead
making misleading statements on the selftests we contribute, in general. What's
even more annoying is that, as I showed you, we pretty much add a selftest
for *every* feature we add. Excellent ... that's certainly ... encouraging ... and
very productive.
>
> As to the leadership side (my bigger point), Linaro is leading us all
> down this fragmented path, with TF-A, FIP, more and more binaries and
> larger firmware diagrams. Or do you disagree with that too?
>
Of course I disagree. People decided not to use SPL for their own reasons.
I am certainly not qualified to answer why Arm choose to do that, but it seems
to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure
U-Boot is compatible and remains the de-facto choice for embedded boot
loaders playing nicely with all the new FSBLs come up with. If you
cosinder SPL and U-Boot the center of the known universe, we certainly view
things differently. FWIW it's *our* work mostly that made U-Boot SystemReady
compliant, which is something Arm pushes for [5].
> I'm sorry if you find this a bit sharp.
Which part? The first one wrt to selftests is not sharp. It's
manipulative and utterly unacceptable for me, not to mention entirely
fabricated.
The latter on bootloading fragmentation, I am always happy to discuss.
> But someone needs to be
> pointing these things out. I don't know who else is doing so. ARM
> firmware has got noticeably more complicated and fragmented in the
> last five years, hasn't it? What can Linaro do to address that? I am
> very happy to help and provide part of the solution, but it needs a
> shared vision.
There's a TF-A mailing list, we can certainly engage there and try to align
our ideas/designs.
>
> It's not even just a Linaro/ARM problem. On the x86 side it is fast
> becoming a living nightmare.
>
> Perhaps the problem here is just the pandemic response and the
> inability for people to get into a room and brainstorm / collaborate /
> hack on ideas? I know you have made big efforts to engage, Ilias. We
> have spoken many times and I'm sure f2f would be easier.
>
>
> It's not even just a Linaro/ARM problem. On the x86 side it is fast
> becoming a living nightmare.
>
> Perhaps the problem here is just the pandemic response and the
> inability for people to get into a room and brainstorm / collaborate /
> hack on ideas? I know you have made big efforts to engage, Ilias. We
> have spoken many times and I'm sure f2f would be easier.
Maybe, hopefully travelling will restart soon.
[1] https://lore.kernel.org/u-boot/CAPnjgZ2mmcUKz0v=ysSvf17c6ab++-hEpO4rc0OeeAEz7pFA2g@mail.gmail.com/
[2] https://lore.kernel.org/u-boot/YVdlvpThuqr8jksL@apalos.home/
[3] https://lore.kernel.org/u-boot/CAC_iWjLWxPyEwPpG7v=1U1sxLOD4LXF+Vm+cGTHom9Mpz9pAgw@mail.gmail.com/
[4] https://lore.kernel.org/u-boot/YVGGRqgVAiHvd1aR@apalos.home/
[5] https://www.arm.com/why-arm/architecture/systems/systemready-certification-program/ir?_ga=2.140829686.578781084.1635493248-857780164.1580291819
Regards
/Ilias
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-29 10:20 ` Ilias Apalodimas
@ 2021-11-01 15:19 ` Tom Rini
2021-11-02 14:53 ` Simon Glass
1 sibling, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-01 15:19 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Simon Glass, François Ozog, U-Boot Mailing List,
Mark Kettenis, Heinrich Schuchardt, Sean Anderson,
Marcel Ziswiler
[-- Attachment #1: Type: text/plain, Size: 4561 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-29 10:20 ` Ilias Apalodimas
2021-11-01 15:19 ` Tom Rini
@ 2021-11-02 14:53 ` Simon Glass
2021-11-02 15:38 ` Ilias Apalodimas
1 sibling, 1 reply; 144+ messages in thread
From: Simon Glass @ 2021-11-02 14:53 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: François Ozog, U-Boot Mailing List, Mark Kettenis,
Heinrich Schuchardt, Tom Rini, Sean Anderson, Marcel Ziswiler
Hi Ilias,
On Fri, 29 Oct 2021 at 04:20, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Simon,
>
> [...]
>
> > > >
> > > > Why me? Perhaps Linaro could take this on instead of working in a
> > > > separate tool and domain? You guys could really pull things together
> > > > and reduce the fragmentation, if you took it on.
> > > >
> > > > Honestly it is hard enough to even get Linaro people to write a test
> > > > for code they have written. What gives?
> > >
> > > That's completely inaccurate. We've added selftests for *every*
> > > single feature we've sent for EFI up to now. Functionality wise the
> > > past 2 years we've added
> > > - EFI variables
> > > - EFI secure boot
> > > - capsule updates
> > > - initrd loading
> > > - efi TCG protocol
> > > - ESRT tables
> > > - RNG protocol
> > >
> > > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests
> > > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi()
> > > 1170fee695197 efi_selftest: fix variables test for GetNextVariableName()
> > > ce62b0f8f45f1 test/py: Fix efidebug related tests
> > > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule
> > > de489d82e3189 test: test the ESRT creation
> > > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test
> > > e1174c566a61c test/py: efi_secboot: add test for intermediate certificates
> > > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
> > >
> > > and I am pretty sure I am forgetting more on functionality and selftests.
> > >
> > > So basically we've either contributed new selftests for *everything*
> > > we've or fixed the existing ones. The only thing that's not merged is
> > > the TCG selftests which are on upstream review.
> >
> > Er, I didn't say or mean that no tests were written, just that there
> > is too much push-back on it. Heinrich put a huge amount of effort into
>
> There's no pushback at all, apart from the TPM one. (and for a very good
> reason I've explained over and over again). In fact we add the sefltests
> as part of our patchsets.
>
> > the tests and basically created a strong base for it. Congrats and
> > huge kudos to him. As to Linaro, no offence intended, and it is great
> > that all these tests have been added. Thank you for your efforts and
> > it is very helpful. But I think you miss my point. Or perhaps you
> > don't even agree with it? I sent an email about this on one patch just
> > a day or two ago.
>
> I guess you mean [1]. I've lost count of how many times I responded to
> this. Threads [2], [3] and [4] are just a few examples, so I just got
> tired or replying the same thing over and over.
>
> So bottom line, we are contributing selftests as always, we just don't agree
> with the way *you* want this specific TPM test, trying to force us into sandbox.
> So instead of respecting what we have (which btw is acceptable from u-boot's
> perspective and cleans up a lot of the TPM crud along the way), you went ahead
> making misleading statements on the selftests we contribute, in general. What's
> even more annoying is that, as I showed you, we pretty much add a selftest
> for *every* feature we add. Excellent ... that's certainly ... encouraging ... and
> very productive.
>
> >
> > As to the leadership side (my bigger point), Linaro is leading us all
> > down this fragmented path, with TF-A, FIP, more and more binaries and
> > larger firmware diagrams. Or do you disagree with that too?
> >
>
> Of course I disagree. People decided not to use SPL for their own reasons.
> I am certainly not qualified to answer why Arm choose to do that, but it seems
> to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure
> U-Boot is compatible and remains the de-facto choice for embedded boot
> loaders playing nicely with all the new FSBLs come up with. If you
> cosinder SPL and U-Boot the center of the known universe, we certainly view
> things differently. FWIW it's *our* work mostly that made U-Boot SystemReady
> compliant, which is something Arm pushes for [5].
>
> > I'm sorry if you find this a bit sharp.
>
> Which part? The first one wrt to selftests is not sharp. It's
> manipulative and utterly unacceptable for me, not to mention entirely
> fabricated.
>
> The latter on bootloading fragmentation, I am always happy to discuss.
My comment was about the push-back I feel I have received when
requesting tests. It was a poor choice of words since it suggests this
is an ongoing problem when in fact many tests have been written. So I
would like to withdraw that and I am sorry for saying that and for
upsetting you. I certainly agree that Linaro has written lots of tests
and this is great. Thank you to you and Linaro for that. The business
of how the tests are written can be handled in other threads.
>
> > But someone needs to be
> > pointing these things out. I don't know who else is doing so. ARM
> > firmware has got noticeably more complicated and fragmented in the
> > last five years, hasn't it? What can Linaro do to address that? I am
> > very happy to help and provide part of the solution, but it needs a
> > shared vision.
>
> There's a TF-A mailing list, we can certainly engage there and try to align
> our ideas/designs.
>
> >
> > It's not even just a Linaro/ARM problem. On the x86 side it is fast
> > becoming a living nightmare.
> >
> > Perhaps the problem here is just the pandemic response and the
> > inability for people to get into a room and brainstorm / collaborate /
> > hack on ideas? I know you have made big efforts to engage, Ilias. We
> > have spoken many times and I'm sure f2f would be easier.
> >
>
>
>
> >
> > It's not even just a Linaro/ARM problem. On the x86 side it is fast
> > becoming a living nightmare.
> >
> > Perhaps the problem here is just the pandemic response and the
> > inability for people to get into a room and brainstorm / collaborate /
> > hack on ideas? I know you have made big efforts to engage, Ilias. We
> > have spoken many times and I'm sure f2f would be easier.
>
> Maybe, hopefully travelling will restart soon.
I think the whole issue in this thread comes down to a matter of alignment.
As you can tell, I am frustrated with where things are headed and hope
we can course-correct at some point.
Regards,
Simon
>
> [1] https://lore.kernel.org/u-boot/CAPnjgZ2mmcUKz0v=ysSvf17c6ab++-hEpO4rc0OeeAEz7pFA2g@mail.gmail.com/
> [2] https://lore.kernel.org/u-boot/YVdlvpThuqr8jksL@apalos.home/
> [3] https://lore.kernel.org/u-boot/CAC_iWjLWxPyEwPpG7v=1U1sxLOD4LXF+Vm+cGTHom9Mpz9pAgw@mail.gmail.com/
> [4] https://lore.kernel.org/u-boot/YVGGRqgVAiHvd1aR@apalos.home/
> [5] https://www.arm.com/why-arm/architecture/systems/systemready-certification-program/ir?_ga=2.140829686.578781084.1635493248-857780164.1580291819
>
> Regards
> /Ilias
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-11-02 14:53 ` Simon Glass
@ 2021-11-02 15:38 ` Ilias Apalodimas
2021-11-03 3:29 ` Simon Glass
0 siblings, 1 reply; 144+ messages in thread
From: Ilias Apalodimas @ 2021-11-02 15:38 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, U-Boot Mailing List, Mark Kettenis,
Heinrich Schuchardt, Tom Rini, Sean Anderson, Marcel Ziswiler
Hi Simon,
[...]
> >
> > > > >
> > > > > Why me? Perhaps Linaro could take this on instead of working in a
> > > > > separate tool and domain? You guys could really pull things together
> > > > > and reduce the fragmentation, if you took it on.
> > > > >
> > > > > Honestly it is hard enough to even get Linaro people to write a test
> > > > > for code they have written. What gives?
> > > >
> > > > That's completely inaccurate. We've added selftests for *every*
> > > > single feature we've sent for EFI up to now. Functionality wise the
> > > > past 2 years we've added
> > > > - EFI variables
> > > > - EFI secure boot
> > > > - capsule updates
> > > > - initrd loading
> > > > - efi TCG protocol
> > > > - ESRT tables
> > > > - RNG protocol
> > > >
> > > > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests
> > > > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi()
> > > > 1170fee695197 efi_selftest: fix variables test for GetNextVariableName()
> > > > ce62b0f8f45f1 test/py: Fix efidebug related tests
> > > > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule
> > > > de489d82e3189 test: test the ESRT creation
> > > > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test
> > > > e1174c566a61c test/py: efi_secboot: add test for intermediate certificates
> > > > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
> > > >
> > > > and I am pretty sure I am forgetting more on functionality and selftests.
> > > >
> > > > So basically we've either contributed new selftests for *everything*
> > > > we've or fixed the existing ones. The only thing that's not merged is
> > > > the TCG selftests which are on upstream review.
> > >
> > > Er, I didn't say or mean that no tests were written, just that there
> > > is too much push-back on it. Heinrich put a huge amount of effort into
> >
> > There's no pushback at all, apart from the TPM one. (and for a very good
> > reason I've explained over and over again). In fact we add the sefltests
> > as part of our patchsets.
> >
> > > the tests and basically created a strong base for it. Congrats and
> > > huge kudos to him. As to Linaro, no offence intended, and it is great
> > > that all these tests have been added. Thank you for your efforts and
> > > it is very helpful. But I think you miss my point. Or perhaps you
> > > don't even agree with it? I sent an email about this on one patch just
> > > a day or two ago.
> >
> > I guess you mean [1]. I've lost count of how many times I responded to
> > this. Threads [2], [3] and [4] are just a few examples, so I just got
> > tired or replying the same thing over and over.
> >
> > So bottom line, we are contributing selftests as always, we just don't agree
> > with the way *you* want this specific TPM test, trying to force us into sandbox.
> > So instead of respecting what we have (which btw is acceptable from u-boot's
> > perspective and cleans up a lot of the TPM crud along the way), you went ahead
> > making misleading statements on the selftests we contribute, in general. What's
> > even more annoying is that, as I showed you, we pretty much add a selftest
> > for *every* feature we add. Excellent ... that's certainly ... encouraging ... and
> > very productive.
> >
> > >
> > > As to the leadership side (my bigger point), Linaro is leading us all
> > > down this fragmented path, with TF-A, FIP, more and more binaries and
> > > larger firmware diagrams. Or do you disagree with that too?
> > >
> >
> > Of course I disagree. People decided not to use SPL for their own reasons.
> > I am certainly not qualified to answer why Arm choose to do that, but it seems
> > to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure
> > U-Boot is compatible and remains the de-facto choice for embedded boot
> > loaders playing nicely with all the new FSBLs come up with. If you
> > cosinder SPL and U-Boot the center of the known universe, we certainly view
> > things differently. FWIW it's *our* work mostly that made U-Boot SystemReady
> > compliant, which is something Arm pushes for [5].
> >
> > > I'm sorry if you find this a bit sharp.
> >
> > Which part? The first one wrt to selftests is not sharp. It's
> > manipulative and utterly unacceptable for me, not to mention entirely
> > fabricated.
> >
> > The latter on bootloading fragmentation, I am always happy to discuss.
>
> My comment was about the push-back I feel I have received when
> requesting tests. It was a poor choice of words since it suggests this
> is an ongoing problem when in fact many tests have been written. So I
> would like to withdraw that and I am sorry for saying that and for
> upsetting you. I certainly agree that Linaro has written lots of tests
> and this is great. Thank you to you and Linaro for that. The business
> of how the tests are written can be handled in other threads.
Thanks, I appreciate this. Let's just forget this ever happened. The discussions are
usually constructive and I am happy with the general progress, despite
of the differences of opinion.
>
> >
> > > But someone needs to be
> > > pointing these things out. I don't know who else is doing so. ARM
> > > firmware has got noticeably more complicated and fragmented in the
> > > last five years, hasn't it? What can Linaro do to address that? I am
> > > very happy to help and provide part of the solution, but it needs a
> > > shared vision.
> >
> > There's a TF-A mailing list, we can certainly engage there and try to align
> > our ideas/designs.
> >
> > >
> > > It's not even just a Linaro/ARM problem. On the x86 side it is fast
> > > becoming a living nightmare.
> > >
> > > Perhaps the problem here is just the pandemic response and the
> > > inability for people to get into a room and brainstorm / collaborate /
> > > hack on ideas? I know you have made big efforts to engage, Ilias. We
> > > have spoken many times and I'm sure f2f would be easier.
> > >
> >
> >
> >
> > >
> > > It's not even just a Linaro/ARM problem. On the x86 side it is fast
> > > becoming a living nightmare.
> > >
> > > Perhaps the problem here is just the pandemic response and the
> > > inability for people to get into a room and brainstorm / collaborate /
> > > hack on ideas? I know you have made big efforts to engage, Ilias. We
> > > have spoken many times and I'm sure f2f would be easier.
> >
> > Maybe, hopefully travelling will restart soon.
>
> I think the whole issue in this thread comes down to a matter of alignment.
>
> As you can tell, I am frustrated with where things are headed and hope
> we can course-correct at some point.
This is a matter of perspective to me. I've accepted the fact that
firmware gets more complex. Whether I personally like it or not is a
different story. One thing that's clear to me though is that we either
have to adapt, or slowly become irrelevant.
Thanks
/Ilias
>
> Regards,
> Simon
>
>
> >
> > [1] https://lore.kernel.org/u-boot/CAPnjgZ2mmcUKz0v=ysSvf17c6ab++-hEpO4rc0OeeAEz7pFA2g@mail.gmail.com/
> > [2] https://lore.kernel.org/u-boot/YVdlvpThuqr8jksL@apalos.home/
> > [3] https://lore.kernel.org/u-boot/CAC_iWjLWxPyEwPpG7v=1U1sxLOD4LXF+Vm+cGTHom9Mpz9pAgw@mail.gmail.com/
> > [4] https://lore.kernel.org/u-boot/YVGGRqgVAiHvd1aR@apalos.home/
> > [5] https://www.arm.com/why-arm/architecture/systems/systemready-certification-program/ir?_ga=2.140829686.578781084.1635493248-857780164.1580291819
> >
> > Regards
> > /Ilias
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-11-02 15:38 ` Ilias Apalodimas
@ 2021-11-03 3:29 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-03 3:29 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: François Ozog, U-Boot Mailing List, Mark Kettenis,
Heinrich Schuchardt, Tom Rini, Sean Anderson, Marcel Ziswiler
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-27 19:52 ` Simon Glass
2021-10-29 10:20 ` Ilias Apalodimas
@ 2021-10-29 17:07 ` François Ozog
2021-11-02 14:53 ` Simon Glass
1 sibling, 1 reply; 144+ messages in thread
From: François Ozog @ 2021-10-29 17:07 UTC (permalink / raw)
To: Simon Glass
Cc: Ilias Apalodimas, U-Boot Mailing List, Mark Kettenis,
Heinrich Schuchardt, Tom Rini, Sean Anderson, Marcel Ziswiler
Hi Simon
(I keep getting messages about delivery problems so I don't know what
went through or not)
On Wed, 27 Oct 2021 at 21:52, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Ilias,
>
> On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > On Wed, 27 Oct 2021 at 21:33, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi François,
> > >
> > > On Wed, 27 Oct 2021 at 09:38, François Ozog <francois.ozog@linaro.org> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Wed, 27 Oct 2021 at 16:13, Simon Glass <sjg@chromium.org> wrote:
> > > >>
> > > >> Hi François,
> > > >>
> > > >> On Tue, 26 Oct 2021 at 09:57, François Ozog <francois.ozog@linaro.org> wrote:
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Tue, 26 Oct 2021 at 17:27, Simon Glass <sjg@chromium.org> wrote:
> > > >> >>
> > > >> >> Hi François,
> > > >> >>
> > > >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog <francois.ozog@linaro.org> wrote:
> > > >> >> >
> > > >> >> > Hi Simon,
> > > >> >> >
> > > >> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg@chromium.org> wrote:
> > > >> >> >>
> > > >> >> >> At present some of the ideas and techniques behind devicetree in U-Boot
> > > >> >> >> are assumed, implied or unsaid. Add some documentation to cover how
> > > >> >> >> devicetree is build, how it can be modified and the rules about using
> > > >> >> >> the various CONFIG_OF_... options.
> > > >> >> >>
> > > >>
> > > >> [..]
> > > >>
> > > >> >> >> +Why not have two devicetrees?
> > > >> >> >> +-----------------------------
> > > >> >> >> +
> > > >> >> >> +Setting aside the argument for restricting U-Boot from having its own nodes and
> > > >> >> >> +properties, another idea proposed is to have two devicetrees, one for the
> > > >> >> >> +U-Boot-specific bits (here called `special`) and one for everything else (here
> > > >> >> >> +called `linux`).
> > > >> >> >> +
> > > >> >> >> +On the positive side, it might quieten the discussion alluded to in the section
> > > >> >> >> +above. But there are many negatives to consider and many open questions to
> > > >> >> >> +resolve.
> > > >> >> >> +
> > > >> >> >> +- **Bindings** - Presumably the special devicetree would have its own bindings.
> > > >> >> >> + It would not be necessary to put a `u-boot,` prefix on anything. People coming
> > > >> >> >> + across the devicetree source would wonder how it fits in with the Linux
> > > >> >> >> + devicetree.
> > > >> >> >> +
> > > >> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This
> > > >> >> >> + would need to be expanded to support two trees. Features which need to access
> > > >> >> >> + both (such as a device driver which reads the special devicetree to get some
> > > >> >> >> + configuration info) could become quite confusing to read and write.
> > > >> >> >> +
> > > >> >> >> +- **Merging** - Can the two devicetree be merged if a platform desires it? If
> > > >> >> >> + so, how is this managed in tooling? Does it happen during the build, in which
> > > >> >> >> + case they are not really separate at all. Or does U-Boot merge them at
> > > >> >> >> + runtime, in which case this adds time and memory?
> > > >> >> >> +
> > > >> >> >> +- **Efficiency** - A second device tree adds more code and more code paths. It
> > > >> >> >> + requires that both be made available to the code in U-Boot, e.g. via a
> > > >> >> >> + separate pointer or argument or API. Overall the separation would certainly
> > > >> >> >> + not speed up U-Boot, nor decrease its size.
> > > >> >> >> +
> > > >> >> >> +- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for
> > > >> >> >> + U-Boot for a particular board. Would we use these same files for the special
> > > >> >> >> + devicetree?
> > > >> >> >> +
> > > >> >> >> +- **Complexity** - Two devicetrees complicates the build system since it must
> > > >> >> >> + build and package them both. Errors must be reported in such a way that it
> > > >> >> >> + is obvious which one is failing.
> > > >> >> >> +
> > > >> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model
> > > >> >> >> + are currently placed in the nodes they relate to. How would these tags
> > > >> >> >> + reference a node that is in a separate devicetree? What extra validation would
> > > >> >> >> + be needed?
> > > >> >> >> +
> > > >> >> >> +- **Storage** - How would the two devicetrees be stored in the image? At present
> > > >> >> >> + we simply concatenate the U-Boot binary and the devicetree. We could add the
> > > >> >> >> + special devicetree before the Linux one, so two are concatenated, but it is
> > > >> >> >> + not pretty. We could use binman to support more complex arrangements, but only
> > > >> >> >> + some boards use this at present, so it would be a big change.
> > > >> >> >> +
> > > >> >> >> +- **API** - How would another project provide two devicetree files to U-Boot at
> > > >> >> >> + runtime? Presumably this would just be too painful. But if it doesn't, it
> > > >> >> >> + would be unable to configure run-time features of U-Boot during the boot.
> > > >> >> >> +
> > > >> >> >> +- **Confusion** - No other project has two devicetrees. U-Boot would be in the
> > > >> >> >> + unfortunate position of having to describe this fact to new users, along with
> > > >> >> >> + the (arguably contrived) reason for the arrangement.
> > > >> >> >> +
> > > >> >> >
> > > >> >> > False:
> > > >> >> > 1) projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes.
> > > >> >>
> > > >> >> Can you provided a link and I can update this.
> > > >> >
> > > >> > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> > > >> > Bindings:
> > > >> > for FCONF: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_properties.html
> > > >> > for FF-A: https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
> > > >> > For chain-of-trust: https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.html
> > > >> >
> > > >> > For some code:
> > > >> > https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fiptool/tbbr_config.c
> > > >> > From there you can wander and see how dynamic config sections of the FIP can contain component specific DTs.
> > > >> > U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
> > > >>
> > > >> OK I can mention that TF-A supports multiple devicetrees if you like,
> > > >> but I'm not sure we are talking about the same thing.
> > > >>
> > > > If I take a possible scenario: OP-TEE to deal with 3 different device trees:
> > > > - the one that will be passed to the OS and for which it may want to do some fixups
> > > > - the one that it is using to run (it may have secure devices that are entirely not visible to any normal world OS)
> > > > - the one that it gets from the FIP and contains runtime configuration parameters, accessed through FCONF library)
> > > >
> > > >>
> > > >> U-Boot also supports multiple devicetrees in the build - e.g. SPL and
> > > >> U-Boot proper. With binman you can create several copies of them for
> > > >> use with A/B boot, for example. But only one is used as a control DTB
> > > >> by a particular U-Boot phase at a time. Do you see what I mean?
> > > >>
> > > >> >>
> > > >> >> > 2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system
> > > >> >> > As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT.
> > > >> >> > If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
> > > >> >>
> > > >> >> I have gone to great efforts to document things here, as they work in
> > > >> >> U-Boot today. As you know, U-Boot supports separate control and active
> > > >> >> devicetrees.
> > > >> >
> > > >> > I don't know what is an active device tree. Is it the device tree to be passed to OS?
> > > >>
> > > >> Yes that's right.
> > > >>
> > > >> >>
> > > >> >> But if you are wanting to change to multiple control
> > > >> >> trees within U-Boot, I'd say the answer is "no, thank you".
> > > >> >
> > > >> > I see only one control DT.
> > > >>
> > > >> OK good.
> > > >>
> > > >> > There is a possibility to store it securely in NT_FW_CONFIG section of a FIP. it also has associated signature plus hash mechanisms to attest authenticity of it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes).
> > > >>
> > > >> What does NT mean? I suppose FW means firmware.
> > > >
> > > > Non Trusted; it means normal world as opposed to secure world.
> > > > It feels unfortunate to say non trusted while it is trusted but running outside secure world ;-)
> > >
> > > OK, good, so long as it doesn't mean Windows NT I am happy.
> > >
> > > >>
> > > >>
> > > >> It doesn't really matter where it is stored, so long as U-Boot can access it.
> > > >>
> > > >> > You can certain have a similar mechanism for binman.
> > > >>
> > > >> Note that binman is a packaging tool. Perhaps you should add FIP
> > > >> support to it if FIP is going to be required too now?
> > > >>
> > > > There may be a need for a FIP explanation. I'll check with other guys to propose text.
> > >
> > > I mean add an entry type to binman for FIP. It supports CBFS already,
> > > for example.
> > >
> > > >
> > > >>
> > > >> What I would like, to package up the firmware for ANY board, after all
> > > >> the building is done in various projects:
> > > >>
> > > >> binman -b <board>
> > > >>
> > > > FIP deals with a number of firmwares like the SCP and MCP ones running on other micro-controllers of a board.
> > > > So in a sense it is an arm targeted tool.
> > > > If you want to package firmware for arm boards with binman you will have to deal with those firmwares as well as secure world and its trusted services as secure partitions that are being developed (including when virtualization is in operation in the secure world).
> > > > So in a word, trying to do this is a big undertaking, but you can try.
> > >
> > > Binman supports adding firmware for microcontrollers. For example, see here:
> > >
> > > https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/dts/flashmap-16mb-x86-rw.dtsi#L64
> > >
> > > That is a Chrome OS EC binary, one of three in the image.
> > >
> > > This is not ARM-specific. That image is actually for x86 Apollo Lake.
> > >
> > > > In a short term future (see Alibaba and Marvell announcements) you will have to deal with Arm v9 realms and associated firmware.
> > >
> > > Why me? Perhaps Linaro could take this on instead of working in a
> > > separate tool and domain? You guys could really pull things together
> > > and reduce the fragmentation, if you took it on.
> > >
> > > Honestly it is hard enough to even get Linaro people to write a test
> > > for code they have written. What gives?
> >
> > That's completely inaccurate. We've added selftests for *every*
> > single feature we've sent for EFI up to now. Functionality wise the
> > past 2 years we've added
> > - EFI variables
> > - EFI secure boot
> > - capsule updates
> > - initrd loading
> > - efi TCG protocol
> > - ESRT tables
> > - RNG protocol
> >
> > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests
> > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi()
> > 1170fee695197 efi_selftest: fix variables test for GetNextVariableName()
> > ce62b0f8f45f1 test/py: Fix efidebug related tests
> > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule
> > de489d82e3189 test: test the ESRT creation
> > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test
> > e1174c566a61c test/py: efi_secboot: add test for intermediate certificates
> > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
> >
> > and I am pretty sure I am forgetting more on functionality and selftests.
> >
> > So basically we've either contributed new selftests for *everything*
> > we've or fixed the existing ones. The only thing that's not merged is
> > the TCG selftests which are on upstream review.
>
> Er, I didn't say or mean that no tests were written, just that there
> is too much push-back on it. Heinrich put a huge amount of effort into
> the tests and basically created a strong base for it. Congrats and
> huge kudos to him. As to Linaro, no offence intended, and it is great
> that all these tests have been added. Thank you for your efforts and
> it is very helpful. But I think you miss my point. Or perhaps you
> don't even agree with it? I sent an email about this on one patch just
> a day or two ago.
>
> As to the leadership side (my bigger point), Linaro is leading us all
> down this fragmented path, with TF-A, FIP, more and more binaries and
> larger firmware diagrams. Or do you disagree with that too?
You seem to picture the role of the firmware to *only* to boot an operating
system. I would be surprised to teach you that secure world is a world
of its own
that need to be orchestrated and hosts business related applications that stay
available after U-Boot has disappeared from memory
(OK with UEFI runtime services it stills occupies some space but
it should be mostly inactive as Linux own devices - let's not comment
on this particular aspect).
As U-Boot has no code for that world, creating another code base would
actually create fragmentation.
The mindset I sense from your comments reminds me when relational databases
reached the market. People wanted to fit their business as
"relational", killing other
flavors of databases. It took at least a decade to get back to reason
and think that
more than one technology is needed with columnar databases,
unstructured databases,
KV databases...
U-Boot is a "jewel" for what it does. Let's not try to expand it in areas where
it is not meant to be and create fragmentation.
>
> I'm sorry if you find this a bit sharp. But someone needs to be
> pointing these things out. I don't know who else is doing so. ARM
> firmware has got noticeably more complicated and fragmented in the
> last five years, hasn't it? What can Linaro do to address that?
Linaro very creation was to avoid fragmentation in the arm ecosystem and I
think we can be proud of what has been accomplished from Linus Torvalds
comment on the state of kernel for arm.
We are on a journey to do the same for the firmware.
The first part was on the secure world firmware (that, again, do a lot of stuff
for the secure world and happen to also load U-Boot).
The second part is on the contract between U-Boot and the OS, hence our
contributions in U-Boot.
I am
> very happy to help and provide part of the solution, but it needs a
> shared vision.
This vision is entirely explained in Arm Cassini project with more firmware
related details in SystemReady and further more details for embedded world
in EBBR.
You asked me what was the problem we are trying to solve:
<session from FOSDEM 2021>
"“A BSP is a badly-patched fork of an ancient U-Boot, a badly-patched
fork of an ancient Linux, and a badly-patched fork of an ancient
Yocto”
“… that, plus often a prehistoric compiler”
</session from FOSDEM 2021>
Adding features in U-Boot is only part of the solution: we need to
have a process
to keep boards bootable over time and that simplifies the firmware supply chain.
I understand you don't like the choices, but that is an ecosystem
choice, not my choice, not Linaro choice, and hopefully you will join
us in making it happen.
>
> It's not even just a Linaro/ARM problem. On the x86 side it is fast
> becoming a living nightmare.
>
> Perhaps the problem here is just the pandemic response and the
> inability for people to get into a room and brainstorm / collaborate /
> hack on ideas?
I could not agree more. Mail exchanges tend to self inflate...
I remember a BoF in a Connect with 20 people around the table talking
about firmware update
and finding a way to make anti-bricking standard across boards (see
yet another effort of defragmentation:-)
People started the session with "impossible" in mind, and we came out
with a plan.
Now we are close to have it. If we could be on the drawing board, I am
sure you would immediately
understand and make a better version of our authentication scheme for
those updates..
..and pull the relevant patchset ;-)
(sorry I could not resist pulling your leg at the end)
I know you have made big efforts to engage, Ilias. We
> have spoken many times and I'm sure f2f would be easier.
>
> Regards,
> Simon
--
François-Frédéric Ozog | Director Business Development
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-29 17:07 ` François Ozog
@ 2021-11-02 14:53 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-02 14:53 UTC (permalink / raw)
To: François Ozog
Cc: Ilias Apalodimas, U-Boot Mailing List, Mark Kettenis,
Heinrich Schuchardt, Tom Rini, Sean Anderson, Marcel Ziswiler
Hi François,
On Fri, 29 Oct 2021 at 11:07, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon
>
> (I keep getting messages about delivery problems so I don't know what
> went through or not)
>
>
I got this one, anyway.
> On Wed, 27 Oct 2021 at 21:52, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Ilias,
> >
> > On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas
> > <ilias.apalodimas@linaro.org> wrote:
> > >
> > > On Wed, 27 Oct 2021 at 21:33, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi François,
> > > >
> > > > On Wed, 27 Oct 2021 at 09:38, François Ozog <francois.ozog@linaro.org> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Wed, 27 Oct 2021 at 16:13, Simon Glass <sjg@chromium.org> wrote:
> > > > >>
> > > > >> Hi François,
> > > > >>
> > > > >> On Tue, 26 Oct 2021 at 09:57, François Ozog <francois.ozog@linaro.org> wrote:
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On Tue, 26 Oct 2021 at 17:27, Simon Glass <sjg@chromium.org> wrote:
> > > > >> >>
> > > > >> >> Hi François,
> > > > >> >>
> > > > >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog <francois.ozog@linaro.org> wrote:
> > > > >> >> >
> > > > >> >> > Hi Simon,
> > > > >> >> >
> > > > >> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg@chromium.org> wrote:
> > > > >> >> >>
> > > > >> >> >> At present some of the ideas and techniques behind devicetree in U-Boot
> > > > >> >> >> are assumed, implied or unsaid. Add some documentation to cover how
> > > > >> >> >> devicetree is build, how it can be modified and the rules about using
> > > > >> >> >> the various CONFIG_OF_... options.
> > > > >> >> >>
> > > > >>
> > > > >> [..]
> > > > >>
> > > > >> >> >> +Why not have two devicetrees?
> > > > >> >> >> +-----------------------------
> > > > >> >> >> +
> > > > >> >> >> +Setting aside the argument for restricting U-Boot from having its own nodes and
> > > > >> >> >> +properties, another idea proposed is to have two devicetrees, one for the
> > > > >> >> >> +U-Boot-specific bits (here called `special`) and one for everything else (here
> > > > >> >> >> +called `linux`).
> > > > >> >> >> +
> > > > >> >> >> +On the positive side, it might quieten the discussion alluded to in the section
> > > > >> >> >> +above. But there are many negatives to consider and many open questions to
> > > > >> >> >> +resolve.
> > > > >> >> >> +
> > > > >> >> >> +- **Bindings** - Presumably the special devicetree would have its own bindings.
> > > > >> >> >> + It would not be necessary to put a `u-boot,` prefix on anything. People coming
> > > > >> >> >> + across the devicetree source would wonder how it fits in with the Linux
> > > > >> >> >> + devicetree.
> > > > >> >> >> +
> > > > >> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the devicetree. This
> > > > >> >> >> + would need to be expanded to support two trees. Features which need to access
> > > > >> >> >> + both (such as a device driver which reads the special devicetree to get some
> > > > >> >> >> + configuration info) could become quite confusing to read and write.
> > > > >> >> >> +
> > > > >> >> >> +- **Merging** - Can the two devicetree be merged if a platform desires it? If
> > > > >> >> >> + so, how is this managed in tooling? Does it happen during the build, in which
> > > > >> >> >> + case they are not really separate at all. Or does U-Boot merge them at
> > > > >> >> >> + runtime, in which case this adds time and memory?
> > > > >> >> >> +
> > > > >> >> >> +- **Efficiency** - A second device tree adds more code and more code paths. It
> > > > >> >> >> + requires that both be made available to the code in U-Boot, e.g. via a
> > > > >> >> >> + separate pointer or argument or API. Overall the separation would certainly
> > > > >> >> >> + not speed up U-Boot, nor decrease its size.
> > > > >> >> >> +
> > > > >> >> >> +- **Source code** - At present `u-boot.dtsi` files provide the pieces needed for
> > > > >> >> >> + U-Boot for a particular board. Would we use these same files for the special
> > > > >> >> >> + devicetree?
> > > > >> >> >> +
> > > > >> >> >> +- **Complexity** - Two devicetrees complicates the build system since it must
> > > > >> >> >> + build and package them both. Errors must be reported in such a way that it
> > > > >> >> >> + is obvious which one is failing.
> > > > >> >> >> +
> > > > >> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver model
> > > > >> >> >> + are currently placed in the nodes they relate to. How would these tags
> > > > >> >> >> + reference a node that is in a separate devicetree? What extra validation would
> > > > >> >> >> + be needed?
> > > > >> >> >> +
> > > > >> >> >> +- **Storage** - How would the two devicetrees be stored in the image? At present
> > > > >> >> >> + we simply concatenate the U-Boot binary and the devicetree. We could add the
> > > > >> >> >> + special devicetree before the Linux one, so two are concatenated, but it is
> > > > >> >> >> + not pretty. We could use binman to support more complex arrangements, but only
> > > > >> >> >> + some boards use this at present, so it would be a big change.
> > > > >> >> >> +
> > > > >> >> >> +- **API** - How would another project provide two devicetree files to U-Boot at
> > > > >> >> >> + runtime? Presumably this would just be too painful. But if it doesn't, it
> > > > >> >> >> + would be unable to configure run-time features of U-Boot during the boot.
> > > > >> >> >> +
> > > > >> >> >> +- **Confusion** - No other project has two devicetrees. U-Boot would be in the
> > > > >> >> >> + unfortunate position of having to describe this fact to new users, along with
> > > > >> >> >> + the (arguably contrived) reason for the arrangement.
> > > > >> >> >> +
> > > > >> >> >
> > > > >> >> > False:
> > > > >> >> > 1) projects in trustedfirmware.org are built to have multiple FDT objects, some for "dynamic" configuration purposes.
> > > > >> >>
> > > > >> >> Can you provided a link and I can update this.
> > > > >> >
> > > > >> > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> > > > >> > Bindings:
> > > > >> > for FCONF: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_properties.html
> > > > >> > for FF-A: https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
> > > > >> > For chain-of-trust: https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.html
> > > > >> >
> > > > >> > For some code:
> > > > >> > https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fiptool/tbbr_config.c
> > > > >> > From there you can wander and see how dynamic config sections of the FIP can contain component specific DTs.
> > > > >> > U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
> > > > >>
> > > > >> OK I can mention that TF-A supports multiple devicetrees if you like,
> > > > >> but I'm not sure we are talking about the same thing.
> > > > >>
> > > > > If I take a possible scenario: OP-TEE to deal with 3 different device trees:
> > > > > - the one that will be passed to the OS and for which it may want to do some fixups
> > > > > - the one that it is using to run (it may have secure devices that are entirely not visible to any normal world OS)
> > > > > - the one that it gets from the FIP and contains runtime configuration parameters, accessed through FCONF library)
> > > > >
> > > > >>
> > > > >> U-Boot also supports multiple devicetrees in the build - e.g. SPL and
> > > > >> U-Boot proper. With binman you can create several copies of them for
> > > > >> use with A/B boot, for example. But only one is used as a control DTB
> > > > >> by a particular U-Boot phase at a time. Do you see what I mean?
> > > > >>
> > > > >> >>
> > > > >> >> > 2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in addition to operating system
> > > > >> >> > As Ilias said, this is not about documentation about the current use of DT in U-Boot, but justification of your views on DT.
> > > > >> >> > If taken by the letter, I feel (may be wrong though) that your views prevent establish the DT lifecycle and usage as per the desire of vendors, partners and customers that supports Arm SystemReady standards.
> > > > >> >>
> > > > >> >> I have gone to great efforts to document things here, as they work in
> > > > >> >> U-Boot today. As you know, U-Boot supports separate control and active
> > > > >> >> devicetrees.
> > > > >> >
> > > > >> > I don't know what is an active device tree. Is it the device tree to be passed to OS?
> > > > >>
> > > > >> Yes that's right.
> > > > >>
> > > > >> >>
> > > > >> >> But if you are wanting to change to multiple control
> > > > >> >> trees within U-Boot, I'd say the answer is "no, thank you".
> > > > >> >
> > > > >> > I see only one control DT.
> > > > >>
> > > > >> OK good.
> > > > >>
> > > > >> > There is a possibility to store it securely in NT_FW_CONFIG section of a FIP. it also has associated signature plus hash mechanisms to attest authenticity of it (do not need signature in DT to allow verification: this is the associated content certificate section that contains the valid hashes).
> > > > >>
> > > > >> What does NT mean? I suppose FW means firmware.
> > > > >
> > > > > Non Trusted; it means normal world as opposed to secure world.
> > > > > It feels unfortunate to say non trusted while it is trusted but running outside secure world ;-)
> > > >
> > > > OK, good, so long as it doesn't mean Windows NT I am happy.
> > > >
> > > > >>
> > > > >>
> > > > >> It doesn't really matter where it is stored, so long as U-Boot can access it.
> > > > >>
> > > > >> > You can certain have a similar mechanism for binman.
> > > > >>
> > > > >> Note that binman is a packaging tool. Perhaps you should add FIP
> > > > >> support to it if FIP is going to be required too now?
> > > > >>
> > > > > There may be a need for a FIP explanation. I'll check with other guys to propose text.
> > > >
> > > > I mean add an entry type to binman for FIP. It supports CBFS already,
> > > > for example.
> > > >
> > > > >
> > > > >>
> > > > >> What I would like, to package up the firmware for ANY board, after all
> > > > >> the building is done in various projects:
> > > > >>
> > > > >> binman -b <board>
> > > > >>
> > > > > FIP deals with a number of firmwares like the SCP and MCP ones running on other micro-controllers of a board.
> > > > > So in a sense it is an arm targeted tool.
> > > > > If you want to package firmware for arm boards with binman you will have to deal with those firmwares as well as secure world and its trusted services as secure partitions that are being developed (including when virtualization is in operation in the secure world).
> > > > > So in a word, trying to do this is a big undertaking, but you can try.
> > > >
> > > > Binman supports adding firmware for microcontrollers. For example, see here:
> > > >
> > > > https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/dts/flashmap-16mb-x86-rw.dtsi#L64
> > > >
> > > > That is a Chrome OS EC binary, one of three in the image.
> > > >
> > > > This is not ARM-specific. That image is actually for x86 Apollo Lake.
> > > >
> > > > > In a short term future (see Alibaba and Marvell announcements) you will have to deal with Arm v9 realms and associated firmware.
> > > >
> > > > Why me? Perhaps Linaro could take this on instead of working in a
> > > > separate tool and domain? You guys could really pull things together
> > > > and reduce the fragmentation, if you took it on.
> > > >
> > > > Honestly it is hard enough to even get Linaro people to write a test
> > > > for code they have written. What gives?
> > >
> > > That's completely inaccurate. We've added selftests for *every*
> > > single feature we've sent for EFI up to now. Functionality wise the
> > > past 2 years we've added
> > > - EFI variables
> > > - EFI secure boot
> > > - capsule updates
> > > - initrd loading
> > > - efi TCG protocol
> > > - ESRT tables
> > > - RNG protocol
> > >
> > > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests
> > > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi()
> > > 1170fee695197 efi_selftest: fix variables test for GetNextVariableName()
> > > ce62b0f8f45f1 test/py: Fix efidebug related tests
> > > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule
> > > de489d82e3189 test: test the ESRT creation
> > > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test
> > > e1174c566a61c test/py: efi_secboot: add test for intermediate certificates
> > > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
> > >
> > > and I am pretty sure I am forgetting more on functionality and selftests.
> > >
> > > So basically we've either contributed new selftests for *everything*
> > > we've or fixed the existing ones. The only thing that's not merged is
> > > the TCG selftests which are on upstream review.
> >
> > Er, I didn't say or mean that no tests were written, just that there
> > is too much push-back on it. Heinrich put a huge amount of effort into
> > the tests and basically created a strong base for it. Congrats and
> > huge kudos to him. As to Linaro, no offence intended, and it is great
> > that all these tests have been added. Thank you for your efforts and
> > it is very helpful. But I think you miss my point. Or perhaps you
> > don't even agree with it? I sent an email about this on one patch just
> > a day or two ago.
> >
> > As to the leadership side (my bigger point), Linaro is leading us all
> > down this fragmented path, with TF-A, FIP, more and more binaries and
> > larger firmware diagrams. Or do you disagree with that too?
> You seem to picture the role of the firmware to *only* to boot an operating
> system. I would be surprised to teach you that secure world is a world
> of its own
> that need to be orchestrated and hosts business related applications that stay
> available after U-Boot has disappeared from memory
> (OK with UEFI runtime services it stills occupies some space but
> it should be mostly inactive as Linux own devices - let's not comment
> on this particular aspect).
> As U-Boot has no code for that world, creating another code base would
> actually create fragmentation.
> The mindset I sense from your comments reminds me when relational databases
> reached the market. People wanted to fit their business as
> "relational", killing other
> flavors of databases. It took at least a decade to get back to reason
> and think that
> more than one technology is needed with columnar databases,
> unstructured databases,
> KV databases...
> U-Boot is a "jewel" for what it does. Let's not try to expand it in areas where
> it is not meant to be and create fragmentation.
> >
> > I'm sorry if you find this a bit sharp. But someone needs to be
> > pointing these things out. I don't know who else is doing so. ARM
> > firmware has got noticeably more complicated and fragmented in the
> > last five years, hasn't it? What can Linaro do to address that?
> Linaro very creation was to avoid fragmentation in the arm ecosystem and I
> think we can be proud of what has been accomplished from Linus Torvalds
> comment on the state of kernel for arm.
> We are on a journey to do the same for the firmware.
> The first part was on the secure world firmware (that, again, do a lot of stuff
> for the secure world and happen to also load U-Boot).
> The second part is on the contract between U-Boot and the OS, hence our
> contributions in U-Boot.
> I am
> > very happy to help and provide part of the solution, but it needs a
> > shared vision.
> This vision is entirely explained in Arm Cassini project with more firmware
> related details in SystemReady and further more details for embedded world
> in EBBR.
> You asked me what was the problem we are trying to solve:
> <session from FOSDEM 2021>
> "“A BSP is a badly-patched fork of an ancient U-Boot, a badly-patched
> fork of an ancient Linux, and a badly-patched fork of an ancient
> Yocto”
> “… that, plus often a prehistoric compiler”
> </session from FOSDEM 2021>
> Adding features in U-Boot is only part of the solution: we need to
> have a process
> to keep boards bootable over time and that simplifies the firmware supply chain.
> I understand you don't like the choices, but that is an ecosystem
> choice, not my choice, not Linaro choice, and hopefully you will join
> us in making it happen.
I believe I am involved, at least. I do make time to engage on a call
most weeks. As you say, we don't agree on all the choices. I think the
areas of concern I have are devicetree (several issues which I hope we
are making progress on), proliferation of binaries and complexity of
packaging.
>
> >
> > It's not even just a Linaro/ARM problem. On the x86 side it is fast
> > becoming a living nightmare.
> >
> > Perhaps the problem here is just the pandemic response and the
> > inability for people to get into a room and brainstorm / collaborate /
> > hack on ideas?
> I could not agree more. Mail exchanges tend to self inflate...
> I remember a BoF in a Connect with 20 people around the table talking
> about firmware update
> and finding a way to make anti-bricking standard across boards (see
> yet another effort of defragmentation:-)
> People started the session with "impossible" in mind, and we came out
> with a plan.
> Now we are close to have it. If we could be on the drawing board, I am
> sure you would immediately
> understand and make a better version of our authentication scheme for
> those updates..
> ..and pull the relevant patchset ;-)
> (sorry I could not resist pulling your leg at the end)
> I know you have made big efforts to engage, Ilias. We
> > have spoken many times and I'm sure f2f would be easier.
OK, well let's hope it all works out. Rome wasn't built in a day. It
is an important goal.
Regards,
Simon
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-27 18:32 ` Simon Glass
2021-10-27 19:12 ` Ilias Apalodimas
@ 2021-10-27 19:46 ` François Ozog
1 sibling, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-10-27 19:46 UTC (permalink / raw)
To: Simon Glass
Cc: Heinrich Schuchardt, Ilias Apalodimas, Marcel Ziswiler,
Mark Kettenis, Sean Anderson, Tom Rini, U-Boot Mailing List
Hi Simon,
Le mer. 27 oct. 2021 à 20:33, Simon Glass <sjg@chromium.org> a écrit :
> Hi François,
>
> On Wed, 27 Oct 2021 at 09:38, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> > Hi Simon,
> >
> > On Wed, 27 Oct 2021 at 16:13, Simon Glass <sjg@chromium.org> wrote:
> >>
> >> Hi François,
> >>
> >> On Tue, 26 Oct 2021 at 09:57, François Ozog <francois.ozog@linaro.org>
> wrote:
> >> >
> >> >
> >> >
> >> > On Tue, 26 Oct 2021 at 17:27, Simon Glass <sjg@chromium.org> wrote:
> >> >>
> >> >> Hi François,
> >> >>
> >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog <
> francois.ozog@linaro.org> wrote:
> >> >> >
> >> >> > Hi Simon,
> >> >> >
> >> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg@chromium.org>
> wrote:
> >> >> >>
> >> >> >> At present some of the ideas and techniques behind devicetree in
> U-Boot
> >> >> >> are assumed, implied or unsaid. Add some documentation to cover
> how
> >> >> >> devicetree is build, how it can be modified and the rules about
> using
> >> >> >> the various CONFIG_OF_... options.
> >> >> >>
> >>
> >> [..]
> >>
> >> >> >> +Why not have two devicetrees?
> >> >> >> +-----------------------------
> >> >> >> +
> >> >> >> +Setting aside the argument for restricting U-Boot from having
> its own nodes and
> >> >> >> +properties, another idea proposed is to have two devicetrees,
> one for the
> >> >> >> +U-Boot-specific bits (here called `special`) and one for
> everything else (here
> >> >> >> +called `linux`).
> >> >> >> +
> >> >> >> +On the positive side, it might quieten the discussion alluded to
> in the section
> >> >> >> +above. But there are many negatives to consider and many open
> questions to
> >> >> >> +resolve.
> >> >> >> +
> >> >> >> +- **Bindings** - Presumably the special devicetree would have
> its own bindings.
> >> >> >> + It would not be necessary to put a `u-boot,` prefix on
> anything. People coming
> >> >> >> + across the devicetree source would wonder how it fits in with
> the Linux
> >> >> >> + devicetree.
> >> >> >> +
> >> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the
> devicetree. This
> >> >> >> + would need to be expanded to support two trees. Features which
> need to access
> >> >> >> + both (such as a device driver which reads the special
> devicetree to get some
> >> >> >> + configuration info) could become quite confusing to read and
> write.
> >> >> >> +
> >> >> >> +- **Merging** - Can the two devicetree be merged if a platform
> desires it? If
> >> >> >> + so, how is this managed in tooling? Does it happen during the
> build, in which
> >> >> >> + case they are not really separate at all. Or does U-Boot merge
> them at
> >> >> >> + runtime, in which case this adds time and memory?
> >> >> >> +
> >> >> >> +- **Efficiency** - A second device tree adds more code and more
> code paths. It
> >> >> >> + requires that both be made available to the code in U-Boot,
> e.g. via a
> >> >> >> + separate pointer or argument or API. Overall the separation
> would certainly
> >> >> >> + not speed up U-Boot, nor decrease its size.
> >> >> >> +
> >> >> >> +- **Source code** - At present `u-boot.dtsi` files provide the
> pieces needed for
> >> >> >> + U-Boot for a particular board. Would we use these same files
> for the special
> >> >> >> + devicetree?
> >> >> >> +
> >> >> >> +- **Complexity** - Two devicetrees complicates the build system
> since it must
> >> >> >> + build and package them both. Errors must be reported in such a
> way that it
> >> >> >> + is obvious which one is failing.
> >> >> >> +
> >> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by
> driver model
> >> >> >> + are currently placed in the nodes they relate to. How would
> these tags
> >> >> >> + reference a node that is in a separate devicetree? What extra
> validation would
> >> >> >> + be needed?
> >> >> >> +
> >> >> >> +- **Storage** - How would the two devicetrees be stored in the
> image? At present
> >> >> >> + we simply concatenate the U-Boot binary and the devicetree. We
> could add the
> >> >> >> + special devicetree before the Linux one, so two are
> concatenated, but it is
> >> >> >> + not pretty. We could use binman to support more complex
> arrangements, but only
> >> >> >> + some boards use this at present, so it would be a big change.
> >> >> >> +
> >> >> >> +- **API** - How would another project provide two devicetree
> files to U-Boot at
> >> >> >> + runtime? Presumably this would just be too painful. But if it
> doesn't, it
> >> >> >> + would be unable to configure run-time features of U-Boot
> during the boot.
> >> >> >> +
> >> >> >> +- **Confusion** - No other project has two devicetrees. U-Boot
> would be in the
> >> >> >> + unfortunate position of having to describe this fact to new
> users, along with
> >> >> >> + the (arguably contrived) reason for the arrangement.
> >> >> >> +
> >> >> >
> >> >> > False:
> >> >> > 1) projects in trustedfirmware.org are built to have multiple FDT
> objects, some for "dynamic" configuration purposes.
> >> >>
> >> >> Can you provided a link and I can update this.
> >> >
> >> >
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> >> > Bindings:
> >> > for FCONF:
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_properties.html
> >> > for FF-A:
> https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
> >> > For chain-of-trust:
> https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.html
> >> >
> >> > For some code:
> >> >
> https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fiptool/tbbr_config.c
> >> > From there you can wander and see how dynamic config sections of the
> FIP can contain component specific DTs.
> >> > U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
> >>
> >> OK I can mention that TF-A supports multiple devicetrees if you like,
> >> but I'm not sure we are talking about the same thing.
> >>
> > If I take a possible scenario: OP-TEE to deal with 3 different device
> trees:
> > - the one that will be passed to the OS and for which it may want to do
> some fixups
> > - the one that it is using to run (it may have secure devices that are
> entirely not visible to any normal world OS)
> > - the one that it gets from the FIP and contains runtime configuration
> parameters, accessed through FCONF library)
> >
> >>
> >> U-Boot also supports multiple devicetrees in the build - e.g. SPL and
> >> U-Boot proper. With binman you can create several copies of them for
> >> use with A/B boot, for example. But only one is used as a control DTB
> >> by a particular U-Boot phase at a time. Do you see what I mean?
> >>
> >> >>
> >> >> > 2) STM32MP1 can have dedicated DTBs for TF-A, OP-TEE and U-Boot in
> addition to operating system
> >> >> > As Ilias said, this is not about documentation about the current
> use of DT in U-Boot, but justification of your views on DT.
> >> >> > If taken by the letter, I feel (may be wrong though) that your
> views prevent establish the DT lifecycle and usage as per the desire of
> vendors, partners and customers that supports Arm SystemReady standards.
> >> >>
> >> >> I have gone to great efforts to document things here, as they work in
> >> >> U-Boot today. As you know, U-Boot supports separate control and
> active
> >> >> devicetrees.
> >> >
> >> > I don't know what is an active device tree. Is it the device tree to
> be passed to OS?
> >>
> >> Yes that's right.
> >>
> >> >>
> >> >> But if you are wanting to change to multiple control
> >> >> trees within U-Boot, I'd say the answer is "no, thank you".
> >> >
> >> > I see only one control DT.
> >>
> >> OK good.
> >>
> >> > There is a possibility to store it securely in NT_FW_CONFIG section
> of a FIP. it also has associated signature plus hash mechanisms to attest
> authenticity of it (do not need signature in DT to allow verification:
> this is the associated content certificate section that contains the valid
> hashes).
> >>
> >> What does NT mean? I suppose FW means firmware.
> >
> > Non Trusted; it means normal world as opposed to secure world.
> > It feels unfortunate to say non trusted while it is trusted but running
> outside secure world ;-)
>
> OK, good, so long as it doesn't mean Windows NT I am happy.
>
> >>
> >>
> >> It doesn't really matter where it is stored, so long as U-Boot can
> access it.
> >>
> >> > You can certain have a similar mechanism for binman.
> >>
> >> Note that binman is a packaging tool. Perhaps you should add FIP
> >> support to it if FIP is going to be required too now?
> >>
> > There may be a need for a FIP explanation. I'll check with other guys to
> propose text.
>
> I mean add an entry type to binman for FIP. It supports CBFS already,
> for example.
>
> >
> >>
> >> What I would like, to package up the firmware for ANY board, after all
> >> the building is done in various projects:
> >>
> >> binman -b <board>
> >>
> > FIP deals with a number of firmwares like the SCP and MCP ones running
> on other micro-controllers of a board.
> > So in a sense it is an arm targeted tool.
> > If you want to package firmware for arm boards with binman you will have
> to deal with those firmwares as well as secure world and its trusted
> services as secure partitions that are being developed (including when
> virtualization is in operation in the secure world).
> > So in a word, trying to do this is a big undertaking, but you can try.
>
> Binman supports adding firmware for microcontrollers. For example, see
> here:
>
>
> https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/dts/flashmap-16mb-x86-rw.dtsi#L64
>
> That is a Chrome OS EC binary, one of three in the image.
>
> This is not ARM-specific. That image is actually for x86 Apollo Lake.
>
> > In a short term future (see Alibaba and Marvell announcements) you will
> have to deal with Arm v9 realms and associated firmware.
>
> Why me? Perhaps Linaro could take this on instead of working in a
> separate tool and domain? You guys could really pull things together
> and reduce the fragmentation, if you took it on.
>
Well, what happens in the secure world is getting pretty complex. TFA
solves it elegantly so there is no incentive in maintaining a separate code
base to do the same.
If I picture things in different way, I would say that it the past pre
U-Boot proper was representing 20 and U-Boot proper 80. In new schemes, pre
U-Boot can be said 80 and U-Boot proper 20.
>
> Honestly it is hard enough to even get Linaro people to write a test
> for code they have written. What gives?
>
> >>
> >> >>
> >> >> If there
> >> >> is a use case for that, please can you be specific about what we
> >> >> cannot do with a combined devicetree?
>
> Regards,
> SImon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-27 15:38 ` François Ozog
2021-10-27 18:32 ` Simon Glass
@ 2021-10-27 19:48 ` Tom Rini
2021-10-27 20:13 ` François Ozog
1 sibling, 1 reply; 144+ messages in thread
From: Tom Rini @ 2021-10-27 19:48 UTC (permalink / raw)
To: François Ozog
Cc: Simon Glass, U-Boot Mailing List, Mark Kettenis,
Heinrich Schuchardt, Ilias Apalodimas, Sean Anderson,
Marcel Ziswiler
[-- Attachment #1: Type: text/plain, Size: 6430 bytes --]
On Wed, Oct 27, 2021 at 05:38:28PM +0200, François Ozog wrote:
> Hi Simon,
>
> On Wed, 27 Oct 2021 at 16:13, Simon Glass <sjg@chromium.org> wrote:
>
> > Hi François,
> >
> > On Tue, 26 Oct 2021 at 09:57, François Ozog <francois.ozog@linaro.org>
> > wrote:
> > >
> > >
> > >
> > > On Tue, 26 Oct 2021 at 17:27, Simon Glass <sjg@chromium.org> wrote:
> > >>
> > >> Hi François,
> > >>
> > >> On Tue, 26 Oct 2021 at 08:31, François Ozog <francois.ozog@linaro.org>
> > wrote:
> > >> >
> > >> > Hi Simon,
> > >> >
> > >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg@chromium.org> wrote:
> > >> >>
> > >> >> At present some of the ideas and techniques behind devicetree in
> > U-Boot
> > >> >> are assumed, implied or unsaid. Add some documentation to cover how
> > >> >> devicetree is build, how it can be modified and the rules about using
> > >> >> the various CONFIG_OF_... options.
> > >> >>
> >
> > [..]
> >
> > >> >> +Why not have two devicetrees?
> > >> >> +-----------------------------
> > >> >> +
> > >> >> +Setting aside the argument for restricting U-Boot from having its
> > own nodes and
> > >> >> +properties, another idea proposed is to have two devicetrees, one
> > for the
> > >> >> +U-Boot-specific bits (here called `special`) and one for everything
> > else (here
> > >> >> +called `linux`).
> > >> >> +
> > >> >> +On the positive side, it might quieten the discussion alluded to in
> > the section
> > >> >> +above. But there are many negatives to consider and many open
> > questions to
> > >> >> +resolve.
> > >> >> +
> > >> >> +- **Bindings** - Presumably the special devicetree would have its
> > own bindings.
> > >> >> + It would not be necessary to put a `u-boot,` prefix on anything.
> > People coming
> > >> >> + across the devicetree source would wonder how it fits in with the
> > Linux
> > >> >> + devicetree.
> > >> >> +
> > >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the
> > devicetree. This
> > >> >> + would need to be expanded to support two trees. Features which
> > need to access
> > >> >> + both (such as a device driver which reads the special devicetree
> > to get some
> > >> >> + configuration info) could become quite confusing to read and
> > write.
> > >> >> +
> > >> >> +- **Merging** - Can the two devicetree be merged if a platform
> > desires it? If
> > >> >> + so, how is this managed in tooling? Does it happen during the
> > build, in which
> > >> >> + case they are not really separate at all. Or does U-Boot merge
> > them at
> > >> >> + runtime, in which case this adds time and memory?
> > >> >> +
> > >> >> +- **Efficiency** - A second device tree adds more code and more
> > code paths. It
> > >> >> + requires that both be made available to the code in U-Boot, e.g.
> > via a
> > >> >> + separate pointer or argument or API. Overall the separation would
> > certainly
> > >> >> + not speed up U-Boot, nor decrease its size.
> > >> >> +
> > >> >> +- **Source code** - At present `u-boot.dtsi` files provide the
> > pieces needed for
> > >> >> + U-Boot for a particular board. Would we use these same files for
> > the special
> > >> >> + devicetree?
> > >> >> +
> > >> >> +- **Complexity** - Two devicetrees complicates the build system
> > since it must
> > >> >> + build and package them both. Errors must be reported in such a
> > way that it
> > >> >> + is obvious which one is failing.
> > >> >> +
> > >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by
> > driver model
> > >> >> + are currently placed in the nodes they relate to. How would these
> > tags
> > >> >> + reference a node that is in a separate devicetree? What extra
> > validation would
> > >> >> + be needed?
> > >> >> +
> > >> >> +- **Storage** - How would the two devicetrees be stored in the
> > image? At present
> > >> >> + we simply concatenate the U-Boot binary and the devicetree. We
> > could add the
> > >> >> + special devicetree before the Linux one, so two are concatenated,
> > but it is
> > >> >> + not pretty. We could use binman to support more complex
> > arrangements, but only
> > >> >> + some boards use this at present, so it would be a big change.
> > >> >> +
> > >> >> +- **API** - How would another project provide two devicetree files
> > to U-Boot at
> > >> >> + runtime? Presumably this would just be too painful. But if it
> > doesn't, it
> > >> >> + would be unable to configure run-time features of U-Boot during
> > the boot.
> > >> >> +
> > >> >> +- **Confusion** - No other project has two devicetrees. U-Boot
> > would be in the
> > >> >> + unfortunate position of having to describe this fact to new
> > users, along with
> > >> >> + the (arguably contrived) reason for the arrangement.
> > >> >> +
> > >> >
> > >> > False:
> > >> > 1) projects in trustedfirmware.org are built to have multiple FDT
> > objects, some for "dynamic" configuration purposes.
> > >>
> > >> Can you provided a link and I can update this.
> > >
> > >
> > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> > > Bindings:
> > > for FCONF:
> > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_properties.html
> > > for FF-A:
> > https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
> > > For chain-of-trust:
> > https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.html
> > >
> > > For some code:
> > >
> > https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fiptool/tbbr_config.c
> > > From there you can wander and see how dynamic config sections of the FIP
> > can contain component specific DTs.
> > > U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
> >
> > OK I can mention that TF-A supports multiple devicetrees if you like,
> > but I'm not sure we are talking about the same thing.
>
> If I take a possible scenario: OP-TEE to deal with 3 different device
> trees:
> - the one that will be passed to the OS and for which it may want to do
> some fixups
> - the one that it is using to run (it may have secure devices that are
> entirely not visible to any normal world OS)
What relationship does this device tree that OP-TEE is using itself bear
to the one is will pass to the OS?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
2021-10-27 19:48 ` Tom Rini
@ 2021-10-27 20:13 ` François Ozog
0 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-10-27 20:13 UTC (permalink / raw)
To: Tom Rini
Cc: Heinrich Schuchardt, Ilias Apalodimas, Marcel Ziswiler,
Mark Kettenis, Sean Anderson, Simon Glass, U-Boot Mailing List
Hi Tom
Le mer. 27 oct. 2021 à 21:48, Tom Rini <trini@konsulko.com> a écrit :
> On Wed, Oct 27, 2021 at 05:38:28PM +0200, François Ozog wrote:
> > Hi Simon,
> >
> > On Wed, 27 Oct 2021 at 16:13, Simon Glass <sjg@chromium.org> wrote:
> >
> > > Hi François,
> > >
> > > On Tue, 26 Oct 2021 at 09:57, François Ozog <francois.ozog@linaro.org>
> > > wrote:
> > > >
> > > >
> > > >
> > > > On Tue, 26 Oct 2021 at 17:27, Simon Glass <sjg@chromium.org> wrote:
> > > >>
> > > >> Hi François,
> > > >>
> > > >> On Tue, 26 Oct 2021 at 08:31, François Ozog <
> francois.ozog@linaro.org>
> > > wrote:
> > > >> >
> > > >> > Hi Simon,
> > > >> >
> > > >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg@chromium.org>
> wrote:
> > > >> >>
> > > >> >> At present some of the ideas and techniques behind devicetree in
> > > U-Boot
> > > >> >> are assumed, implied or unsaid. Add some documentation to cover
> how
> > > >> >> devicetree is build, how it can be modified and the rules about
> using
> > > >> >> the various CONFIG_OF_... options.
> > > >> >>
> > >
> > > [..]
> > >
> > > >> >> +Why not have two devicetrees?
> > > >> >> +-----------------------------
> > > >> >> +
> > > >> >> +Setting aside the argument for restricting U-Boot from having
> its
> > > own nodes and
> > > >> >> +properties, another idea proposed is to have two devicetrees,
> one
> > > for the
> > > >> >> +U-Boot-specific bits (here called `special`) and one for
> everything
> > > else (here
> > > >> >> +called `linux`).
> > > >> >> +
> > > >> >> +On the positive side, it might quieten the discussion alluded
> to in
> > > the section
> > > >> >> +above. But there are many negatives to consider and many open
> > > questions to
> > > >> >> +resolve.
> > > >> >> +
> > > >> >> +- **Bindings** - Presumably the special devicetree would have
> its
> > > own bindings.
> > > >> >> + It would not be necessary to put a `u-boot,` prefix on
> anything.
> > > People coming
> > > >> >> + across the devicetree source would wonder how it fits in with
> the
> > > Linux
> > > >> >> + devicetree.
> > > >> >> +
> > > >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the
> > > devicetree. This
> > > >> >> + would need to be expanded to support two trees. Features which
> > > need to access
> > > >> >> + both (such as a device driver which reads the special
> devicetree
> > > to get some
> > > >> >> + configuration info) could become quite confusing to read and
> > > write.
> > > >> >> +
> > > >> >> +- **Merging** - Can the two devicetree be merged if a platform
> > > desires it? If
> > > >> >> + so, how is this managed in tooling? Does it happen during the
> > > build, in which
> > > >> >> + case they are not really separate at all. Or does U-Boot merge
> > > them at
> > > >> >> + runtime, in which case this adds time and memory?
> > > >> >> +
> > > >> >> +- **Efficiency** - A second device tree adds more code and more
> > > code paths. It
> > > >> >> + requires that both be made available to the code in U-Boot,
> e.g.
> > > via a
> > > >> >> + separate pointer or argument or API. Overall the separation
> would
> > > certainly
> > > >> >> + not speed up U-Boot, nor decrease its size.
> > > >> >> +
> > > >> >> +- **Source code** - At present `u-boot.dtsi` files provide the
> > > pieces needed for
> > > >> >> + U-Boot for a particular board. Would we use these same files
> for
> > > the special
> > > >> >> + devicetree?
> > > >> >> +
> > > >> >> +- **Complexity** - Two devicetrees complicates the build system
> > > since it must
> > > >> >> + build and package them both. Errors must be reported in such a
> > > way that it
> > > >> >> + is obvious which one is failing.
> > > >> >> +
> > > >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by
> > > driver model
> > > >> >> + are currently placed in the nodes they relate to. How would
> these
> > > tags
> > > >> >> + reference a node that is in a separate devicetree? What extra
> > > validation would
> > > >> >> + be needed?
> > > >> >> +
> > > >> >> +- **Storage** - How would the two devicetrees be stored in the
> > > image? At present
> > > >> >> + we simply concatenate the U-Boot binary and the devicetree. We
> > > could add the
> > > >> >> + special devicetree before the Linux one, so two are
> concatenated,
> > > but it is
> > > >> >> + not pretty. We could use binman to support more complex
> > > arrangements, but only
> > > >> >> + some boards use this at present, so it would be a big change.
> > > >> >> +
> > > >> >> +- **API** - How would another project provide two devicetree
> files
> > > to U-Boot at
> > > >> >> + runtime? Presumably this would just be too painful. But if it
> > > doesn't, it
> > > >> >> + would be unable to configure run-time features of U-Boot
> during
> > > the boot.
> > > >> >> +
> > > >> >> +- **Confusion** - No other project has two devicetrees. U-Boot
> > > would be in the
> > > >> >> + unfortunate position of having to describe this fact to new
> > > users, along with
> > > >> >> + the (arguably contrived) reason for the arrangement.
> > > >> >> +
> > > >> >
> > > >> > False:
> > > >> > 1) projects in trustedfirmware.org are built to have multiple FDT
> > > objects, some for "dynamic" configuration purposes.
> > > >>
> > > >> Can you provided a link and I can update this.
> > > >
> > > >
> > >
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> > > > Bindings:
> > > > for FCONF:
> > >
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_properties.html
> > > > for FF-A:
> > >
> https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
> > > > For chain-of-trust:
> > >
> https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.html
> > > >
> > > > For some code:
> > > >
> > >
> https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fiptool/tbbr_config.c
> > > > From there you can wander and see how dynamic config sections of the
> FIP
> > > can contain component specific DTs.
> > > > U-Boot "private" DT could be securely stored in NT_FW_CONFIG section.
> > >
> > > OK I can mention that TF-A supports multiple devicetrees if you like,
> > > but I'm not sure we are talking about the same thing.
> >
> > If I take a possible scenario: OP-TEE to deal with 3 different device
> > trees:
> > - the one that will be passed to the OS and for which it may want to do
> > some fixups
> > - the one that it is using to run (it may have secure devices that are
> > entirely not visible to any normal world OS)
>
> What relationship does this device tree that OP-TEE is using itself bear
> to the one is will pass to the OS?
may be none. The DT may contain only secure devices and devices for which
there are no Linux drivers (clocks or others).
I am not sure “secure device” is clear. This is a device that is separated
by hardware methods to be only accessible by EL3, secure ELx. So even if
you have secure mmio range you can’t access it from normal world at all.
>
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 144+ messages in thread
* [PATCH v5 03/26] arm: qemu: Mention -nographic in the docs
2021-10-26 0:23 ` Simon Glass
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Albert Aribaud, qemu-devel
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:
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [PATCH v5 03/26] arm: qemu: Mention -nographic in the docs
@ 2021-10-26 0:23 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Albert Aribaud, Heinrich Schuchardt, Simon Glass,
Ilias Apalodimas, qemu-devel, Sean Anderson, Mark Kettenis
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:
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [PATCH v5 04/26] arm: riscv: qemu: Explain how to extract the generated dt
2021-10-26 0:23 ` Simon Glass
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Albert Aribaud, qemu-devel
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
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 04/26] arm: riscv: qemu: Explain how to extract the generated dt
@ 2021-10-26 0:23 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Albert Aribaud, Heinrich Schuchardt, Simon Glass,
Ilias Apalodimas, qemu-devel, Sean Anderson, Mark Kettenis
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
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [PATCH v5 05/26] arm: qemu: Add a devicetree file for qemu_arm
2021-10-26 0:23 ` Simon Glass
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Albert Aribaud, Tuomas Tynkkynen,
qemu-devel
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
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 05/26] arm: qemu: Add a devicetree file for qemu_arm
@ 2021-10-26 0:23 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Albert Aribaud, Heinrich Schuchardt, Simon Glass,
Ilias Apalodimas, qemu-devel, Sean Anderson, Tuomas Tynkkynen,
Mark Kettenis
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
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-10-26 0:23 ` Simon Glass
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Albert Aribaud, Tuomas Tynkkynen,
qemu-devel
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
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-10-26 0:23 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Albert Aribaud, Heinrich Schuchardt, Simon Glass,
Ilias Apalodimas, qemu-devel, Sean Anderson, Tuomas Tynkkynen,
Mark Kettenis
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
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-10-26 0:23 ` Simon Glass
@ 2021-11-01 10:48 ` Peter Maydell
-1 siblings, 0 replies; 144+ messages in thread
From: Peter Maydell @ 2021-11-01 10:48 UTC (permalink / raw)
To: Simon Glass
Cc: Albert Aribaud, Tom Rini, Heinrich Schuchardt, Ilias Apalodimas,
qemu-devel, Sean Anderson, U-Boot Mailing List, Tuomas Tynkkynen,
Mark Kettenis
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
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-01 10:48 ` Peter Maydell
0 siblings, 0 replies; 144+ messages in thread
From: Peter Maydell @ 2021-11-01 10:48 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Tom Rini, Albert Aribaud,
Heinrich Schuchardt, Ilias Apalodimas, qemu-devel, Sean Anderson,
Tuomas Tynkkynen, Mark Kettenis
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
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-01 10:48 ` Peter Maydell
@ 2021-11-01 16:58 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-01 16:58 UTC (permalink / raw)
To: Peter Maydell
Cc: Albert Aribaud, Tom Rini, Heinrich Schuchardt, Ilias Apalodimas,
QEMU Developers, Sean Anderson, U-Boot Mailing List,
Tuomas Tynkkynen, Mark Kettenis
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. 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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-01 16:58 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-01 16:58 UTC (permalink / raw)
To: Peter Maydell
Cc: U-Boot Mailing List, Tom Rini, Albert Aribaud,
Heinrich Schuchardt, Ilias Apalodimas, QEMU Developers,
Sean Anderson, Tuomas Tynkkynen, Mark Kettenis
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. 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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-01 16:58 ` Simon Glass
@ 2021-11-01 17:33 ` François Ozog
-1 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-11-01 17:33 UTC (permalink / raw)
To: Simon Glass
Cc: Albert Aribaud, Heinrich Schuchardt, Ilias Apalodimas,
Mark Kettenis, Peter Maydell, QEMU Developers, Sean Anderson,
Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List
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.
> 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
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-01 17:33 ` François Ozog
0 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-11-01 17:33 UTC (permalink / raw)
To: Simon Glass
Cc: Peter Maydell, Albert Aribaud, U-Boot Mailing List,
Heinrich Schuchardt, Ilias Apalodimas, QEMU Developers,
Sean Anderson, Tuomas Tynkkynen, Tom Rini, Mark Kettenis
[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]
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.
> 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
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 3729 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-01 17:33 ` François Ozog
@ 2021-11-01 18:07 ` Tom Rini
-1 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-01 18:07 UTC (permalink / raw)
To: François Ozog
Cc: Simon Glass, Albert Aribaud, Heinrich Schuchardt,
Ilias Apalodimas, Mark Kettenis, Peter Maydell, QEMU Developers,
Sean Anderson, Tuomas Tynkkynen, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]
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.
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-01 18:07 ` Tom Rini
0 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-01 18:07 UTC (permalink / raw)
To: François Ozog
Cc: Peter Maydell, Albert Aribaud, U-Boot Mailing List,
Heinrich Schuchardt, Simon Glass, Ilias Apalodimas,
QEMU Developers, Sean Anderson, Tuomas Tynkkynen, Mark Kettenis
[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]
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.
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-01 18:07 ` Tom Rini
@ 2021-11-02 15:00 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-02 15:00 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Albert Aribaud, Heinrich Schuchardt,
Ilias Apalodimas, Mark Kettenis, Peter Maydell, QEMU Developers,
Sean Anderson, Tuomas Tynkkynen, U-Boot Mailing List
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?
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-02 15:00 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-02 15:00 UTC (permalink / raw)
To: Tom Rini
Cc: Peter Maydell, Albert Aribaud, François Ozog,
U-Boot Mailing List, Heinrich Schuchardt, Ilias Apalodimas,
QEMU Developers, Sean Anderson, Tuomas Tynkkynen, Mark Kettenis
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?
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-02 15:00 ` Simon Glass
@ 2021-11-02 17:28 ` Tom Rini
-1 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-02 17:28 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Albert Aribaud, Heinrich Schuchardt,
Ilias Apalodimas, Mark Kettenis, Peter Maydell, QEMU Developers,
Sean Anderson, Tuomas Tynkkynen, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 3734 bytes --]
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.
> > 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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-02 17:28 ` Tom Rini
0 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-02 17:28 UTC (permalink / raw)
To: Simon Glass
Cc: Peter Maydell, Albert Aribaud, François Ozog,
U-Boot Mailing List, Heinrich Schuchardt, Ilias Apalodimas,
QEMU Developers, Sean Anderson, Tuomas Tynkkynen, Mark Kettenis
[-- Attachment #1: Type: text/plain, Size: 3734 bytes --]
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.
> > 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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-02 17:28 ` Tom Rini
@ 2021-11-03 1:29 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-03 1:29 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Albert Aribaud, Heinrich Schuchardt,
Ilias Apalodimas, Mark Kettenis, Peter Maydell, QEMU Developers,
Sean Anderson, Tuomas Tynkkynen, U-Boot Mailing List
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. 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@google.com/
[2] https://u-boot.readthedocs.io/en/latest/board/emulation/qemu-arm.html
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-03 1:29 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-03 1:29 UTC (permalink / raw)
To: Tom Rini
Cc: Peter Maydell, Albert Aribaud, François Ozog,
U-Boot Mailing List, Heinrich Schuchardt, Ilias Apalodimas,
QEMU Developers, Sean Anderson, Tuomas Tynkkynen, Mark Kettenis
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. 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@google.com/
[2] https://u-boot.readthedocs.io/en/latest/board/emulation/qemu-arm.html
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-03 1:29 ` Simon Glass
@ 2021-11-03 5:29 ` François Ozog
-1 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-11-03 5:29 UTC (permalink / raw)
To: Simon Glass
Cc: Albert Aribaud, Heinrich Schuchardt, Ilias Apalodimas,
Mark Kettenis, Peter Maydell, QEMU Developers, Sean Anderson,
Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List
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?
>
> 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.
>
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’”
>
> 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.
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@google.com/
> [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
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-03 5:29 ` François Ozog
0 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-11-03 5:29 UTC (permalink / raw)
To: Simon Glass
Cc: Peter Maydell, Albert Aribaud, U-Boot Mailing List,
Heinrich Schuchardt, Ilias Apalodimas, QEMU Developers,
Sean Anderson, Tuomas Tynkkynen, Tom Rini, Mark Kettenis
[-- Attachment #1: Type: text/plain, Size: 9927 bytes --]
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?
>
> 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.
>
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’”
>
> 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.
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@google.com/
> [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
[-- Attachment #2: Type: text/html, Size: 14398 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-03 5:29 ` François Ozog
@ 2021-11-03 14:41 ` Tom Rini
-1 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-03 14:41 UTC (permalink / raw)
To: François Ozog
Cc: Simon Glass, Albert Aribaud, Heinrich Schuchardt,
Ilias Apalodimas, Mark Kettenis, Peter Maydell, QEMU Developers,
Sean Anderson, Tuomas Tynkkynen, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 687 bytes --]
On Wed, Nov 03, 2021 at 06:29:20AM +0100, François Ozog wrote:
[snip]
> > 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.
>
> 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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-03 14:41 ` Tom Rini
0 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-03 14:41 UTC (permalink / raw)
To: François Ozog
Cc: Peter Maydell, Albert Aribaud, U-Boot Mailing List,
Heinrich Schuchardt, Simon Glass, Ilias Apalodimas,
QEMU Developers, Sean Anderson, Tuomas Tynkkynen, Mark Kettenis
[-- Attachment #1: Type: text/plain, Size: 687 bytes --]
On Wed, Nov 03, 2021 at 06:29:20AM +0100, François Ozog wrote:
[snip]
> > 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.
>
> 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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-03 14:41 ` Tom Rini
@ 2021-11-04 11:09 ` Peter Maydell
-1 siblings, 0 replies; 144+ messages in thread
From: Peter Maydell @ 2021-11-04 11:09 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Simon Glass, Albert Aribaud,
Heinrich Schuchardt, Ilias Apalodimas, Mark Kettenis,
QEMU Developers, Sean Anderson, Tuomas Tynkkynen,
U-Boot Mailing List
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]
> > > 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.
> >
> > 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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-04 11:09 ` Peter Maydell
0 siblings, 0 replies; 144+ messages in thread
From: Peter Maydell @ 2021-11-04 11:09 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Albert Aribaud, U-Boot Mailing List,
Heinrich Schuchardt, Simon Glass, Ilias Apalodimas,
QEMU Developers, Sean Anderson, Tuomas Tynkkynen, Mark Kettenis
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]
> > > 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.
> >
> > 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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-04 11:09 ` Peter Maydell
@ 2021-11-04 11:22 ` François Ozog
-1 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-11-04 11:22 UTC (permalink / raw)
To: Peter Maydell
Cc: Albert Aribaud, Heinrich Schuchardt, Ilias Apalodimas,
Mark Kettenis, QEMU Developers, Sean Anderson, Simon Glass,
Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List
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]
> > > > 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.
> > >
> > > 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
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-04 11:22 ` François Ozog
0 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-11-04 11:22 UTC (permalink / raw)
To: Peter Maydell
Cc: Albert Aribaud, Tom Rini, U-Boot Mailing List,
Heinrich Schuchardt, Simon Glass, Ilias Apalodimas,
QEMU Developers, Sean Anderson, Tuomas Tynkkynen, Mark Kettenis
[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]
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]
> > > > 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.
> > >
> > > 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
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 4234 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-04 11:22 ` François Ozog
@ 2021-11-04 11:41 ` Peter Maydell
-1 siblings, 0 replies; 144+ messages in thread
From: Peter Maydell @ 2021-11-04 11:41 UTC (permalink / raw)
To: François Ozog
Cc: Albert Aribaud, Heinrich Schuchardt, Ilias Apalodimas,
Mark Kettenis, QEMU Developers, Sean Anderson, Simon Glass,
Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-04 11:41 ` Peter Maydell
0 siblings, 0 replies; 144+ messages in thread
From: Peter Maydell @ 2021-11-04 11:41 UTC (permalink / raw)
To: François Ozog
Cc: Albert Aribaud, Tom Rini, U-Boot Mailing List,
Heinrich Schuchardt, Simon Glass, Ilias Apalodimas,
QEMU Developers, Sean Anderson, Tuomas Tynkkynen, Mark Kettenis
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-04 11:41 ` Peter Maydell
@ 2021-11-04 11:48 ` François Ozog
-1 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-11-04 11:48 UTC (permalink / raw)
To: Peter Maydell
Cc: Albert Aribaud, Heinrich Schuchardt, Ilias Apalodimas,
Mark Kettenis, QEMU Developers, Sean Anderson, Simon Glass,
Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List
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
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-04 11:48 ` François Ozog
0 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-11-04 11:48 UTC (permalink / raw)
To: Peter Maydell
Cc: Albert Aribaud, Tom Rini, U-Boot Mailing List,
Heinrich Schuchardt, Simon Glass, Ilias Apalodimas,
QEMU Developers, Sean Anderson, Tuomas Tynkkynen, Mark Kettenis
[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]
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
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 3326 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-03 5:29 ` François Ozog
@ 2021-11-03 14:44 ` François Ozog
-1 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-11-03 14:44 UTC (permalink / raw)
To: Simon Glass
Cc: Albert Aribaud, Heinrich Schuchardt, Ilias Apalodimas,
Mark Kettenis, Peter Maydell, QEMU Developers, Sean Anderson,
Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List
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?
>>
>> 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.
>>
> 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’”
>
>>
>> 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.
>
> 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@google.com/
>> [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
>
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-03 14:44 ` François Ozog
0 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-11-03 14:44 UTC (permalink / raw)
To: Simon Glass
Cc: Peter Maydell, Albert Aribaud, U-Boot Mailing List,
Heinrich Schuchardt, Ilias Apalodimas, QEMU Developers,
Sean Anderson, Tuomas Tynkkynen, Tom Rini, Mark Kettenis
[-- Attachment #1: Type: text/plain, Size: 10701 bytes --]
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?
>>
>> 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.
>>
> 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’”
>
>>
>> 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.
>
> 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@google.com/
>> [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
>
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 16810 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-03 1:29 ` Simon Glass
@ 2021-11-03 14:39 ` Tom Rini
-1 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-03 14:39 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Albert Aribaud, Heinrich Schuchardt,
Ilias Apalodimas, Mark Kettenis, Peter Maydell, QEMU Developers,
Sean Anderson, Tuomas Tynkkynen, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 11738 bytes --]
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?
>
> 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?
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?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-03 14:39 ` Tom Rini
0 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-03 14:39 UTC (permalink / raw)
To: Simon Glass
Cc: Peter Maydell, Albert Aribaud, François Ozog,
U-Boot Mailing List, Heinrich Schuchardt, Ilias Apalodimas,
QEMU Developers, Sean Anderson, Tuomas Tynkkynen, Mark Kettenis
[-- Attachment #1: Type: text/plain, Size: 11738 bytes --]
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?
>
> 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?
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?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-01 17:33 ` François Ozog
@ 2021-11-02 14:59 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-02 14:59 UTC (permalink / raw)
To: François Ozog
Cc: Albert Aribaud, Heinrich Schuchardt, Ilias Apalodimas,
Mark Kettenis, Peter Maydell, QEMU Developers, Sean Anderson,
Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List
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:
>> > 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.
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-sjg@chromium.org/
https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-sjg@chromium.org/
>>
>> 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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-02 14:59 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-02 14:59 UTC (permalink / raw)
To: François Ozog
Cc: Peter Maydell, Albert Aribaud, U-Boot Mailing List,
Heinrich Schuchardt, Ilias Apalodimas, QEMU Developers,
Sean Anderson, Tuomas Tynkkynen, Tom Rini, Mark Kettenis
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:
>> > 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.
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-sjg@chromium.org/
https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-sjg@chromium.org/
>>
>> 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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-02 14:59 ` Simon Glass
@ 2021-11-02 16:57 ` Tom Rini
-1 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-02 16:57 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Albert Aribaud, Heinrich Schuchardt,
Ilias Apalodimas, Mark Kettenis, Peter Maydell, QEMU Developers,
Sean Anderson, Tuomas Tynkkynen, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]
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:
> >> > 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.
>
> 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-sjg@chromium.org/
> https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-sjg@chromium.org/
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-02 16:57 ` Tom Rini
0 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-02 16:57 UTC (permalink / raw)
To: Simon Glass
Cc: Peter Maydell, Albert Aribaud, François Ozog,
U-Boot Mailing List, Heinrich Schuchardt, Ilias Apalodimas,
QEMU Developers, Sean Anderson, Tuomas Tynkkynen, Mark Kettenis
[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]
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:
> >> > 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.
>
> 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-sjg@chromium.org/
> https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-sjg@chromium.org/
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-02 16:57 ` Tom Rini
@ 2021-11-03 1:32 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-03 1:32 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Albert Aribaud, Heinrich Schuchardt,
Ilias Apalodimas, Mark Kettenis, Peter Maydell, QEMU Developers,
Sean Anderson, Tuomas Tynkkynen, U-Boot Mailing List
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:
> > >> > 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.
> >
> > 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-sjg@chromium.org/
> > https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-sjg@chromium.org/
>
> 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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-03 1:32 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-03 1:32 UTC (permalink / raw)
To: Tom Rini
Cc: Peter Maydell, Albert Aribaud, François Ozog,
U-Boot Mailing List, Heinrich Schuchardt, Ilias Apalodimas,
QEMU Developers, Sean Anderson, Tuomas Tynkkynen, Mark Kettenis
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:
> > >> > 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.
> >
> > 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-sjg@chromium.org/
> > https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-sjg@chromium.org/
>
> 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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-11-03 1:32 ` Simon Glass
@ 2021-11-03 14:39 ` Tom Rini
-1 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-03 14:39 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Albert Aribaud, Heinrich Schuchardt,
Ilias Apalodimas, Mark Kettenis, Peter Maydell, QEMU Developers,
Sean Anderson, Tuomas Tynkkynen, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 3531 bytes --]
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:
> > > >> > 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.
> > >
> > > 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-sjg@chromium.org/
> > > https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-sjg@chromium.org/
> >
> > 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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-11-03 14:39 ` Tom Rini
0 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-03 14:39 UTC (permalink / raw)
To: Simon Glass
Cc: Peter Maydell, Albert Aribaud, François Ozog,
U-Boot Mailing List, Heinrich Schuchardt, Ilias Apalodimas,
QEMU Developers, Sean Anderson, Tuomas Tynkkynen, Mark Kettenis
[-- Attachment #1: Type: text/plain, Size: 3531 bytes --]
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:
> > > >> > 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.
> > >
> > > 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-sjg@chromium.org/
> > > https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-sjg@chromium.org/
> >
> > 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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* [PATCH v5 07/26] riscv: qemu: Add devicetree files for qemu_riscv32/64
2021-10-26 0:23 ` Simon Glass
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Bin Meng, qemu-devel
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
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 07/26] riscv: qemu: Add devicetree files for qemu_riscv32/64
@ 2021-10-26 0:23 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Heinrich Schuchardt, Simon Glass, Ilias Apalodimas,
qemu-devel, Sean Anderson, Bin Meng, Mark Kettenis
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
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [PATCH v5 08/26] arm: rpi: Add a devicetree file for rpi_4
2021-10-26 0:23 ` Simon Glass
` (7 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Albert Aribaud, Matthias Brugger,
Stephen Warren, Stephen Warren
Add this file, obtained from the Raspbian boot disk, so there is a
reference devicetree in the U-Boot tree. The same one is used for
32- and 64-bit variants.
Note that U-Boot does not normally need this at runtime, since
CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
devicetree at runtime.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++++++++
configs/rpi_4_32b_defconfig | 1 +
configs/rpi_4_defconfig | 1 +
configs/rpi_arm64_defconfig | 1 +
5 files changed, 1963 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 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;"
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 09/26] arm: vexpress: Add a devicetree file for juno
2021-10-26 0:23 ` Simon Glass
` (8 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Albert Aribaud, Linus Walleij
Add this file, obtained from the Linaro website[1], so there is a
reference file in the U-Boot tree.
Note that U-Boot does not normally need this at runtime, since
CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
devicetree at runtime.
[1] https://releases.linaro.org/android/reference-lcr/juno/7.1-17.05/
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/dts/Makefile | 3 +
arch/arm/dts/juno-r2.dts | 1038 ++++++++++++++++++++++++
configs/vexpress_aemv8a_juno_defconfig | 1 +
3 files changed, 1042 insertions(+)
create mode 100644 arch/arm/dts/juno-r2.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 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"
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 10/26] arm: xenguest_arm64: Add a fake devicetree file
2021-10-26 0:23 ` Simon Glass
` (9 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Albert Aribaud,
Anastasiia Lukianenko, Oleksandr Andrushchenko
Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.
The build instructions in U-Boot do not provide enough detail to build a
useful devicetree, unfortunately.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/dts/Makefile | 2 ++
arch/arm/dts/xenguest-arm64.dts | 15 +++++++++++++++
configs/xenguest_arm64_defconfig | 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
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 11/26] arm: octeontx: Add a fake devicetree file
2021-10-26 0:23 ` Simon Glass
` (10 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Aaron Williams, Albert Aribaud
Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.
Unfortunately there are no build instructions in the U-Boot tree to enable
a real file to be created.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/dts/Makefile | 3 +++
arch/arm/dts/octeontx.dts | 14 ++++++++++++++
configs/octeontx2_95xx_defconfig | 1 +
configs/octeontx2_96xx_defconfig | 1 +
configs/octeontx_81xx_defconfig | 1 +
configs/octeontx_83xx_defconfig | 1 +
6 files changed, 21 insertions(+)
create mode 100644 arch/arm/dts/octeontx.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 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
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 12/26] arm: xilinx_versal_virt: Add a devicetree file
2021-10-26 0:23 ` Simon Glass
` (11 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Albert Aribaud, Michal Simek
Add a devicetree file obtained from qemu for this board. This was obtained
with:
qemu-system-aarch64 -M xlnx-versal-virt -machine dumpdtb=dtb.dtb
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/xilinx-versal-virt.dts | 307 +++++++++++++++++++++++++++
configs/xilinx_versal_virt_defconfig | 1 +
3 files changed, 310 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 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
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 13/26] arm: bcm7xxx: Add a devicetree file
2021-10-26 0:23 ` Simon Glass
` (12 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Albert Aribaud, Thomas Fitzsimmons
Add a dummy devicetree file for these boards. It seems to be possible to
obtain a real one from another bootloader called 'bolt' but I will leave
this to the maintainer.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/dts/Makefile | 2 ++
arch/arm/dts/bcm7xxx.dts | 15 +++++++++++++++
configs/bcm7260_defconfig | 1 +
configs/bcm7445_defconfig | 1 +
4 files changed, 19 insertions(+)
create mode 100644 arch/arm/dts/bcm7xxx.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 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
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 14/26] arm: qemu-ppce500: Add a devicetree file
2021-10-26 0:23 ` Simon Glass
` (13 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Albert Aribaud, Alexander Graf,
Bin Meng
Add a devicetree file obtained from qemu for this board. This was obtained
with:
qemu-system-ppc64 -machine ppce500 -cpu e6500 -M dumpdtb=dtb.dtb
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/powerpc/dts/Makefile | 1 +
arch/powerpc/dts/qemu-ppce500.dts | 264 ++++++++++++++++++++++++++++++
configs/qemu-ppce500_defconfig | 1 +
3 files changed, 266 insertions(+)
create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
diff --git a/arch/powerpc/dts/Makefile b/arch/powerpc/dts/Makefile
index ceaa8ce5c82..66d22ae8a45 100644
--- a/arch/powerpc/dts/Makefile
+++ b/arch/powerpc/dts/Makefile
@@ -18,6 +18,7 @@ dtb-$(CONFIG_TARGET_P2041RDB) += p2041rdb.dtb
dtb-$(CONFIG_TARGET_P3041DS) += p3041ds.dtb
dtb-$(CONFIG_TARGET_P4080DS) += p4080ds.dtb
dtb-$(CONFIG_TARGET_P5040DS) += p5040ds.dtb
+dtb-$(CONFIG_TARGET_QEMU_PPCE500) += qemu-ppce500.dtb
dtb-$(CONFIG_TARGET_SOCRATES) += socrates.dtb
dtb-$(CONFIG_TARGET_T1024RDB) += t1024rdb.dtb
dtb-$(CONFIG_TARGET_T1042D4RDB) += t1042d4rdb.dtb
diff --git a/arch/powerpc/dts/qemu-ppce500.dts b/arch/powerpc/dts/qemu-ppce500.dts
new file mode 100644
index 00000000000..92368e4d731
--- /dev/null
+++ b/arch/powerpc/dts/qemu-ppce500.dts
@@ -0,0 +1,264 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu-ppce400
+
+ * Copyright 2021 Google LLC
+ */
+/dts-v1/;
+
+/ {
+ compatible = "fsl,qemu-e500";
+ model = "QEMU ppce500";
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+
+ platform@f00000000 {
+ interrupt-parent = <0x8003>;
+ ranges = <0x00 0x0f 0x00 0x8000000>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ pci@fe0008000 {
+ #address-cells = <0x03>;
+ #size-cells = <0x02>;
+ #interrupt-cells = <0x01>;
+ clock-frequency = <0x3f940aa>;
+ reg = <0x0f 0xe0008000 0x00 0x1000>;
+ ranges = <0x2000000 0x00 0xe0000000 0x0c
+ 0x00 0x00 0x20000000 0x1000000
+ 0x00 0x00 0x0f 0xe1000000
+ 0x00 0x10000>;
+ fsl,msi = <0x8004>;
+ bus-range = <0x00 0xff>;
+ interrupts = <0x18 0x02>;
+ interrupt-parent = <0x8003>;
+ interrupt-map = <0x800 0x00 0x00 0x01 0x8003 0x02 0x01 0x800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x1000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x1000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x1000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x1000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x1800 0x00 0x00 0x01 0x8003 0x04 0x01 0x1800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x1800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x1800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0x2000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0x2000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0x2000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0x2000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0x2800 0x00 0x00 0x01 0x8003 0x02 0x01 0x2800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x2800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x2800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x3000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x3000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x3000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x3000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x3800 0x00 0x00 0x01 0x8003 0x04 0x01 0x3800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x3800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x3800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0x4000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0x4000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0x4000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0x4000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0x4800 0x00 0x00 0x01 0x8003 0x02 0x01 0x4800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x4800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x4800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x5000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x5000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x5000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x5000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x5800 0x00 0x00 0x01 0x8003 0x04 0x01 0x5800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x5800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x5800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0x6000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0x6000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0x6000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0x6000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0x6800 0x00 0x00 0x01 0x8003 0x02 0x01 0x6800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x6800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x6800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x7000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x7000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x7000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x7000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x7800 0x00 0x00 0x01 0x8003 0x04 0x01 0x7800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x7800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x7800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0x8000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0x8000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0x8000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0x8000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0x8800 0x00 0x00 0x01 0x8003 0x02 0x01 0x8800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x8800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x8800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x9000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x9000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x9000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x9000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x9800 0x00 0x00 0x01 0x8003 0x04 0x01 0x9800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x9800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x9800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0xa000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0xa000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0xa000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0xa000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0xa800 0x00 0x00 0x01 0x8003 0x02 0x01 0xa800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0xa800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0xa800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0xb000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0xb000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0xb000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0xb000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0xb800 0x00 0x00 0x01 0x8003 0x04 0x01 0xb800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0xb800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0xb800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0xc000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0xc000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0xc000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0xc000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0xc800 0x00 0x00 0x01 0x8003 0x02 0x01 0xc800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0xc800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0xc800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0xd000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0xd000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0xd000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0xd000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0xd800 0x00 0x00 0x01 0x8003 0x04 0x01 0xd800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0xd800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0xd800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0xe000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0xe000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0xe000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0xe000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0xe800 0x00 0x00 0x01 0x8003 0x02 0x01 0xe800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0xe800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0xe800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0xf000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0xf000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0xf000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0xf000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0xf800 0x00 0x00 0x01 0x8003 0x04 0x01 0xf800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0xf800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0xf800 0x00 0x00
+ 0x04 0x8003 0x03 0x01>;
+ interrupt-map-mask = <0xf800 0x00 0x00 0x07>;
+ device_type = "pci";
+ compatible = "fsl,mpc8540-pci";
+ cell-index = <0x00>;
+ };
+
+ soc@fe0000000 {
+ bus-frequency = <0x00>;
+ ranges = <0x00 0x0f 0xe0000000 0x100000>;
+ #size-cells = <0x01>;
+ #address-cells = <0x01>;
+ compatible = "fsl,mpc8544-immr\0simple-bus";
+ device_type = "soc";
+
+ power-off {
+ gpios = <0x8005 0x00 0x00>;
+ compatible = "gpio-poweroff";
+ };
+
+ gpio@ff000 {
+ linux,phandle = <0x8005>;
+ phandle = <0x8005>;
+ gpio-controller;
+ #gpio-cells = <0x02>;
+ interrupt-parent = <0x8003>;
+ interrupts = <0x2f 0x02>;
+ reg = <0xff000 0x1000>;
+ compatible = "fsl,qoriq-gpio";
+ };
+
+ msi@41600 {
+ linux,phandle = <0x8004>;
+ phandle = <0x8004>;
+ interrupts = <0xe0 0x00 0xe1 0x00 0xe2 0x00 0xe3 0x00
+ 0xe4 0x00 0xe5 0x00 0xe6 0x00 0xe7 0x00>;
+ interrupt-parent = <0x8003>;
+ msi-available-ranges = <0x00 0x100>;
+ reg = <0x41600 0x200>;
+ compatible = "fsl,mpic-msi";
+ };
+
+ global-utilities@e0000 {
+ fsl,has-rstcr;
+ reg = <0xe0000 0x1000>;
+ compatible = "fsl,mpc8544-guts";
+ };
+
+ i2c@3000 {
+ interrupt-parent = <0x8003>;
+ interrupts = <0x2b 0x02>;
+ cell-index = <0x00>;
+ reg = <0x3000 0x14>;
+ compatible = "fsl-i2c";
+ device_type = "i2c";
+
+ rtc@68 {
+ reg = <0x68>;
+ compatible = "pericom,pt7c4338";
+ };
+ };
+
+ serial@4500 {
+ interrupt-parent = <0x8003>;
+ interrupts = <0x2a 0x02>;
+ clock-frequency = <0x17d78400>;
+ cell-index = <0x00>;
+ reg = <0x4500 0x100>;
+ compatible = "ns16550";
+ device_type = "serial";
+ };
+
+ pic@40000 {
+ interrupt-controller;
+ linux,phandle = <0x8003>;
+ phandle = <0x8003>;
+ #interrupt-cells = <0x02>;
+ #address-cells = <0x00>;
+ reg = <0x40000 0x40000>;
+ compatible = "fsl,mpic";
+ device_type = "open-pic";
+ };
+ };
+
+ aliases {
+ pci0 = "/pci@fe0008000";
+ rtc = "i2c/rtc@68";
+ i2c = "/soc@fe0000000/i2c@3000";
+ serial0 = "/soc@fe0000000/serial@4500";
+ };
+
+ cpus {
+ #size-cells = <0x00>;
+ #address-cells = <0x01>;
+
+ PowerPC,8544@0 {
+ status = "okay";
+ bus-frequency = <0x00>;
+ i-cache-size = <0x8000>;
+ d-cache-size = <0x8000>;
+ i-cache-line-size = <0x20>;
+ d-cache-line-size = <0x20>;
+ reg = <0x00>;
+ device_type = "cpu";
+ timebase-frequency = <0x17d78400>;
+ clock-frequency = <0x17d78400>;
+ };
+ };
+
+ chosen {
+ stdout-path = "/soc@fe0000000/serial@4500";
+ linux,stdout-path = "/soc@fe0000000/serial@4500";
+ bootargs = [00];
+ };
+
+ memory {
+ reg = <0x00 0x00 0x00 0x8000000>;
+ device_type = "memory";
+ };
+};
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index 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
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 15/26] arm: highbank: Add a fake devicetree file
2021-10-26 0:23 ` Simon Glass
` (14 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Albert Aribaud, Andre Przywara
Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.
Unfortunately there are no build instructions in the U-Boot tree to enable
a real file to be created.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/dts/Makefile | 2 ++
arch/arm/dts/highbank.dts | 14 ++++++++++++++
configs/highbank_defconfig | 2 +-
3 files changed, 17 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/highbank.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 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
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 16/26] fdt: Make OF_BOARD a bool option
2021-10-26 0:23 ` Simon Glass
` (15 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Jerry Van Baren
This should not be a separate option from OF_SEPARATE. It is a run-time
option to override the devicetree, even if present.
Move the option out of the choice.
Disable BINMAN_FDT for a few boards which don't actually use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
configs/qemu-ppce500_defconfig | 1 +
configs/qemu-riscv32_spl_defconfig | 2 ++
configs/qemu-riscv64_spl_defconfig | 1 +
dts/Kconfig | 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"
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 17/26] Drop CONFIG_BINMAN_STANDALONE_FDT
2021-10-26 0:23 ` Simon Glass
` (16 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass
This was added as a hack to work around not having an in-tree devicetree.
Now that this is fixed it is not needed.
Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
Makefile | 3 +--
dts/Kconfig | 18 ------------------
tools/binman/binman.rst | 20 --------------------
3 files changed, 1 insertion(+), 40 deletions(-)
diff --git a/Makefile b/Makefile
index 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)
----------------------------------------------------
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 18/26] doc: Update info on devicetree update
2021-10-26 0:23 ` Simon Glass
` (17 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass
Since OF_BOARD has been corrected to be a run-time option, we can drop
the historical info from this documentation.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
doc/develop/devicetree/dt_update.rst | 74 +++-------------------------
1 file changed, 8 insertions(+), 66 deletions(-)
diff --git a/doc/develop/devicetree/dt_update.rst b/doc/develop/devicetree/dt_update.rst
index 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-deymo@google.com/
.. _`TF-A`: https://www.trustedfirmware.org/projects/tf-a
.. _`QEMU ARM`: https://github.com/qemu/qemu/blob/master/hw/arm/virt.c
.. _`QEMU RISC-V`: https://github.com/qemu/qemu/blob/master/hw/riscv/virt.c
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 19/26] fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup()
2021-10-26 0:23 ` Simon Glass
` (18 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
2021-10-29 5:49 ` Ilias Apalodimas
-1 siblings, 1 reply; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Jerry Van Baren
This logic is a bit convoluted for one function. Move the mulit-FIT part
into its own function.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(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
^ permalink raw reply related [flat|nested] 144+ messages in thread* Re: [PATCH v5 19/26] fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup()
2021-10-26 0:23 ` [PATCH v5 19/26] fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() Simon Glass
@ 2021-10-29 5:49 ` Ilias Apalodimas
0 siblings, 0 replies; 144+ messages in thread
From: Ilias Apalodimas @ 2021-10-29 5:49 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Heinrich Schuchardt,
Tom Rini, Sean Anderson, Jerry Van Baren
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>
^ permalink raw reply [flat|nested] 144+ messages in thread
* [PATCH v5 20/26] fdt: Drop #ifdefs with MULTI_DTB_FIT
2021-10-26 0:23 ` Simon Glass
` (19 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
2021-10-29 5:55 ` Ilias Apalodimas
-1 siblings, 1 reply; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Jerry Van Baren
Refactor the code to drop the #ifdefs for this feature.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
dts/Kconfig | 1 -
include/asm-generic/global_data.h | 8 ++++++++
lib/fdtdec.c | 31 +++++++++++--------------------
3 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/dts/Kconfig b/dts/Kconfig
index 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,
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* Re: [PATCH v5 20/26] fdt: Drop #ifdefs with MULTI_DTB_FIT
2021-10-26 0:23 ` [PATCH v5 20/26] fdt: Drop #ifdefs with MULTI_DTB_FIT Simon Glass
@ 2021-10-29 5:55 ` Ilias Apalodimas
0 siblings, 0 replies; 144+ messages in thread
From: Ilias Apalodimas @ 2021-10-29 5:55 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Heinrich Schuchardt,
Tom Rini, Sean Anderson, Jerry Van Baren
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);
> 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,
> --
> 2.33.0.1079.g6e70778dc9-goog
>
^ permalink raw reply [flat|nested] 144+ messages in thread
* [PATCH v5 21/26] fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup()
2021-10-26 0:23 ` Simon Glass
` (20 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Jerry Van Baren
Move this to the header file to clean up the C code.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
include/fdtdec.h | 14 ++++++++++++++
lib/fdtdec.c | 6 +-----
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 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();
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 22/26] fdt: Drop #ifdef around board_fdt_blob_setup()
2021-10-26 0:23 ` Simon Glass
` (21 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Jerry Van Baren
This serves no purpose. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
lib/fdtdec.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 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)
{
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 25/26] fdt: Drop remaining preprocessor macros in fdtdec_setup()
2021-10-26 0:23 ` Simon Glass
` (22 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Jerry Van Baren
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,
--
2.33.0.1079.g6e70778dc9-goog
^ permalink raw reply related [flat|nested] 144+ messages in thread* [PATCH v5 26/26] fdt: Don't call board_fdt_blob_setup() without OF_BOARD
2021-10-26 0:23 ` Simon Glass
` (23 preceding siblings ...)
(?)
@ 2021-10-26 0:23 ` Simon Glass
2021-10-26 13:55 ` Ilias Apalodimas
-1 siblings, 1 reply; 144+ messages in thread
From: Simon Glass @ 2021-10-26 0:23 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Mark Kettenis, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
Sean Anderson, Simon Glass, Jerry Van Baren
At present this override function is called even when OF_BOARD Is not
enabled. This makes it impossible to disable this feature and in fact
makes the OF_BOARD option useless.
Reinstate its intended purpose, so that it is possible to switch between
the appended devicetree and one provided by the board's custom function.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
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
^ permalink raw reply related [flat|nested] 144+ messages in thread* Re: [PATCH v5 26/26] fdt: Don't call board_fdt_blob_setup() without OF_BOARD
2021-10-26 0:23 ` [PATCH v5 26/26] fdt: Don't call board_fdt_blob_setup() without OF_BOARD Simon Glass
@ 2021-10-26 13:55 ` Ilias Apalodimas
2021-10-26 15:27 ` Simon Glass
0 siblings, 1 reply; 144+ messages in thread
From: Ilias Apalodimas @ 2021-10-26 13:55 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Heinrich Schuchardt,
Tom Rini, Sean Anderson, Jerry Van Baren
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
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH v5 26/26] fdt: Don't call board_fdt_blob_setup() without OF_BOARD
2021-10-26 13:55 ` Ilias Apalodimas
@ 2021-10-26 15:27 ` Simon Glass
2021-10-27 7:17 ` Ilias Apalodimas
0 siblings, 1 reply; 144+ messages in thread
From: Simon Glass @ 2021-10-26 15:27 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: U-Boot Mailing List, Mark Kettenis, Heinrich Schuchardt,
Tom Rini, Sean Anderson, Jerry Van Baren
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
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH v5 26/26] fdt: Don't call board_fdt_blob_setup() without OF_BOARD
2021-10-26 15:27 ` Simon Glass
@ 2021-10-27 7:17 ` Ilias Apalodimas
2021-10-27 19:12 ` Tom Rini
0 siblings, 1 reply; 144+ messages in thread
From: Ilias Apalodimas @ 2021-10-27 7:17 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Heinrich Schuchardt,
Tom Rini, Sean Anderson, Jerry Van Baren
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
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH v5 26/26] fdt: Don't call board_fdt_blob_setup() without OF_BOARD
2021-10-27 7:17 ` Ilias Apalodimas
@ 2021-10-27 19:12 ` Tom Rini
2021-10-27 21:33 ` François Ozog
0 siblings, 1 reply; 144+ messages in thread
From: Tom Rini @ 2021-10-27 19:12 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Simon Glass, U-Boot Mailing List, Mark Kettenis,
Heinrich Schuchardt, Sean Anderson, Jerry Van Baren
[-- Attachment #1: Type: text/plain, Size: 1930 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH v5 26/26] fdt: Don't call board_fdt_blob_setup() without OF_BOARD
2021-10-27 19:12 ` Tom Rini
@ 2021-10-27 21:33 ` François Ozog
2021-10-27 21:44 ` Tom Rini
0 siblings, 1 reply; 144+ messages in thread
From: François Ozog @ 2021-10-27 21:33 UTC (permalink / raw)
To: Tom Rini
Cc: Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Mark Kettenis, Sean Anderson, Simon Glass, U-Boot Mailing List
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
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH v5 26/26] fdt: Don't call board_fdt_blob_setup() without OF_BOARD
2021-10-27 21:33 ` François Ozog
@ 2021-10-27 21:44 ` Tom Rini
0 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-10-27 21:44 UTC (permalink / raw)
To: François Ozog
Cc: Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Mark Kettenis, Sean Anderson, Simon Glass, U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 3271 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-26 0:23 ` Simon Glass
@ 2021-10-26 6:07 ` François Ozog
-1 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-10-26 6:07 UTC (permalink / raw)
To: Simon Glass
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Sean Anderson, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tom Rini, Tuomas Tynkkynen,
U-Boot Mailing List, qemu-devel
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-sjg@chromium.org/
>
> 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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-10-26 6:07 ` François Ozog
0 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-10-26 6:07 UTC (permalink / raw)
To: Simon Glass
Cc: Linus Walleij, Thomas Fitzsimmons, qemu-devel, Sean Anderson,
U-Boot Mailing List, Mark Kettenis, Tom Rini, Stephen Warren,
Oleksandr Andrushchenko, Heinrich Schuchardt, Michal Simek,
Jerry Van Baren, Stephen Warren, Andre Przywara, Alexander Graf,
Anastasiia Lukianenko, Albert Aribaud, Matthias Brugger,
Ilias Apalodimas, Aaron Williams, Tuomas Tynkkynen, Bin Meng
[-- Attachment #1: Type: text/plain, Size: 9235 bytes --]
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-sjg@chromium.org/
>
> 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
[-- Attachment #2: Type: text/html, Size: 12305 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-26 6:07 ` François Ozog
@ 2021-10-27 14:08 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-27 14:08 UTC (permalink / raw)
To: François Ozog
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Sean Anderson, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tom Rini, Tuomas Tynkkynen,
U-Boot Mailing List, QEMU Developers
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-sjg@chromium.org/
>>
>> 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
>
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 14:08 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-27 14:08 UTC (permalink / raw)
To: François Ozog
Cc: Linus Walleij, Thomas Fitzsimmons, QEMU Developers,
Sean Anderson, U-Boot Mailing List, Mark Kettenis, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Michal Simek, Jerry Van Baren, Stephen Warren, Andre Przywara,
Alexander Graf, Anastasiia Lukianenko, Albert Aribaud,
Matthias Brugger, Ilias Apalodimas, Aaron Williams,
Tuomas Tynkkynen, Bin Meng
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-sjg@chromium.org/
>>
>> 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
>
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-27 14:08 ` Simon Glass
@ 2021-10-27 15:14 ` François Ozog
-1 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-10-27 15:14 UTC (permalink / raw)
To: Simon Glass
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Sean Anderson, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tom Rini, Tuomas Tynkkynen,
U-Boot Mailing List, QEMU Developers
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-sjg@chromium.org/
> >>
> >> 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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 15:14 ` François Ozog
0 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-10-27 15:14 UTC (permalink / raw)
To: Simon Glass
Cc: Linus Walleij, Thomas Fitzsimmons, QEMU Developers,
Sean Anderson, U-Boot Mailing List, Mark Kettenis, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Michal Simek, Jerry Van Baren, Stephen Warren, Andre Przywara,
Alexander Graf, Anastasiia Lukianenko, Albert Aribaud,
Matthias Brugger, Ilias Apalodimas, Aaron Williams,
Tuomas Tynkkynen, Bin Meng
[-- Attachment #1: Type: text/plain, Size: 11617 bytes --]
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-sjg@chromium.org/
> >>
> >> 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
[-- Attachment #2: Type: text/html, Size: 16603 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-27 15:14 ` François Ozog
@ 2021-10-27 18:23 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-27 18:23 UTC (permalink / raw)
To: François Ozog
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Sean Anderson, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tom Rini, Tuomas Tynkkynen,
U-Boot Mailing List, QEMU Developers
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-sjg@chromium.org/
>> >>
>> >> 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
>
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 18:23 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-10-27 18:23 UTC (permalink / raw)
To: François Ozog
Cc: Linus Walleij, Thomas Fitzsimmons, QEMU Developers,
Sean Anderson, U-Boot Mailing List, Mark Kettenis, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Michal Simek, Jerry Van Baren, Stephen Warren, Andre Przywara,
Alexander Graf, Anastasiia Lukianenko, Albert Aribaud,
Matthias Brugger, Ilias Apalodimas, Aaron Williams,
Tuomas Tynkkynen, Bin Meng
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-sjg@chromium.org/
>> >>
>> >> 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
>
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-27 18:23 ` Simon Glass
@ 2021-10-27 19:25 ` Tom Rini
-1 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-10-27 19:25 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Sean Anderson, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen,
U-Boot Mailing List, QEMU Developers
[-- Attachment #1: Type: text/plain, Size: 3228 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 19:25 ` Tom Rini
0 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-10-27 19:25 UTC (permalink / raw)
To: Simon Glass
Cc: Linus Walleij, Thomas Fitzsimmons, QEMU Developers,
Sean Anderson, U-Boot Mailing List, Mark Kettenis,
François Ozog, Stephen Warren, Oleksandr Andrushchenko,
Heinrich Schuchardt, Michal Simek, Jerry Van Baren,
Stephen Warren, Andre Przywara, Alexander Graf,
Anastasiia Lukianenko, Albert Aribaud, Matthias Brugger,
Ilias Apalodimas, Aaron Williams, Tuomas Tynkkynen, Bin Meng
[-- Attachment #1: Type: text/plain, Size: 3228 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-27 19:25 ` Tom Rini
@ 2021-11-03 16:45 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-03 16:45 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Sean Anderson, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen,
U-Boot Mailing List, QEMU Developers
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-11-03 16:45 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-03 16:45 UTC (permalink / raw)
To: Tom Rini
Cc: Linus Walleij, Thomas Fitzsimmons, QEMU Developers,
Sean Anderson, U-Boot Mailing List, Mark Kettenis,
François Ozog, Stephen Warren, Oleksandr Andrushchenko,
Heinrich Schuchardt, Michal Simek, Jerry Van Baren,
Stephen Warren, Andre Przywara, Alexander Graf,
Anastasiia Lukianenko, Albert Aribaud, Matthias Brugger,
Ilias Apalodimas, Aaron Williams, Tuomas Tynkkynen, Bin Meng
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-11-03 16:45 ` Simon Glass
@ 2021-11-03 17:21 ` Tom Rini
-1 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-03 17:21 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Sean Anderson, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen,
U-Boot Mailing List, QEMU Developers
[-- Attachment #1: Type: text/plain, Size: 4778 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-11-03 17:21 ` Tom Rini
0 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-03 17:21 UTC (permalink / raw)
To: Simon Glass
Cc: Linus Walleij, Thomas Fitzsimmons, QEMU Developers,
Sean Anderson, U-Boot Mailing List, Mark Kettenis,
François Ozog, Stephen Warren, Oleksandr Andrushchenko,
Heinrich Schuchardt, Michal Simek, Jerry Van Baren,
Stephen Warren, Andre Przywara, Alexander Graf,
Anastasiia Lukianenko, Albert Aribaud, Matthias Brugger,
Ilias Apalodimas, Aaron Williams, Tuomas Tynkkynen, Bin Meng
[-- Attachment #1: Type: text/plain, Size: 4778 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-27 18:23 ` Simon Glass
@ 2021-10-27 20:07 ` François Ozog
-1 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-10-27 20:07 UTC (permalink / raw)
To: Simon Glass
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, QEMU Developers, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons, Tom Rini,
Tuomas Tynkkynen, U-Boot Mailing List
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-sjg@chromium.org/
> >> >>
> >> >> 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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 20:07 ` François Ozog
0 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-10-27 20:07 UTC (permalink / raw)
To: Simon Glass
Cc: Linus Walleij, Thomas Fitzsimmons, QEMU Developers,
Sean Anderson, U-Boot Mailing List, Mark Kettenis, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Michal Simek, Jerry Van Baren, Stephen Warren, Andre Przywara,
Alexander Graf, Anastasiia Lukianenko, Albert Aribaud,
Matthias Brugger, Ilias Apalodimas, Aaron Williams,
Tuomas Tynkkynen, Bin Meng
[-- Attachment #1: Type: text/plain, Size: 15074 bytes --]
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-sjg@chromium.org/
> >> >>
> >> >> 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
[-- Attachment #2: Type: text/html, Size: 21585 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-27 20:07 ` François Ozog
@ 2021-11-03 1:20 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-03 1:20 UTC (permalink / raw)
To: François Ozog
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, QEMU Developers, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons, Tom Rini,
Tuomas Tynkkynen, U-Boot Mailing List
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-sjg@chromium.org/
>> >> >>
>> >> >> 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
>
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-11-03 1:20 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-03 1:20 UTC (permalink / raw)
To: François Ozog
Cc: Linus Walleij, Thomas Fitzsimmons, QEMU Developers,
Sean Anderson, U-Boot Mailing List, Mark Kettenis, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Michal Simek, Jerry Van Baren, Stephen Warren, Andre Przywara,
Alexander Graf, Anastasiia Lukianenko, Albert Aribaud,
Matthias Brugger, Ilias Apalodimas, Aaron Williams,
Tuomas Tynkkynen, Bin Meng
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-sjg@chromium.org/
>> >> >>
>> >> >> 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
>
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-11-03 1:20 ` Simon Glass
@ 2021-11-03 4:45 ` François Ozog
-1 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-11-03 4:45 UTC (permalink / raw)
To: Simon Glass
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, QEMU Developers, Sean Anderson,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons, Tom Rini,
Tuomas Tynkkynen, U-Boot Mailing List
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-sjg@chromium.org/
> >> >> >>
> >> >> >> 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
> >
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-11-03 4:45 ` François Ozog
0 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-11-03 4:45 UTC (permalink / raw)
To: Simon Glass
Cc: Linus Walleij, Thomas Fitzsimmons, QEMU Developers,
Sean Anderson, U-Boot Mailing List, Mark Kettenis, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Michal Simek, Jerry Van Baren, Stephen Warren, Andre Przywara,
Alexander Graf, Anastasiia Lukianenko, Albert Aribaud,
Matthias Brugger, Ilias Apalodimas, Aaron Williams,
Tuomas Tynkkynen, Bin Meng
[-- Attachment #1: Type: text/plain, Size: 17743 bytes --]
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-sjg@chromium.org/
> >> >> >>
> >> >> >> 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
> >
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 25852 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-27 18:23 ` Simon Glass
@ 2021-10-27 22:30 ` Mark Kettenis
-1 siblings, 0 replies; 144+ messages in thread
From: Mark Kettenis @ 2021-10-27 22:30 UTC (permalink / raw)
To: Simon Glass
Cc: francois.ozog, awilliams, albert.u.boot, agraf,
anastasiia_lukianenko, andre.przywara, bmeng.cn, xypron.glpk,
ilias.apalodimas, vanbaren, linus.walleij, mbrugger,
michal.simek, oleksandr_andrushchenko, seanga2, swarren, swarren,
fitzsim, trini, tuomas.tynkkynen, u-boot, qemu-devel
> 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 ;).
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 22:30 ` Mark Kettenis
0 siblings, 0 replies; 144+ messages in thread
From: Mark Kettenis @ 2021-10-27 22:30 UTC (permalink / raw)
To: Simon Glass
Cc: linus.walleij, fitzsim, qemu-devel, seanga2, u-boot,
francois.ozog, swarren, oleksandr_andrushchenko, xypron.glpk,
michal.simek, vanbaren, swarren, andre.przywara, agraf,
anastasiia_lukianenko, albert.u.boot, mbrugger, ilias.apalodimas,
awilliams, tuomas.tynkkynen, bmeng.cn, trini
> 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 ;).
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-27 22:30 ` Mark Kettenis
@ 2021-11-03 1:20 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-03 1:20 UTC (permalink / raw)
To: Mark Kettenis
Cc: francois.ozog, awilliams, albert.u.boot, agraf,
Anastasiia_Lukianenko, andre.przywara, bmeng.cn, xypron.glpk,
ilias.apalodimas, vanbaren, linus.walleij, mbrugger,
michal.simek, Oleksandr_Andrushchenko, seanga2, swarren, swarren,
fitzsim, trini, tuomas.tynkkynen, u-boot, qemu-devel
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-11-03 1:20 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-03 1:20 UTC (permalink / raw)
To: Mark Kettenis
Cc: linus.walleij, fitzsim, qemu-devel, seanga2, u-boot,
francois.ozog, swarren, Oleksandr_Andrushchenko, xypron.glpk,
michal.simek, vanbaren, swarren, andre.przywara, agraf,
Anastasiia_Lukianenko, albert.u.boot, mbrugger, ilias.apalodimas,
awilliams, tuomas.tynkkynen, bmeng.cn, trini
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-11-03 1:20 ` Simon Glass
@ 2021-11-03 8:22 ` Mark Kettenis
-1 siblings, 0 replies; 144+ messages in thread
From: Mark Kettenis @ 2021-11-03 8:22 UTC (permalink / raw)
To: Simon Glass
Cc: francois.ozog, awilliams, albert.u.boot, agraf,
Anastasiia_Lukianenko, andre.przywara, bmeng.cn, xypron.glpk,
ilias.apalodimas, vanbaren, linus.walleij, mbrugger,
michal.simek, Oleksandr_Andrushchenko, seanga2, swarren, swarren,
fitzsim, trini, tuomas.tynkkynen, u-boot, qemu-devel
> 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.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-11-03 8:22 ` Mark Kettenis
0 siblings, 0 replies; 144+ messages in thread
From: Mark Kettenis @ 2021-11-03 8:22 UTC (permalink / raw)
To: Simon Glass
Cc: linus.walleij, fitzsim, qemu-devel, seanga2, u-boot,
francois.ozog, swarren, Oleksandr_Andrushchenko, xypron.glpk,
michal.simek, vanbaren, swarren, andre.przywara, agraf,
Anastasiia_Lukianenko, albert.u.boot, mbrugger, ilias.apalodimas,
awilliams, tuomas.tynkkynen, bmeng.cn, trini
> 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.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-11-03 8:22 ` Mark Kettenis
@ 2021-11-03 16:02 ` Tom Rini
-1 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-03 16:02 UTC (permalink / raw)
To: Mark Kettenis
Cc: Simon Glass, francois.ozog, awilliams, albert.u.boot, agraf,
Anastasiia_Lukianenko, andre.przywara, bmeng.cn, xypron.glpk,
ilias.apalodimas, vanbaren, linus.walleij, mbrugger,
michal.simek, Oleksandr_Andrushchenko, seanga2, swarren, swarren,
fitzsim, tuomas.tynkkynen, u-boot, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 5420 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-11-03 16:02 ` Tom Rini
0 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-03 16:02 UTC (permalink / raw)
To: Mark Kettenis
Cc: linus.walleij, fitzsim, qemu-devel, seanga2, u-boot,
francois.ozog, swarren, Oleksandr_Andrushchenko, xypron.glpk,
michal.simek, vanbaren, swarren, andre.przywara, agraf,
Anastasiia_Lukianenko, albert.u.boot, mbrugger, Simon Glass,
ilias.apalodimas, awilliams, tuomas.tynkkynen, bmeng.cn
[-- Attachment #1: Type: text/plain, Size: 5420 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-11-03 16:02 ` Tom Rini
@ 2021-11-03 16:45 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-03 16:45 UTC (permalink / raw)
To: Tom Rini
Cc: Mark Kettenis, francois.ozog, awilliams, albert.u.boot, agraf,
Anastasiia_Lukianenko, andre.przywara, bmeng.cn, xypron.glpk,
ilias.apalodimas, vanbaren, linus.walleij, mbrugger,
michal.simek, Oleksandr_Andrushchenko, seanga2, swarren, swarren,
fitzsim, tuomas.tynkkynen, u-boot, qemu-devel
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-11-03 16:45 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-03 16:45 UTC (permalink / raw)
To: Tom Rini
Cc: linus.walleij, fitzsim, qemu-devel, seanga2, u-boot,
Mark Kettenis, francois.ozog, swarren, Oleksandr_Andrushchenko,
xypron.glpk, michal.simek, vanbaren, swarren, andre.przywara,
agraf, Anastasiia_Lukianenko, albert.u.boot, mbrugger,
ilias.apalodimas, awilliams, tuomas.tynkkynen, bmeng.cn
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-11-03 16:45 ` Simon Glass
@ 2021-11-03 17:36 ` Mark Kettenis
-1 siblings, 0 replies; 144+ messages in thread
From: Mark Kettenis @ 2021-11-03 17:36 UTC (permalink / raw)
To: Simon Glass
Cc: trini, francois.ozog, awilliams, albert.u.boot, agraf,
Anastasiia_Lukianenko, andre.przywara, bmeng.cn, xypron.glpk,
ilias.apalodimas, vanbaren, linus.walleij, mbrugger,
michal.simek, Oleksandr_Andrushchenko, seanga2, swarren, swarren,
fitzsim, tuomas.tynkkynen, u-boot, qemu-devel
> 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.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-11-03 17:36 ` Mark Kettenis
0 siblings, 0 replies; 144+ messages in thread
From: Mark Kettenis @ 2021-11-03 17:36 UTC (permalink / raw)
To: Simon Glass
Cc: linus.walleij, fitzsim, qemu-devel, seanga2, francois.ozog,
trini, swarren, Oleksandr_Andrushchenko, xypron.glpk,
michal.simek, vanbaren, swarren, andre.przywara, agraf,
Anastasiia_Lukianenko, albert.u.boot, mbrugger, u-boot,
ilias.apalodimas, awilliams, tuomas.tynkkynen, bmeng.cn
> 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.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-11-03 1:20 ` Simon Glass
@ 2021-11-03 15:56 ` Tom Rini
-1 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-03 15:56 UTC (permalink / raw)
To: Simon Glass
Cc: Mark Kettenis, francois.ozog, awilliams, albert.u.boot, agraf,
Anastasiia_Lukianenko, andre.przywara, bmeng.cn, xypron.glpk,
ilias.apalodimas, vanbaren, linus.walleij, mbrugger,
michal.simek, Oleksandr_Andrushchenko, seanga2, swarren, swarren,
fitzsim, tuomas.tynkkynen, u-boot, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 2780 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-11-03 15:56 ` Tom Rini
0 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-11-03 15:56 UTC (permalink / raw)
To: Simon Glass
Cc: linus.walleij, fitzsim, qemu-devel, seanga2, u-boot,
Mark Kettenis, francois.ozog, swarren, Oleksandr_Andrushchenko,
xypron.glpk, michal.simek, vanbaren, swarren, andre.przywara,
agraf, Anastasiia_Lukianenko, albert.u.boot, mbrugger,
ilias.apalodimas, awilliams, tuomas.tynkkynen, bmeng.cn
[-- Attachment #1: Type: text/plain, Size: 2780 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-11-03 15:56 ` Tom Rini
@ 2021-11-03 16:45 ` Simon Glass
-1 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-03 16:45 UTC (permalink / raw)
To: Tom Rini
Cc: Mark Kettenis, francois.ozog, awilliams, albert.u.boot, agraf,
Anastasiia_Lukianenko, andre.przywara, bmeng.cn, xypron.glpk,
ilias.apalodimas, vanbaren, linus.walleij, mbrugger,
michal.simek, Oleksandr_Andrushchenko, seanga2, swarren, swarren,
fitzsim, tuomas.tynkkynen, u-boot, qemu-devel
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-11-03 16:45 ` Simon Glass
0 siblings, 0 replies; 144+ messages in thread
From: Simon Glass @ 2021-11-03 16:45 UTC (permalink / raw)
To: Tom Rini
Cc: linus.walleij, fitzsim, qemu-devel, seanga2, u-boot,
Mark Kettenis, francois.ozog, swarren, Oleksandr_Andrushchenko,
xypron.glpk, michal.simek, vanbaren, swarren, andre.przywara,
agraf, Anastasiia_Lukianenko, albert.u.boot, mbrugger,
ilias.apalodimas, awilliams, tuomas.tynkkynen, bmeng.cn
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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-27 14:08 ` Simon Glass
@ 2021-10-27 15:36 ` Tuomas Tynkkynen
-1 siblings, 0 replies; 144+ messages in thread
From: Tuomas Tynkkynen @ 2021-10-27 15:36 UTC (permalink / raw)
To: Simon Glass, François Ozog
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Sean Anderson, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tom Rini,
U-Boot Mailing List, QEMU Developers
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.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 15:36 ` Tuomas Tynkkynen
0 siblings, 0 replies; 144+ messages in thread
From: Tuomas Tynkkynen @ 2021-10-27 15:36 UTC (permalink / raw)
To: Simon Glass, François Ozog
Cc: Anastasiia Lukianenko, Albert Aribaud, QEMU Developers,
Matthias Brugger, Stephen Warren, Stephen Warren,
Oleksandr Andrushchenko, Thomas Fitzsimmons, Andre Przywara,
Linus Walleij, Ilias Apalodimas, Michal Simek, Sean Anderson,
Aaron Williams, U-Boot Mailing List, Jerry Van Baren,
Alexander Graf, Heinrich Schuchardt, Bin Meng, Tom Rini,
Mark Kettenis
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.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-27 15:36 ` Tuomas Tynkkynen
@ 2021-10-27 19:13 ` Tom Rini
-1 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-10-27 19:13 UTC (permalink / raw)
To: Tuomas Tynkkynen
Cc: Simon Glass, François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Sean Anderson, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, U-Boot Mailing List,
QEMU Developers
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 19:13 ` Tom Rini
0 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-10-27 19:13 UTC (permalink / raw)
To: Tuomas Tynkkynen
Cc: Linus Walleij, Thomas Fitzsimmons, QEMU Developers,
Sean Anderson, U-Boot Mailing List, Mark Kettenis,
François Ozog, Stephen Warren, Oleksandr Andrushchenko,
Heinrich Schuchardt, Michal Simek, Jerry Van Baren,
Stephen Warren, Andre Przywara, Alexander Graf,
Anastasiia Lukianenko, Albert Aribaud, Matthias Brugger,
Simon Glass, Ilias Apalodimas, Aaron Williams, Bin Meng
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-27 14:08 ` Simon Glass
@ 2021-10-27 18:16 ` Tom Rini
-1 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-10-27 18:16 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Sean Anderson, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen,
U-Boot Mailing List, QEMU Developers
[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 18:16 ` Tom Rini
0 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-10-27 18:16 UTC (permalink / raw)
To: Simon Glass
Cc: Linus Walleij, Thomas Fitzsimmons, QEMU Developers,
Sean Anderson, U-Boot Mailing List, Mark Kettenis,
François Ozog, Stephen Warren, Oleksandr Andrushchenko,
Heinrich Schuchardt, Michal Simek, Jerry Van Baren,
Stephen Warren, Andre Przywara, Alexander Graf,
Anastasiia Lukianenko, Albert Aribaud, Matthias Brugger,
Ilias Apalodimas, Aaron Williams, Tuomas Tynkkynen, Bin Meng
[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-27 14:08 ` Simon Glass
@ 2021-10-27 18:24 ` Tom Rini
-1 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-10-27 18:24 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Heinrich Schuchardt, Ilias Apalodimas, Jerry Van Baren,
Linus Walleij, Mark Kettenis, Matthias Brugger, Michal Simek,
Oleksandr Andrushchenko, Sean Anderson, Stephen Warren,
Stephen Warren, Thomas Fitzsimmons, Tuomas Tynkkynen,
U-Boot Mailing List, QEMU Developers
[-- Attachment #1: Type: text/plain, Size: 606 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 18:24 ` Tom Rini
0 siblings, 0 replies; 144+ messages in thread
From: Tom Rini @ 2021-10-27 18:24 UTC (permalink / raw)
To: Simon Glass
Cc: Linus Walleij, Thomas Fitzsimmons, QEMU Developers,
Sean Anderson, U-Boot Mailing List, Mark Kettenis,
François Ozog, Stephen Warren, Oleksandr Andrushchenko,
Heinrich Schuchardt, Michal Simek, Jerry Van Baren,
Stephen Warren, Andre Przywara, Alexander Graf,
Anastasiia Lukianenko, Albert Aribaud, Matthias Brugger,
Ilias Apalodimas, Aaron Williams, Tuomas Tynkkynen, Bin Meng
[-- Attachment #1: Type: text/plain, Size: 606 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-26 0:23 ` Simon Glass
@ 2021-11-03 17:13 ` François Ozog
-1 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-11-03 17:13 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Mark Kettenis, Heinrich Schuchardt,
Ilias Apalodimas, Tom Rini, Sean Anderson, Aaron Williams,
Albert Aribaud, Alexander Graf, Anastasiia Lukianenko,
Andre Przywara, Bin Meng, Jerry Van Baren, Linus Walleij,
Matthias Brugger, Michal Simek, Oleksandr Andrushchenko,
Stephen Warren, Stephen Warren, Thomas Fitzsimmons,
Tuomas Tynkkynen, qemu-devel
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-sjg@chromium.org/
>
> 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
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-11-03 17:13 ` François Ozog
0 siblings, 0 replies; 144+ messages in thread
From: François Ozog @ 2021-11-03 17:13 UTC (permalink / raw)
To: Simon Glass
Cc: Linus Walleij, Thomas Fitzsimmons, qemu-devel, Sean Anderson,
U-Boot Mailing List, Mark Kettenis, Tom Rini, Stephen Warren,
Oleksandr Andrushchenko, Heinrich Schuchardt, Michal Simek,
Jerry Van Baren, Stephen Warren, Andre Przywara, Alexander Graf,
Anastasiia Lukianenko, Albert Aribaud, Matthias Brugger,
Ilias Apalodimas, Aaron Williams, Tuomas Tynkkynen, Bin Meng
[-- Attachment #1: Type: text/plain, Size: 9964 bytes --]
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-sjg@chromium.org/
>
> 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
[-- Attachment #2: Type: text/html, Size: 14172 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread