* [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
@ 2021-10-26 0:23 Simon Glass
2021-10-26 0:23 ` [PATCH v5 03/26] arm: qemu: Mention -nographic in the docs Simon Glass
` (6 more replies)
0 siblings, 7 replies; 48+ 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] 48+ messages in thread
* [PATCH v5 03/26] arm: qemu: Mention -nographic in the docs
2021-10-26 0:23 [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option Simon Glass
@ 2021-10-26 0:23 ` Simon Glass
2021-10-26 0:23 ` [PATCH v5 04/26] arm: riscv: qemu: Explain how to extract the generated dt Simon Glass
` (5 subsequent siblings)
6 siblings, 0 replies; 48+ 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] 48+ messages in thread
* [PATCH v5 04/26] arm: riscv: qemu: Explain how to extract the generated dt
2021-10-26 0:23 [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option Simon Glass
2021-10-26 0:23 ` [PATCH v5 03/26] arm: qemu: Mention -nographic in the docs Simon Glass
@ 2021-10-26 0:23 ` Simon Glass
2021-10-26 0:23 ` [PATCH v5 05/26] arm: qemu: Add a devicetree file for qemu_arm Simon Glass
` (4 subsequent siblings)
6 siblings, 0 replies; 48+ 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] 48+ messages in thread
* [PATCH v5 05/26] arm: qemu: Add a devicetree file for qemu_arm
2021-10-26 0:23 [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option Simon Glass
2021-10-26 0:23 ` [PATCH v5 03/26] arm: qemu: Mention -nographic in the docs Simon Glass
2021-10-26 0:23 ` [PATCH v5 04/26] arm: riscv: qemu: Explain how to extract the generated dt Simon Glass
@ 2021-10-26 0:23 ` Simon Glass
2021-10-26 0:23 ` [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64 Simon Glass
` (3 subsequent siblings)
6 siblings, 0 replies; 48+ 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] 48+ messages in thread
* [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-10-26 0:23 [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option Simon Glass
` (2 preceding siblings ...)
2021-10-26 0:23 ` [PATCH v5 05/26] arm: qemu: Add a devicetree file for qemu_arm Simon Glass
@ 2021-10-26 0:23 ` Simon Glass
2021-11-01 10:48 ` Peter Maydell
2021-10-26 0:23 ` [PATCH v5 07/26] riscv: qemu: Add devicetree files for qemu_riscv32/64 Simon Glass
` (2 subsequent siblings)
6 siblings, 1 reply; 48+ 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] 48+ messages in thread
* [PATCH v5 07/26] riscv: qemu: Add devicetree files for qemu_riscv32/64
2021-10-26 0:23 [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option Simon Glass
` (3 preceding siblings ...)
2021-10-26 0:23 ` [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64 Simon Glass
@ 2021-10-26 0:23 ` Simon Glass
2021-10-26 6:07 ` [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option François Ozog
2021-11-03 17:13 ` François Ozog
6 siblings, 0 replies; 48+ 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] 48+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-26 0:23 [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option Simon Glass
` (4 preceding siblings ...)
2021-10-26 0:23 ` [PATCH v5 07/26] riscv: qemu: Add devicetree files for qemu_riscv32/64 Simon Glass
@ 2021-10-26 6:07 ` François Ozog
2021-10-27 14:08 ` Simon Glass
2021-11-03 17:13 ` François Ozog
6 siblings, 1 reply; 48+ 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] 48+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-26 6:07 ` [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option François Ozog
@ 2021-10-27 14:08 ` Simon Glass
2021-10-27 15:14 ` François Ozog
` (3 more replies)
0 siblings, 4 replies; 48+ 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] 48+ 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
2021-10-27 18:23 ` Simon Glass
2021-10-27 15:36 ` Tuomas Tynkkynen
` (2 subsequent siblings)
3 siblings, 1 reply; 48+ 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] 48+ 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
@ 2021-10-27 15:36 ` Tuomas Tynkkynen
2021-10-27 19:13 ` Tom Rini
2021-10-27 18:16 ` Tom Rini
2021-10-27 18:24 ` Tom Rini
3 siblings, 1 reply; 48+ 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] 48+ 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
2021-10-27 15:36 ` Tuomas Tynkkynen
@ 2021-10-27 18:16 ` Tom Rini
2021-10-27 18:24 ` Tom Rini
3 siblings, 0 replies; 48+ 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] 48+ 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
2021-10-27 19:25 ` Tom Rini
` (2 more replies)
0 siblings, 3 replies; 48+ 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] 48+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-27 14:08 ` Simon Glass
` (2 preceding siblings ...)
2021-10-27 18:16 ` Tom Rini
@ 2021-10-27 18:24 ` Tom Rini
3 siblings, 0 replies; 48+ 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] 48+ 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
0 siblings, 0 replies; 48+ 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] 48+ 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
2021-11-03 16:45 ` Simon Glass
2021-10-27 20:07 ` François Ozog
2021-10-27 22:30 ` Mark Kettenis
2 siblings, 1 reply; 48+ 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] 48+ 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
@ 2021-10-27 20:07 ` François Ozog
2021-11-03 1:20 ` Simon Glass
2021-10-27 22:30 ` Mark Kettenis
2 siblings, 1 reply; 48+ 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] 48+ 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
2021-10-27 20:07 ` François Ozog
@ 2021-10-27 22:30 ` Mark Kettenis
2021-11-03 1:20 ` Simon Glass
2 siblings, 1 reply; 48+ 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] 48+ messages in thread
* Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
2021-10-26 0:23 ` [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64 Simon Glass
@ 2021-11-01 10:48 ` Peter Maydell
2021-11-01 16:58 ` Simon Glass
0 siblings, 1 reply; 48+ 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] 48+ 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
2021-11-01 17:33 ` François Ozog
0 siblings, 1 reply; 48+ 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] 48+ 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
2021-11-01 18:07 ` Tom Rini
2021-11-02 14:59 ` Simon Glass
0 siblings, 2 replies; 48+ 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] 48+ 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
2021-11-02 15:00 ` Simon Glass
2021-11-02 14:59 ` Simon Glass
1 sibling, 1 reply; 48+ 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] 48+ 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
@ 2021-11-02 14:59 ` Simon Glass
2021-11-02 16:57 ` Tom Rini
1 sibling, 1 reply; 48+ 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] 48+ 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
2021-11-02 17:28 ` Tom Rini
0 siblings, 1 reply; 48+ 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] 48+ 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
2021-11-03 1:32 ` Simon Glass
0 siblings, 1 reply; 48+ 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] 48+ 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
2021-11-03 1:29 ` Simon Glass
0 siblings, 1 reply; 48+ 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] 48+ 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
2021-11-03 4:45 ` François Ozog
0 siblings, 1 reply; 48+ 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] 48+ 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
2021-11-03 8:22 ` Mark Kettenis
2021-11-03 15:56 ` Tom Rini
0 siblings, 2 replies; 48+ 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] 48+ 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
2021-11-03 5:29 ` François Ozog
2021-11-03 14:39 ` Tom Rini
0 siblings, 2 replies; 48+ 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] 48+ 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
2021-11-03 14:39 ` Tom Rini
0 siblings, 1 reply; 48+ 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] 48+ 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
0 siblings, 0 replies; 48+ 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] 48+ 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
2021-11-03 14:41 ` Tom Rini
2021-11-03 14:44 ` François Ozog
2021-11-03 14:39 ` Tom Rini
1 sibling, 2 replies; 48+ 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] 48+ 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
2021-11-03 16:02 ` Tom Rini
2021-11-03 15:56 ` Tom Rini
1 sibling, 1 reply; 48+ 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] 48+ 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
@ 2021-11-03 14:39 ` Tom Rini
1 sibling, 0 replies; 48+ 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] 48+ 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
0 siblings, 0 replies; 48+ 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] 48+ 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
2021-11-04 11:09 ` Peter Maydell
2021-11-03 14:44 ` François Ozog
1 sibling, 1 reply; 48+ 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] 48+ 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
@ 2021-11-03 14:44 ` François Ozog
1 sibling, 0 replies; 48+ 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] 48+ 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
@ 2021-11-03 15:56 ` Tom Rini
2021-11-03 16:45 ` Simon Glass
1 sibling, 1 reply; 48+ 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] 48+ 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
2021-11-03 16:45 ` Simon Glass
0 siblings, 1 reply; 48+ 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] 48+ 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
2021-11-03 17:21 ` Tom Rini
0 siblings, 1 reply; 48+ 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] 48+ 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
0 siblings, 0 replies; 48+ 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] 48+ 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
2021-11-03 17:36 ` Mark Kettenis
0 siblings, 1 reply; 48+ 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] 48+ messages in thread
* Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
2021-10-26 0:23 [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option Simon Glass
` (5 preceding siblings ...)
2021-10-26 6:07 ` [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option François Ozog
@ 2021-11-03 17:13 ` François Ozog
6 siblings, 0 replies; 48+ 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] 48+ 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
0 siblings, 0 replies; 48+ 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] 48+ 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
0 siblings, 0 replies; 48+ 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] 48+ 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
2021-11-04 11:22 ` François Ozog
0 siblings, 1 reply; 48+ 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] 48+ 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
2021-11-04 11:41 ` Peter Maydell
0 siblings, 1 reply; 48+ 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] 48+ 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
2021-11-04 11:48 ` François Ozog
0 siblings, 1 reply; 48+ 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] 48+ 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
0 siblings, 0 replies; 48+ 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] 48+ messages in thread
end of thread, other threads:[~2021-11-04 11:51 UTC | newest]
Thread overview: 48+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-26 0:23 [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option Simon Glass
2021-10-26 0:23 ` [PATCH v5 03/26] arm: qemu: Mention -nographic in the docs Simon Glass
2021-10-26 0:23 ` [PATCH v5 04/26] arm: riscv: qemu: Explain how to extract the generated dt Simon Glass
2021-10-26 0:23 ` [PATCH v5 05/26] arm: qemu: Add a devicetree file for qemu_arm Simon Glass
2021-10-26 0:23 ` [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64 Simon Glass
2021-11-01 10:48 ` Peter Maydell
2021-11-01 16:58 ` Simon Glass
2021-11-01 17:33 ` François Ozog
2021-11-01 18:07 ` Tom Rini
2021-11-02 15:00 ` Simon Glass
2021-11-02 17:28 ` Tom Rini
2021-11-03 1:29 ` Simon Glass
2021-11-03 5:29 ` François Ozog
2021-11-03 14:41 ` Tom Rini
2021-11-04 11:09 ` Peter Maydell
2021-11-04 11:22 ` François Ozog
2021-11-04 11:41 ` Peter Maydell
2021-11-04 11:48 ` François Ozog
2021-11-03 14:44 ` François Ozog
2021-11-03 14:39 ` Tom Rini
2021-11-02 14:59 ` Simon Glass
2021-11-02 16:57 ` Tom Rini
2021-11-03 1:32 ` Simon Glass
2021-11-03 14:39 ` Tom Rini
2021-10-26 0:23 ` [PATCH v5 07/26] riscv: qemu: Add devicetree files for qemu_riscv32/64 Simon Glass
2021-10-26 6:07 ` [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option François Ozog
2021-10-27 14:08 ` Simon Glass
2021-10-27 15:14 ` François Ozog
2021-10-27 18:23 ` Simon Glass
2021-10-27 19:25 ` Tom Rini
2021-11-03 16:45 ` Simon Glass
2021-11-03 17:21 ` Tom Rini
2021-10-27 20:07 ` François Ozog
2021-11-03 1:20 ` Simon Glass
2021-11-03 4:45 ` François Ozog
2021-10-27 22:30 ` Mark Kettenis
2021-11-03 1:20 ` Simon Glass
2021-11-03 8:22 ` Mark Kettenis
2021-11-03 16:02 ` Tom Rini
2021-11-03 16:45 ` Simon Glass
2021-11-03 17:36 ` Mark Kettenis
2021-11-03 15:56 ` Tom Rini
2021-11-03 16:45 ` Simon Glass
2021-10-27 15:36 ` Tuomas Tynkkynen
2021-10-27 19:13 ` Tom Rini
2021-10-27 18:16 ` Tom Rini
2021-10-27 18:24 ` Tom Rini
2021-11-03 17:13 ` François Ozog
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).