* [PATCH 00/16] fdt: Make OF_BOARD a boolean option @ 2021-10-13 1:01 Simon Glass 2021-10-13 1:01 ` [PATCH 01/16] arm: qemu: Mention -nographic in the docs Simon Glass ` (8 more replies) 0 siblings, 9 replies; 73+ messages in thread From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw) To: U-Boot Mailing List Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari 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 at [1]. 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. It also provides a few qemu clean-ups discovered along the way. This series is based on Ilias' two series for OF_HOSTFILE and OF_PRIOR_STAGE removal. It is available at u-boot-dm/ofb-working [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ Simon Glass (16): arm: qemu: Mention -nographic in the docs arm: qemu: Explain how to extract the generate devicetree riscv: qemu: Explain how to extract the generate devicetree 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 Makefile | 3 +- arch/arm/dts/Makefile | 20 +- arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++ arch/arm/dts/bcm7xxx.dts | 15 + arch/arm/dts/highbank.dts | 14 + arch/arm/dts/juno-r2.dts | 1038 +++++++++++++ arch/arm/dts/octeontx.dts | 14 + arch/arm/dts/qemu-arm.dts | 402 +++++ arch/arm/dts/qemu-arm64.dts | 381 +++++ arch/arm/dts/xenguest-arm64.dts | 15 + arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/qemu-ppce500.dts | 264 ++++ arch/riscv/dts/Makefile | 2 +- arch/riscv/dts/qemu-virt.dts | 8 - arch/riscv/dts/qemu-virt32.dts | 217 +++ arch/riscv/dts/qemu-virt64.dts | 217 +++ configs/bcm7260_defconfig | 1 + configs/bcm7445_defconfig | 1 + configs/highbank_defconfig | 2 +- configs/octeontx2_95xx_defconfig | 1 + configs/octeontx2_96xx_defconfig | 1 + configs/octeontx_81xx_defconfig | 1 + configs/octeontx_83xx_defconfig | 1 + configs/qemu-ppce500_defconfig | 2 + configs/qemu-riscv32_defconfig | 1 + configs/qemu-riscv32_smode_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 4 +- configs/qemu-riscv64_defconfig | 1 + configs/qemu-riscv64_smode_defconfig | 1 + configs/qemu-riscv64_spl_defconfig | 3 +- configs/qemu_arm64_defconfig | 1 + configs/qemu_arm_defconfig | 1 + configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + configs/vexpress_aemv8a_juno_defconfig | 1 + configs/xenguest_arm64_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + doc/board/emulation/qemu-arm.rst | 19 +- doc/board/emulation/qemu-riscv.rst | 12 + dts/Kconfig | 27 +- tools/binman/binman.rst | 20 - 43 files changed, 4922 insertions(+), 61 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 -- 2.33.0.882.g93a45727a2-goog ^ permalink raw reply [flat|nested] 73+ messages in thread
* [PATCH 01/16] arm: qemu: Mention -nographic in the docs 2021-10-13 1:01 [PATCH 00/16] fdt: Make OF_BOARD a boolean option Simon Glass @ 2021-10-13 1:01 ` Simon Glass 2021-10-13 1:01 ` [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree Simon Glass ` (7 subsequent siblings) 8 siblings, 0 replies; 73+ messages in thread From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw) To: U-Boot Mailing List Cc: Tom Rini, Simon Glass, Ilias Apalodimas, qemu-devel, Albert Aribaud Without this option QEMU appears to hang. Add it to avoid confusion. Signed-off-by: Simon Glass <sjg@chromium.org> --- 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.882.g93a45727a2-goog ^ permalink raw reply related [flat|nested] 73+ messages in thread
* [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree 2021-10-13 1:01 [PATCH 00/16] fdt: Make OF_BOARD a boolean option Simon Glass 2021-10-13 1:01 ` [PATCH 01/16] arm: qemu: Mention -nographic in the docs Simon Glass @ 2021-10-13 1:01 ` Simon Glass 2021-10-13 1:19 ` François Ozog 2021-10-13 1:01 ` [PATCH 03/16] riscv: " Simon Glass ` (6 subsequent siblings) 8 siblings, 1 reply; 73+ messages in thread From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw) To: U-Boot Mailing List Cc: Tom Rini, Simon Glass, Ilias Apalodimas, qemu-devel, Albert Aribaud QEMU currently generates a devicetree for use with U-Boot. Explain how to obtain it. Signed-off-by: Simon Glass <sjg@chromium.org> --- doc/board/emulation/qemu-arm.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst index 97b6ec64905..b458a398c69 100644 --- a/doc/board/emulation/qemu-arm.rst +++ b/doc/board/emulation/qemu-arm.rst @@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these settings:: CONFIG_DEBUG_UART_PL010=y CONFIG_DEBUG_UART_BASE=0x9000000 CONFIG_DEBUG_UART_CLOCK=0 + +Obtaining the QEMU devicetree +----------------------------- + +QEMU generates its own devicetree to pass to U-Boot and does this by default. +You 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=dtb.dtb`, +e.g.:: + + qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \ + -bios u-boot.bin -machine dumpdtb=dtb.dtb -- 2.33.0.882.g93a45727a2-goog ^ permalink raw reply related [flat|nested] 73+ messages in thread
* Re: [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree 2021-10-13 1:01 ` [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree Simon Glass @ 2021-10-13 1:19 ` François Ozog 2021-10-13 16:58 ` Simon Glass 0 siblings, 1 reply; 73+ messages in thread From: François Ozog @ 2021-10-13 1:19 UTC (permalink / raw) To: Simon Glass Cc: U-Boot Mailing List, Albert Aribaud, Ilias Apalodimas, qemu-devel, Tom Rini [-- Attachment #1: Type: text/plain, Size: 1541 bytes --] Le mer. 13 oct. 2021 à 03:02, Simon Glass <sjg@chromium.org> a écrit : > QEMU currently generates a devicetree for use with U-Boot. Explain how to > obtain it. > > Signed-off-by: Simon Glass <sjg@chromium.org> > --- > > doc/board/emulation/qemu-arm.rst | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/doc/board/emulation/qemu-arm.rst > b/doc/board/emulation/qemu-arm.rst > index 97b6ec64905..b458a398c69 100644 > --- a/doc/board/emulation/qemu-arm.rst > +++ b/doc/board/emulation/qemu-arm.rst > @@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these > settings:: > CONFIG_DEBUG_UART_PL010=y > CONFIG_DEBUG_UART_BASE=0x9000000 > CONFIG_DEBUG_UART_CLOCK=0 > + > +Obtaining the QEMU devicetree > +----------------------------- > + > +QEMU generates its own devicetree to pass to U-Boot and does this by > default. > +You can use `-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree > version. this is for either Qemu experts or u-boot for Qemu maintainers. Not for the kernel développer as it is recipe for problems: could you add this warning ? > > + > +To obtain the devicetree that qemu generates, add `-machine > dumpdtb=dtb.dtb`, > +e.g.:: > + > + qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \ > + -bios u-boot.bin -machine dumpdtb=dtb.dtb > -- > 2.33.0.882.g93a45727a2-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: 3461 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree 2021-10-13 1:19 ` François Ozog @ 2021-10-13 16:58 ` Simon Glass 2021-10-13 17:36 ` Tom Rini 0 siblings, 1 reply; 73+ messages in thread From: Simon Glass @ 2021-10-13 16:58 UTC (permalink / raw) To: François Ozog Cc: U-Boot Mailing List, Albert Aribaud, Ilias Apalodimas, QEMU Developers, Tom Rini Hi François, On Tue, 12 Oct 2021 at 19:20, François Ozog <francois.ozog@linaro.org> wrote: > > > > Le mer. 13 oct. 2021 à 03:02, Simon Glass <sjg@chromium.org> a écrit : >> >> QEMU currently generates a devicetree for use with U-Boot. Explain how to >> obtain it. >> >> Signed-off-by: Simon Glass <sjg@chromium.org> >> --- >> >> doc/board/emulation/qemu-arm.rst | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) >> >> diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst >> index 97b6ec64905..b458a398c69 100644 >> --- a/doc/board/emulation/qemu-arm.rst >> +++ b/doc/board/emulation/qemu-arm.rst >> @@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these settings:: >> CONFIG_DEBUG_UART_PL010=y >> CONFIG_DEBUG_UART_BASE=0x9000000 >> CONFIG_DEBUG_UART_CLOCK=0 >> + >> +Obtaining the QEMU devicetree >> +----------------------------- >> + >> +QEMU generates its own devicetree to pass to U-Boot and does this by default. >> +You can use `-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version. > > this is for either Qemu experts or u-boot for Qemu maintainers. Not for the kernel développer as it is recipe for problems: could you add this warning ? Yes I can do that...or would it be better to hide this in doc/develop somewhere with a link here? >> >> >> + >> +To obtain the devicetree that qemu generates, add `-machine dumpdtb=dtb.dtb`, >> +e.g.:: >> + >> + qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \ >> + -bios u-boot.bin -machine dumpdtb=dtb.dtb >> -- >> 2.33.0.882.g93a45727a2-goog >> Regards, Simon ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree 2021-10-13 16:58 ` Simon Glass @ 2021-10-13 17:36 ` Tom Rini 0 siblings, 0 replies; 73+ messages in thread From: Tom Rini @ 2021-10-13 17:36 UTC (permalink / raw) To: Simon Glass Cc: U-Boot Mailing List, François Ozog, Ilias Apalodimas, QEMU Developers, Albert Aribaud [-- Attachment #1: Type: text/plain, Size: 1677 bytes --] On Wed, Oct 13, 2021 at 10:58:31AM -0600, Simon Glass wrote: > Hi François, > > On Tue, 12 Oct 2021 at 19:20, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > Le mer. 13 oct. 2021 à 03:02, Simon Glass <sjg@chromium.org> a écrit : > >> > >> QEMU currently generates a devicetree for use with U-Boot. Explain how to > >> obtain it. > >> > >> Signed-off-by: Simon Glass <sjg@chromium.org> > >> --- > >> > >> doc/board/emulation/qemu-arm.rst | 12 ++++++++++++ > >> 1 file changed, 12 insertions(+) > >> > >> diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst > >> index 97b6ec64905..b458a398c69 100644 > >> --- a/doc/board/emulation/qemu-arm.rst > >> +++ b/doc/board/emulation/qemu-arm.rst > >> @@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these settings:: > >> CONFIG_DEBUG_UART_PL010=y > >> CONFIG_DEBUG_UART_BASE=0x9000000 > >> CONFIG_DEBUG_UART_CLOCK=0 > >> + > >> +Obtaining the QEMU devicetree > >> +----------------------------- > >> + > >> +QEMU generates its own devicetree to pass to U-Boot and does this by default. > >> +You can use `-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version. > > > > this is for either Qemu experts or u-boot for Qemu maintainers. Not for the kernel développer as it is recipe for problems: could you add this warning ? > > Yes I can do that...or would it be better to hide this in doc/develop > somewhere with a link here? Somewhere under doc/develop and an external link to the QEMU documentation on dumpdtb would be good, as it's (as you demonstrate throughout this series) a generic feature. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* [PATCH 03/16] riscv: qemu: Explain how to extract the generate devicetree 2021-10-13 1:01 [PATCH 00/16] fdt: Make OF_BOARD a boolean option Simon Glass 2021-10-13 1:01 ` [PATCH 01/16] arm: qemu: Mention -nographic in the docs Simon Glass 2021-10-13 1:01 ` [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree Simon Glass @ 2021-10-13 1:01 ` Simon Glass 2021-10-13 1:01 ` [PATCH 04/16] arm: qemu: Add a devicetree file for qemu_arm Simon Glass ` (5 subsequent siblings) 8 siblings, 0 replies; 73+ messages in thread From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw) To: U-Boot Mailing List Cc: Tom Rini, Ilias Apalodimas, Heinrich Schuchardt, Simon Glass, Bin Meng, Rick Chen, qemu-devel, Atish Patra QEMU currently generates a devicetree for use with U-Boot. Explain how to obtain it. Signed-off-by: Simon Glass <sjg@chromium.org> --- doc/board/emulation/qemu-riscv.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst index 4b8e104a215..b3cf7085847 100644 --- a/doc/board/emulation/qemu-riscv.rst +++ b/doc/board/emulation/qemu-riscv.rst @@ -113,3 +113,15 @@ An attached disk can be emulated by adding:: -device ide-hd,drive=mydisk,bus=ahci.0 You will have to run 'scsi scan' to use it. + +Obtaining the QEMU devicetree +----------------------------- + +QEMU generates its own devicetree to pass to U-Boot and does this by default. +You 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=dtb.dtb`, +e.g.:: + + qemu-system-riscv64 -nographic -machine virt -bios u-boot \ + -machine dumpdtb=dtb.dtb -- 2.33.0.882.g93a45727a2-goog ^ permalink raw reply related [flat|nested] 73+ messages in thread
* [PATCH 04/16] arm: qemu: Add a devicetree file for qemu_arm 2021-10-13 1:01 [PATCH 00/16] fdt: Make OF_BOARD a boolean option Simon Glass ` (2 preceding siblings ...) 2021-10-13 1:01 ` [PATCH 03/16] riscv: " Simon Glass @ 2021-10-13 1:01 ` Simon Glass 2021-10-13 1:01 ` [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64 Simon Glass ` (4 subsequent siblings) 8 siblings, 0 replies; 73+ messages in thread From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw) To: U-Boot Mailing List Cc: Tom Rini, Albert Aribaud, qemu-devel, Andre Przywara, Simon Glass, Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen, Neil Armstrong, Tuomas Tynkkynen, Jagan Teki, Sean Anderson, Heiko Schocher, Fabio Estevam, Tim Harvey, Peter Robinson 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> --- 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 b8a382d1539..e2fc0cb65fc 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1145,6 +1145,8 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += imx8mm-cl-iot-gate.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..790571a9d9e --- /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 = <0x00 0x3f000000 0x00 0x1000000>; + 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.882.g93a45727a2-goog ^ permalink raw reply related [flat|nested] 73+ messages in thread
* [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64 2021-10-13 1:01 [PATCH 00/16] fdt: Make OF_BOARD a boolean option Simon Glass ` (3 preceding siblings ...) 2021-10-13 1:01 ` [PATCH 04/16] arm: qemu: Add a devicetree file for qemu_arm Simon Glass @ 2021-10-13 1:01 ` Simon Glass 2021-10-13 1:15 ` François Ozog 2021-10-13 1:01 ` [PATCH 06/16] riscv: qemu: Add devicetree files for qemu_riscv32/64 Simon Glass ` (3 subsequent siblings) 8 siblings, 1 reply; 73+ messages in thread From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw) To: U-Boot Mailing List Cc: Tom Rini, Albert Aribaud, qemu-devel, Andre Przywara, Simon Glass, Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen, Neil Armstrong, Tuomas Tynkkynen, Jagan Teki, Sean Anderson, Heiko Schocher, Fabio Estevam, Tim Harvey, Peter Robinson 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> --- 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 e2fc0cb65fc..52c586f3974 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1145,7 +1145,7 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += imx8mm-cl-iot-gate.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.882.g93a45727a2-goog ^ permalink raw reply related [flat|nested] 73+ messages in thread
* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64 2021-10-13 1:01 ` [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64 Simon Glass @ 2021-10-13 1:15 ` François Ozog 2021-10-27 14:44 ` Alex Bennée 0 siblings, 1 reply; 73+ messages in thread From: François Ozog @ 2021-10-13 1:15 UTC (permalink / raw) To: Simon Glass Cc: Albert Aribaud, qemu-devel, Neil Armstrong, U-Boot Mailing List, Andre Przywara, Tim Harvey, Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen, Tuomas Tynkkynen, Jagan Teki, Sean Anderson, Heiko Schocher, Fabio Estevam, Tom Rini, Peter Robinson [-- Attachment #1: Type: text/plain, Size: 16023 bytes --] Hi Simon The only place I could agree with this file presence is in the documentation directory, not in dts. It creates a mental picture for the reader an entirely bad mind scheme around Qemu and DT. And even in a documentation directory I would place a bug warning: don’t use this with any kernel , Qemu generates a DT dynamically based on cpu, memory and devices specified at the command line. I would also document how to get the DT that Qemu generates (and lkvm btw) outside any firmware/os provided. Cheers FF Le mer. 13 oct. 2021 à 03:03, Simon Glass <sjg@chromium.org> a écrit : > 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> > --- > > 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 e2fc0cb65fc..52c586f3974 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -1145,7 +1145,7 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += > imx8mm-cl-iot-gate.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.882.g93a45727a2-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: 22346 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64 2021-10-13 1:15 ` François Ozog @ 2021-10-27 14:44 ` Alex Bennée 2021-10-27 14:56 ` Tom Rini 0 siblings, 1 reply; 73+ messages in thread From: Alex Bennée @ 2021-10-27 14:44 UTC (permalink / raw) To: François Ozog Cc: Albert Aribaud, Tom Rini, Heiko Schocher, Neil Armstrong, qemu-devel, Andre Przywara, Simon Glass, Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen, U-Boot Mailing List, Jagan Teki, Sean Anderson, Tuomas Tynkkynen, Fabio Estevam, Tim Harvey, Peter Robinson François Ozog <francois.ozog@linaro.org> writes: > Hi Simon > > The only place I could agree with this file presence is in the documentation directory, not in dts. It creates a mental picture for the reader > an entirely bad mind scheme around Qemu and DT. > > And even in a documentation directory I would place a bug warning: don’t use this with any kernel , Qemu generates a DT dynamically > based on cpu, memory and devices specified at the command line. Certainly for the arm, aarch64 and riscv "virt" machines you should always use the QEMU generated DTB. I'm not entirely clear what a qemu_arm and qemu_arm64 def targets are meant to be in this context. -- Alex Bennée ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64 2021-10-27 14:44 ` Alex Bennée @ 2021-10-27 14:56 ` Tom Rini 2021-10-27 18:34 ` Simon Glass 0 siblings, 1 reply; 73+ messages in thread From: Tom Rini @ 2021-10-27 14:56 UTC (permalink / raw) To: Alex Bennée Cc: Heiko Schocher, François Ozog, Albert Aribaud, Neil Armstrong, qemu-devel, Andre Przywara, Simon Glass, Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen, U-Boot Mailing List, Jagan Teki, Sean Anderson, Tuomas Tynkkynen, Fabio Estevam, Tim Harvey, Peter Robinson [-- Attachment #1: Type: text/plain, Size: 944 bytes --] On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote: > > François Ozog <francois.ozog@linaro.org> writes: > > > Hi Simon > > > > The only place I could agree with this file presence is in the documentation directory, not in dts. It creates a mental picture for the reader > > an entirely bad mind scheme around Qemu and DT. > > > > And even in a documentation directory I would place a bug warning: don’t use this with any kernel , Qemu generates a DT dynamically > > based on cpu, memory and devices specified at the command line. > > Certainly for the arm, aarch64 and riscv "virt" machines you should > always use the QEMU generated DTB. I'm not entirely clear what a > qemu_arm and qemu_arm64 def targets are meant to be in this context. Agreed. We cannot include random device trees in U-Boot for devices that generate their own at run time or otherwise have the source of truth elsewhere. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64 2021-10-27 14:56 ` Tom Rini @ 2021-10-27 18:34 ` Simon Glass 2021-10-27 18:39 ` Tom Rini 0 siblings, 1 reply; 73+ messages in thread From: Simon Glass @ 2021-10-27 18:34 UTC (permalink / raw) To: Tom Rini Cc: Heiko Schocher, François Ozog, Albert Aribaud, Neil Armstrong, QEMU Developers, Andre Przywara, Tim Harvey, Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen, U-Boot Mailing List, Jagan Teki, Sean Anderson, Fabio Estevam, Tuomas Tynkkynen, Alex Bennée, Peter Robinson Hi all, On Wed, 27 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote: > > > > François Ozog <francois.ozog@linaro.org> writes: > > > > > Hi Simon > > > > > > The only place I could agree with this file presence is in the documentation directory, not in dts. It creates a mental picture for the reader > > > an entirely bad mind scheme around Qemu and DT. > > > > > > And even in a documentation directory I would place a bug warning: don’t use this with any kernel , Qemu generates a DT dynamically > > > based on cpu, memory and devices specified at the command line. > > > > Certainly for the arm, aarch64 and riscv "virt" machines you should > > always use the QEMU generated DTB. I'm not entirely clear what a > > qemu_arm and qemu_arm64 def targets are meant to be in this context. > > Agreed. We cannot include random device trees in U-Boot for devices > that generate their own at run time or otherwise have the source of > truth elsewhere. Until we have a way of bringing in the u-boot.dtsi that people in QEMU can agree on, I don't see an alternative. I will send a series for the bloblist handoff next week and I think you will all see what I mean. Perhaps all this will be easier a year or so, if we continue to make progress on the devicetree validation/sharing stuff, but for now, this seems like the only viable approach to me. Regards, Simon ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64 2021-10-27 18:34 ` Simon Glass @ 2021-10-27 18:39 ` Tom Rini 2021-10-27 19:45 ` Alex Bennée 0 siblings, 1 reply; 73+ messages in thread From: Tom Rini @ 2021-10-27 18:39 UTC (permalink / raw) To: Simon Glass Cc: Heiko Schocher, François Ozog, Albert Aribaud, Neil Armstrong, QEMU Developers, Andre Przywara, Tim Harvey, Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen, U-Boot Mailing List, Jagan Teki, Sean Anderson, Fabio Estevam, Tuomas Tynkkynen, Alex Bennée, Peter Robinson [-- Attachment #1: Type: text/plain, Size: 1673 bytes --] On Wed, Oct 27, 2021 at 12:34:26PM -0600, Simon Glass wrote: > Hi all, > > On Wed, 27 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote: > > > > > > François Ozog <francois.ozog@linaro.org> writes: > > > > > > > Hi Simon > > > > > > > > The only place I could agree with this file presence is in the documentation directory, not in dts. It creates a mental picture for the reader > > > > an entirely bad mind scheme around Qemu and DT. > > > > > > > > And even in a documentation directory I would place a bug warning: don’t use this with any kernel , Qemu generates a DT dynamically > > > > based on cpu, memory and devices specified at the command line. > > > > > > Certainly for the arm, aarch64 and riscv "virt" machines you should > > > always use the QEMU generated DTB. I'm not entirely clear what a > > > qemu_arm and qemu_arm64 def targets are meant to be in this context. > > > > Agreed. We cannot include random device trees in U-Boot for devices > > that generate their own at run time or otherwise have the source of > > truth elsewhere. > > Until we have a way of bringing in the u-boot.dtsi that people in QEMU > can agree on, I don't see an alternative. I will send a series for the > bloblist handoff next week and I think you will all see what I mean. I think the alternative is that QEMU in U-Boot just can't be used for certain features. Which is annoying in that it would be good to use it to test certain feature, yes. It's generating a good and valid enough dtb for Linux, so it should be good enough for us in general. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64 2021-10-27 18:39 ` Tom Rini @ 2021-10-27 19:45 ` Alex Bennée 0 siblings, 0 replies; 73+ messages in thread From: Alex Bennée @ 2021-10-27 19:45 UTC (permalink / raw) To: Tom Rini Cc: Heiko Schocher, François Ozog, Albert Aribaud, Neil Armstrong, QEMU Developers, Andre Przywara, Simon Glass, Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen, U-Boot Mailing List, Jagan Teki, Sean Anderson, Tuomas Tynkkynen, Fabio Estevam, Tim Harvey, Peter Robinson [-- Attachment #1: Type: text/plain, Size: 2034 bytes --] There are QEMU targets that have fixed hardware which do rely on the firmware to have a fixed view of the hardware. sbsa-ref is one such board although there will be some versioning required for later levels. On Wed, 27 Oct 2021, 19:39 Tom Rini, <trini@konsulko.com> wrote: > On Wed, Oct 27, 2021 at 12:34:26PM -0600, Simon Glass wrote: > > Hi all, > > > > On Wed, 27 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote: > > > > > > > > François Ozog <francois.ozog@linaro.org> writes: > > > > > > > > > Hi Simon > > > > > > > > > > The only place I could agree with this file presence is in the > documentation directory, not in dts. It creates a mental picture for the > reader > > > > > an entirely bad mind scheme around Qemu and DT. > > > > > > > > > > And even in a documentation directory I would place a bug warning: > don’t use this with any kernel , Qemu generates a DT dynamically > > > > > based on cpu, memory and devices specified at the command line. > > > > > > > > Certainly for the arm, aarch64 and riscv "virt" machines you should > > > > always use the QEMU generated DTB. I'm not entirely clear what a > > > > qemu_arm and qemu_arm64 def targets are meant to be in this context. > > > > > > Agreed. We cannot include random device trees in U-Boot for devices > > > that generate their own at run time or otherwise have the source of > > > truth elsewhere. > > > > Until we have a way of bringing in the u-boot.dtsi that people in QEMU > > can agree on, I don't see an alternative. I will send a series for the > > bloblist handoff next week and I think you will all see what I mean. > > I think the alternative is that QEMU in U-Boot just can't be used for > certain features. Which is annoying in that it would be good to use it > to test certain feature, yes. It's generating a good and valid enough > dtb for Linux, so it should be good enough for us in general. > > -- > Tom > [-- Attachment #2: Type: text/html, Size: 2751 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* [PATCH 06/16] riscv: qemu: Add devicetree files for qemu_riscv32/64 2021-10-13 1:01 [PATCH 00/16] fdt: Make OF_BOARD a boolean option Simon Glass ` (4 preceding siblings ...) 2021-10-13 1:01 ` [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64 Simon Glass @ 2021-10-13 1:01 ` Simon Glass 2021-10-13 4:21 ` Heinrich Schuchardt 2021-10-13 1:29 ` [PATCH 00/16] fdt: Make OF_BOARD a boolean option Bin Meng ` (2 subsequent siblings) 8 siblings, 1 reply; 73+ messages in thread From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw) To: U-Boot Mailing List Cc: Tom Rini, qemu-devel, Leo, David Abdurachmanov, Simon Glass, Ilias Apalodimas, Rick Chen, Green Wan, Sean Anderson, Heinrich Schuchardt, Zong Li, Tianrui Wei, Bin Meng, Dimitri John Ledkov, Padmarao Begari 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> --- 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.882.g93a45727a2-goog ^ permalink raw reply related [flat|nested] 73+ messages in thread
* Re: [PATCH 06/16] riscv: qemu: Add devicetree files for qemu_riscv32/64 2021-10-13 1:01 ` [PATCH 06/16] riscv: qemu: Add devicetree files for qemu_riscv32/64 Simon Glass @ 2021-10-13 4:21 ` Heinrich Schuchardt 0 siblings, 0 replies; 73+ messages in thread From: Heinrich Schuchardt @ 2021-10-13 4:21 UTC (permalink / raw) To: Simon Glass Cc: Tom Rini, qemu-devel, Leo, David Abdurachmanov, Ilias Apalodimas, Rick Chen, Green Wan, Sean Anderson, U-Boot Mailing List, Zong Li, Tianrui Wei, Bin Meng, Dimitri John Ledkov, Padmarao Begari On 10/13/21 03:01, Simon Glass wrote: > 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. > You only sent patch 6/16 and 15/16 to me. No clue why. Please, send complete patchsets instead of selected patches which cannot be reviewed without the context. Which devices exist depends on the QEMU comannd line. The files you create here do neither reflect the superset of all QEMU settings nor the minimum set. They do not include all devices supported on QEMU by U-Boot either. You cannot assume that the values in this patch will match values used by the next invocation of QEMU. Hence it is totally unclear what this patch might be good for. Best regards Heinrich > Signed-off-by: Simon Glass <sjg@chromium.org> > --- > > 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 > ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-13 1:01 [PATCH 00/16] fdt: Make OF_BOARD a boolean option Simon Glass ` (5 preceding siblings ...) 2021-10-13 1:01 ` [PATCH 06/16] riscv: qemu: Add devicetree files for qemu_riscv32/64 Simon Glass @ 2021-10-13 1:29 ` Bin Meng 2021-10-13 1:34 ` Tom Rini 2021-10-13 12:39 ` Philippe Mathieu-Daudé 2021-10-13 4:26 ` Heinrich Schuchardt 2021-10-13 9:50 ` Andre Przywara 8 siblings, 2 replies; 73+ messages in thread From: Bin Meng @ 2021-10-13 1:29 UTC (permalink / raw) To: Simon Glass Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, U-Boot Mailing List, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, Atish Patra, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Pali Rohár, Dimitri John Ledkov, Padmarao Begari Hi Simon, On Wed, Oct 13, 2021 at 9:01 AM 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 > > 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 at [1]. > > 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. Adding device trees that are never used sounds like a hack to me. For QEMU, device tree is dynamically generated on the fly based on command line parameters, and the device tree you put in this series has various hardcoded <phandle> values which normally do not show up in hand-written dts files. I am not sure I understand the whole point of this. > > It also provides a few qemu clean-ups discovered along the way. > > This series is based on Ilias' two series for OF_HOSTFILE and > OF_PRIOR_STAGE removal. > > It is available at u-boot-dm/ofb-working > > [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > Regards, Bin ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-13 1:29 ` [PATCH 00/16] fdt: Make OF_BOARD a boolean option Bin Meng @ 2021-10-13 1:34 ` Tom Rini 2021-10-13 8:02 ` François Ozog 2021-10-13 14:47 ` Simon Glass 2021-10-13 12:39 ` Philippe Mathieu-Daudé 1 sibling, 2 replies; 73+ messages in thread From: Tom Rini @ 2021-10-13 1:34 UTC (permalink / raw) To: Bin Meng Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 2058 bytes --] On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > Hi Simon, > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > 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 at [1]. > > > > 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. > > Adding device trees that are never used sounds like a hack to me. > > For QEMU, device tree is dynamically generated on the fly based on > command line parameters, and the device tree you put in this series > has various hardcoded <phandle> values which normally do not show up > in hand-written dts files. > > I am not sure I understand the whole point of this. I am also confused and do not like the idea of adding device trees for platforms that are capable of and can / do have a device tree to give us at run time. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-13 1:34 ` Tom Rini @ 2021-10-13 8:02 ` François Ozog 2021-10-13 14:47 ` Simon Glass 1 sibling, 0 replies; 73+ messages in thread From: François Ozog @ 2021-10-13 8:02 UTC (permalink / raw) To: Tom Rini Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 2948 bytes --] Hi Simon Le mer. 13 oct. 2021 à 03:35, Tom Rini <trini@konsulko.com> a écrit : > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > Hi Simon, > > > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > > > 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 at [1]. > > > > > > 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. > > > > Adding device trees that are never used sounds like a hack to me. > > > > For QEMU, device tree is dynamically generated on the fly based on > > command line parameters, and the device tree you put in this series > > has various hardcoded <phandle> values which normally do not show up > > in hand-written dts files. > > > > I am not sure I understand the whole point of this. > > I am also confused and do not like the idea of adding device trees for > platforms that are capable of and can / do have a device tree to give us > at run time. > > -- > Tom +1 While the cleanup go get three options, including OF_BOARD is nice, the build solution you propose does not sound the right approach: U-Boot should be buildable without any DT. Getting the DT you produced as sample information can be useful and kept out of build path in documentation with ad-hoc warnings though as I explained in other mails of the series. OF_BOARD is a choice to say “I don’t override the legitimate DT with either OF_SEPARATE or OF_EMBED” (which I see in this case as debug facility for U-Boot maintainer of the platform). > > -- 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: 5627 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-13 1:34 ` Tom Rini 2021-10-13 8:02 ` François Ozog @ 2021-10-13 14:47 ` Simon Glass 2021-10-13 17:34 ` François Ozog 1 sibling, 1 reply; 73+ messages in thread From: Simon Glass @ 2021-10-13 14:47 UTC (permalink / raw) To: Tom Rini Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari Hi Tom, Bin,François, On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > Hi Simon, > > > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > > > 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 at [1]. > > > > > > 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. > > > > Adding device trees that are never used sounds like a hack to me. > > > > For QEMU, device tree is dynamically generated on the fly based on > > command line parameters, and the device tree you put in this series > > has various hardcoded <phandle> values which normally do not show up > > in hand-written dts files. > > > > I am not sure I understand the whole point of this. > > I am also confused and do not like the idea of adding device trees for > platforms that are capable of and can / do have a device tree to give us > at run time. (I'll just reply to this one email, since the same points applies to all replies I think) I have been thinking about this and discussing it with people for a few months now. I've been signalling a change like this for over a month now, on U-Boot contributor calls and in discussions with Linaro people. I sent a patch (below) to try to explain things. I hope it is not a surprise! The issue here is that we need a devicetree in-tree in U-Boot, to avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between Ilias' series and this one we can get ourselves on a stronger footing. There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. For more context: http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ BTW I did suggest to QEMU ARM that they support a way of adding the u-boot.dtsi but there was not much interest there (in fact the maintainer would prefer there was no special support even for booting Linux directly!) But in any case it doesn't really help U-Boot. I think the path forward might be to run QEMU twice, once to get its generated tree and once to give the 'merged' tree with the U-Boot properties in it, if people want to use U-Boot features. I do strongly believe that OF_BOARD must be a run-time option, not a build-time one. It creates all sorts of problems and obscurity which have taken months to unpick. See the above patch for the rationale. To add to that rationale, OF_BOARD needs to be an option available to any board. At some point in the future it may become a common way things are done, e.g. TF-A calling U-Boot and providing a devicetree to it. It doesn't make any sense to have people decide whether or not to set OF_BOARD at build time, thus affecting how the image is put together. We'll end up with different U-Boot build targets like capricorn, capricorn_of_board and the like. It should be obvious where that will lead. Instead, OF_BOARD needs to become a commonly used option, perhaps enabled by most/all boards, so that this sort of build explosion is not needed. U-Boot needs to be flexible enough to function correctly in whatever runtime environment in which it finds itself. Also as binman is pressed into service more and more to build the complex firmware images that are becoming fashionable, it needs a definition (in the devicetree) that describes how to create the image. We can't support that unless we are building a devicetree, nor can the running program access the image layout without that information. François's point about 'don't use this with any kernel' is germane...but of course I am not suggesting doing that, since OF_BOARD is, still, enabled. We already use OF_BOARD for various boards that include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example (as I said in the cover letter "Most boards do provide one, but some don't."). So this series is just completing the picture by enforcing that *some sort* of devicetree is always present. I can't quite pinpoint the patch where U-Boot started allowing the devicetree to be omitted, but if people are interested I could try a little harder. It was certainly not my intention (putting on my device-tree-maintainer hat) to go down that path and it slipped in somehow in all the confusion. I'm not sure anyone could tell you that rpi_3 has an in-tree devicetree but rpi_4 does not... Anyway this series is very modest. It just adds the requirement that all in-tree boards have some sort of sample devicetree and preferably some documentation as to where it might come from at runtime. That should not be a tough call IMO. Assuming we can get the validation in place (mentioned by Rob Herring recently) it will be quite natural to sync them between (presumably) Linux and U-Boot. I am also quite happy to discuss what should actually be in these devicetree files and whether some of them should be essentially empty. As you probably noticed, some of them are empty since I literally could not figure out where they come from! But there needs to be at least some skeleton for U-Boot to progress, since devicetree is critical to its feature set. It is high time we tidied all this up. I predict it will be much harder, and much more confusing, in 6 months. Regards, Simon ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-13 14:47 ` Simon Glass @ 2021-10-13 17:34 ` François Ozog 2021-10-13 18:06 ` Simon Glass 0 siblings, 1 reply; 73+ messages in thread From: François Ozog @ 2021-10-13 17:34 UTC (permalink / raw) To: Simon Glass Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 8047 bytes --] Hi Simon Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > Hi Tom, Bin,François, > > On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > Hi Simon, > > > > > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > > > > > 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 at [1]. > > > > > > > > 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. > > > > > > Adding device trees that are never used sounds like a hack to me. > > > > > > For QEMU, device tree is dynamically generated on the fly based on > > > command line parameters, and the device tree you put in this series > > > has various hardcoded <phandle> values which normally do not show up > > > in hand-written dts files. > > > > > > I am not sure I understand the whole point of this. > > > > I am also confused and do not like the idea of adding device trees for > > platforms that are capable of and can / do have a device tree to give us > > at run time. > > (I'll just reply to this one email, since the same points applies to > all replies I think) > > I have been thinking about this and discussing it with people for a > few months now. I've been signalling a change like this for over a > month now, on U-Boot contributor calls and in discussions with Linaro > people. I sent a patch (below) to try to explain things. I hope it is > not a surprise! > > The issue here is that we need a devicetree in-tree in U-Boot, to > avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > Ilias' series and this one we can get ourselves on a stronger footing. > There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > For more context: > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > BTW I did suggest to QEMU ARM that they support a way of adding the > u-boot.dtsi but there was not much interest there (in fact the > maintainer would prefer there was no special support even for booting > Linux directly!) i understand their point of view and agree with it. > But in any case it doesn't really help U-Boot. I > think the path forward might be to run QEMU twice, once to get its > generated tree and once to give the 'merged' tree with the U-Boot > properties in it, if people want to use U-Boot features. > > I do strongly believe that OF_BOARD must be a run-time option, not a > build-time one. It creates all sorts of problems and obscurity which > have taken months to unpick. See the above patch for the rationale. > > To add to that rationale, OF_BOARD needs to be an option available to > any board. At some point in the future it may become a common way > things are done, e.g. TF-A calling U-Boot and providing a devicetree > to it. It doesn't make any sense to have people decide whether or not > to set OF_BOARD at build time, thus affecting how the image is put > together. We'll end up with different U-Boot build targets like > capricorn, capricorn_of_board and the like. It should be obvious where > that will lead. Instead, OF_BOARD needs to become a commonly used > option, perhaps enabled by most/all boards, so that this sort of build > explosion is not needed. If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. > U-Boot needs to be flexible enough to > function correctly in whatever runtime environment in which it finds > itself. > > Also as binman is pressed into service more and more to build the > complex firmware images that are becoming fashionable, it needs a > definition (in the devicetree) that describes how to create the image. > We can't support that unless we are building a devicetree, nor can the > running program access the image layout without that information. > > François's point about 'don't use this with any kernel' is > germane...but of course I am not suggesting doing that, since OF_BOARD > is, still, enabled. We already use OF_BOARD for various boards that > include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > (as I said in the cover letter "Most boards do provide one, but some > don't."). So this series is just completing the picture by enforcing > that *some sort* of devicetree is always present. > That seems inconsistent with the OF_BOARD becomes the default. > > I can't quite pinpoint the patch where U-Boot started allowing the > devicetree to be omitted, but if people are interested I could try a > little harder. It was certainly not my intention (putting on my > device-tree-maintainer hat) to go down that path and it slipped in > somehow in all the confusion. I'm not sure anyone could tell you that > rpi_3 has an in-tree devicetree but rpi_4 does not... > > Anyway this series is very modest. It just adds the requirement that > all in-tree boards have some sort of sample devicetree and preferably > some documentation as to where it might come from at runtime. That’s a very good goal. But adding files in dts make them not samples but templates to be used and replace board provided DTB. If you push all your DTS files in documentation, you do what you say: adding sample files. > That > should not be a tough call IMO. Assuming we can get the validation in > place (mentioned by Rob Herring recently) it will be quite natural to > sync them between (presumably) Linux and U-Boot. > > I am also quite happy to discuss what should actually be in these > devicetree files and whether some of them should be essentially empty. > As you probably noticed, some of them are empty since I literally > could not figure out where they come from! But there needs to be at > least some skeleton for U-Boot to progress, since devicetree is > critical to its feature set. absolutely. And thank you for your efforts to make that center stage. This is also Linaro Edge group mist challenging task on the next 6 moths. Knowing that we have lived in a floating situation for over 10 years, I just hope we get consensus across projects and distro providers about the right end goal and migration strategy. > > > It is high time we tidied all this up. I predict it will be much > harder, and much more confusing, in 6 months. > > 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: 11368 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-13 17:34 ` François Ozog @ 2021-10-13 18:06 ` Simon Glass 2021-10-14 14:56 ` Tom Rini 2021-10-14 18:12 ` François Ozog 0 siblings, 2 replies; 73+ messages in thread From: Simon Glass @ 2021-10-13 18:06 UTC (permalink / raw) To: François Ozog Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari Hi François, On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: > > Hi Simon > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : >> >> Hi Tom, Bin,François, >> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: >> > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: >> > > Hi Simon, >> > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 >> > > > >> > > > 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 at [1]. >> > > > >> > > > 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. >> > > >> > > Adding device trees that are never used sounds like a hack to me. >> > > >> > > For QEMU, device tree is dynamically generated on the fly based on >> > > command line parameters, and the device tree you put in this series >> > > has various hardcoded <phandle> values which normally do not show up >> > > in hand-written dts files. >> > > >> > > I am not sure I understand the whole point of this. >> > >> > I am also confused and do not like the idea of adding device trees for >> > platforms that are capable of and can / do have a device tree to give us >> > at run time. >> >> (I'll just reply to this one email, since the same points applies to >> all replies I think) >> >> I have been thinking about this and discussing it with people for a >> few months now. I've been signalling a change like this for over a >> month now, on U-Boot contributor calls and in discussions with Linaro >> people. I sent a patch (below) to try to explain things. I hope it is >> not a surprise! >> >> The issue here is that we need a devicetree in-tree in U-Boot, to >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between >> Ilias' series and this one we can get ourselves on a stronger footing. >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. >> For more context: >> >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ >> >> BTW I did suggest to QEMU ARM that they support a way of adding the >> u-boot.dtsi but there was not much interest there (in fact the >> maintainer would prefer there was no special support even for booting >> Linux directly!) > > i understand their point of view and agree with it. >> >> But in any case it doesn't really help U-Boot. I >> think the path forward might be to run QEMU twice, once to get its >> generated tree and once to give the 'merged' tree with the U-Boot >> properties in it, if people want to use U-Boot features. >> >> I do strongly believe that OF_BOARD must be a run-time option, not a >> build-time one. It creates all sorts of problems and obscurity which >> have taken months to unpick. See the above patch for the rationale. >> >> To add to that rationale, OF_BOARD needs to be an option available to >> any board. At some point in the future it may become a common way >> things are done, e.g. TF-A calling U-Boot and providing a devicetree >> to it. It doesn't make any sense to have people decide whether or not >> to set OF_BOARD at build time, thus affecting how the image is put >> together. We'll end up with different U-Boot build targets like >> capricorn, capricorn_of_board and the like. It should be obvious where >> that will lead. Instead, OF_BOARD needs to become a commonly used >> option, perhaps enabled by most/all boards, so that this sort of build >> explosion is not needed. > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. >> >> U-Boot needs to be flexible enough to >> function correctly in whatever runtime environment in which it finds >> itself. >> >> Also as binman is pressed into service more and more to build the >> complex firmware images that are becoming fashionable, it needs a >> definition (in the devicetree) that describes how to create the image. >> We can't support that unless we are building a devicetree, nor can the >> running program access the image layout without that information. >> >> François's point about 'don't use this with any kernel' is >> germane...but of course I am not suggesting doing that, since OF_BOARD >> is, still, enabled. We already use OF_BOARD for various boards that >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example >> (as I said in the cover letter "Most boards do provide one, but some >> don't."). So this series is just completing the picture by enforcing >> that *some sort* of devicetree is always present. > > That seems inconsistent with the OF_BOARD becomes the default. I think the key point that will get you closer to where I am on this issue, is that OF_BOARD needs to be a run-time option. At present it has build-time effects and this is quite wrong. If you go through all the material I have written on this I think I have motivated that very clearly. Another big issue is that I believe we need ONE devicetree for U-Boot, not two that get merged by U-Boot. Again I have gone through that in a lot of detail. >> >> >> I can't quite pinpoint the patch where U-Boot started allowing the >> devicetree to be omitted, but if people are interested I could try a >> little harder. It was certainly not my intention (putting on my >> device-tree-maintainer hat) to go down that path and it slipped in >> somehow in all the confusion. I'm not sure anyone could tell you that >> rpi_3 has an in-tree devicetree but rpi_4 does not... >> >> Anyway this series is very modest. It just adds the requirement that >> all in-tree boards have some sort of sample devicetree and preferably >> some documentation as to where it might come from at runtime. > > That’s a very good goal. But adding files in dts make them not samples but templates to be used and replace board provided DTB. > If you push all your DTS files in documentation, you do what you say: adding sample files. >> >> That >> should not be a tough call IMO. Assuming we can get the validation in >> place (mentioned by Rob Herring recently) it will be quite natural to >> sync them between (presumably) Linux and U-Boot. >> >> I am also quite happy to discuss what should actually be in these >> devicetree files and whether some of them should be essentially empty. >> As you probably noticed, some of them are empty since I literally >> could not figure out where they come from! But there needs to be at >> least some skeleton for U-Boot to progress, since devicetree is >> critical to its feature set. > > absolutely. And thank you for your efforts to make that center stage. This is also Linaro Edge group mist challenging task on the next 6 moths. Knowing that we have lived in a floating situation for over 10 years, I just hope we get consensus across projects and distro providers about the right end goal and migration strategy. >> Thank you. >> >> >> It is high time we tidied all this up. I predict it will be much >> harder, and much more confusing, in 6 months. Just to set a road map here in case you can help unblock anything, here are the things I am aware of, excluding the things I have forgotten: - Ilias OF_PRIOR_STAGE, OF_HOSTFILE series - this series - the devicetree docs patch - devicetree bindings upstream for U-Boot (first patch under discussion) - bloblist as a means of passing devicetree, ACPI, tiny config info as C structs to U-Boot (needs to be written) - VPL so we can handle verification (patches pending) - bootflow / VBE v2 series (coming next week) Regards, Simon ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-13 18:06 ` Simon Glass @ 2021-10-14 14:56 ` Tom Rini 2021-10-14 15:17 ` Simon Glass 2021-10-14 18:12 ` François Ozog 1 sibling, 1 reply; 73+ messages in thread From: Tom Rini @ 2021-10-14 14:56 UTC (permalink / raw) To: Simon Glass Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 7518 bytes --] On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > Hi François, > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: > > > > Hi Simon > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > >> > >> Hi Tom, Bin,François, > >> > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > >> > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > >> > > Hi Simon, > >> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > >> > > > > >> > > > 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 at [1]. > >> > > > > >> > > > 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. > >> > > > >> > > Adding device trees that are never used sounds like a hack to me. > >> > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > >> > > command line parameters, and the device tree you put in this series > >> > > has various hardcoded <phandle> values which normally do not show up > >> > > in hand-written dts files. > >> > > > >> > > I am not sure I understand the whole point of this. > >> > > >> > I am also confused and do not like the idea of adding device trees for > >> > platforms that are capable of and can / do have a device tree to give us > >> > at run time. > >> > >> (I'll just reply to this one email, since the same points applies to > >> all replies I think) > >> > >> I have been thinking about this and discussing it with people for a > >> few months now. I've been signalling a change like this for over a > >> month now, on U-Boot contributor calls and in discussions with Linaro > >> people. I sent a patch (below) to try to explain things. I hope it is > >> not a surprise! > >> > >> The issue here is that we need a devicetree in-tree in U-Boot, to > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > >> Ilias' series and this one we can get ourselves on a stronger footing. > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > >> For more context: > >> > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > >> > >> BTW I did suggest to QEMU ARM that they support a way of adding the > >> u-boot.dtsi but there was not much interest there (in fact the > >> maintainer would prefer there was no special support even for booting > >> Linux directly!) > > > > i understand their point of view and agree with it. > >> > >> But in any case it doesn't really help U-Boot. I > >> think the path forward might be to run QEMU twice, once to get its > >> generated tree and once to give the 'merged' tree with the U-Boot > >> properties in it, if people want to use U-Boot features. > >> > >> I do strongly believe that OF_BOARD must be a run-time option, not a > >> build-time one. It creates all sorts of problems and obscurity which > >> have taken months to unpick. See the above patch for the rationale. > >> > >> To add to that rationale, OF_BOARD needs to be an option available to > >> any board. At some point in the future it may become a common way > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree > >> to it. It doesn't make any sense to have people decide whether or not > >> to set OF_BOARD at build time, thus affecting how the image is put > >> together. We'll end up with different U-Boot build targets like > >> capricorn, capricorn_of_board and the like. It should be obvious where > >> that will lead. Instead, OF_BOARD needs to become a commonly used > >> option, perhaps enabled by most/all boards, so that this sort of build > >> explosion is not needed. > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. > >> > >> U-Boot needs to be flexible enough to > >> function correctly in whatever runtime environment in which it finds > >> itself. > >> > >> Also as binman is pressed into service more and more to build the > >> complex firmware images that are becoming fashionable, it needs a > >> definition (in the devicetree) that describes how to create the image. > >> We can't support that unless we are building a devicetree, nor can the > >> running program access the image layout without that information. > >> > >> François's point about 'don't use this with any kernel' is > >> germane...but of course I am not suggesting doing that, since OF_BOARD > >> is, still, enabled. We already use OF_BOARD for various boards that > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > >> (as I said in the cover letter "Most boards do provide one, but some > >> don't."). So this series is just completing the picture by enforcing > >> that *some sort* of devicetree is always present. > > > > That seems inconsistent with the OF_BOARD becomes the default. > > I think the key point that will get you closer to where I am on this > issue, is that OF_BOARD needs to be a run-time option. At present it > has build-time effects and this is quite wrong. If you go through all > the material I have written on this I think I have motivated that very > clearly. > > Another big issue is that I believe we need ONE devicetree for U-Boot, > not two that get merged by U-Boot. Again I have gone through that in a > lot of detail. I have a long long reply to your first reply here saved, but, maybe here's the biggest sticking point. To be clear, you agree that U-Boot needs to support being passed a device tree to use, at run time, yes? And in that case, would not be using the "fake" tree we built in? So is the sticking point here that we really have two classes of devices, one class where we will never ever be given the device tree at run time (think BeagleBone Black) and one where we will always be given one at run time (think Raspberry Pi) ? -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-14 14:56 ` Tom Rini @ 2021-10-14 15:17 ` Simon Glass 2021-10-14 15:28 ` Tom Rini 2021-10-14 16:24 ` Andre Przywara 0 siblings, 2 replies; 73+ messages in thread From: Simon Glass @ 2021-10-14 15:17 UTC (permalink / raw) To: Tom Rini Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari Hi Tom, On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > Hi François, > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > Hi Simon > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > > >> > > >> Hi Tom, Bin,François, > > >> > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > > >> > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > >> > > Hi Simon, > > >> > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > >> > > > > > >> > > > 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 at [1]. > > >> > > > > > >> > > > 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. > > >> > > > > >> > > Adding device trees that are never used sounds like a hack to me. > > >> > > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > > >> > > command line parameters, and the device tree you put in this series > > >> > > has various hardcoded <phandle> values which normally do not show up > > >> > > in hand-written dts files. > > >> > > > > >> > > I am not sure I understand the whole point of this. > > >> > > > >> > I am also confused and do not like the idea of adding device trees for > > >> > platforms that are capable of and can / do have a device tree to give us > > >> > at run time. > > >> > > >> (I'll just reply to this one email, since the same points applies to > > >> all replies I think) > > >> > > >> I have been thinking about this and discussing it with people for a > > >> few months now. I've been signalling a change like this for over a > > >> month now, on U-Boot contributor calls and in discussions with Linaro > > >> people. I sent a patch (below) to try to explain things. I hope it is > > >> not a surprise! > > >> > > >> The issue here is that we need a devicetree in-tree in U-Boot, to > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > > >> Ilias' series and this one we can get ourselves on a stronger footing. > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > > >> For more context: > > >> > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > >> > > >> BTW I did suggest to QEMU ARM that they support a way of adding the > > >> u-boot.dtsi but there was not much interest there (in fact the > > >> maintainer would prefer there was no special support even for booting > > >> Linux directly!) > > > > > > i understand their point of view and agree with it. > > >> > > >> But in any case it doesn't really help U-Boot. I > > >> think the path forward might be to run QEMU twice, once to get its > > >> generated tree and once to give the 'merged' tree with the U-Boot > > >> properties in it, if people want to use U-Boot features. > > >> > > >> I do strongly believe that OF_BOARD must be a run-time option, not a > > >> build-time one. It creates all sorts of problems and obscurity which > > >> have taken months to unpick. See the above patch for the rationale. > > >> > > >> To add to that rationale, OF_BOARD needs to be an option available to > > >> any board. At some point in the future it may become a common way > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree > > >> to it. It doesn't make any sense to have people decide whether or not > > >> to set OF_BOARD at build time, thus affecting how the image is put > > >> together. We'll end up with different U-Boot build targets like > > >> capricorn, capricorn_of_board and the like. It should be obvious where > > >> that will lead. Instead, OF_BOARD needs to become a commonly used > > >> option, perhaps enabled by most/all boards, so that this sort of build > > >> explosion is not needed. > > > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. > > >> > > >> U-Boot needs to be flexible enough to > > >> function correctly in whatever runtime environment in which it finds > > >> itself. > > >> > > >> Also as binman is pressed into service more and more to build the > > >> complex firmware images that are becoming fashionable, it needs a > > >> definition (in the devicetree) that describes how to create the image. > > >> We can't support that unless we are building a devicetree, nor can the > > >> running program access the image layout without that information. > > >> > > >> François's point about 'don't use this with any kernel' is > > >> germane...but of course I am not suggesting doing that, since OF_BOARD > > >> is, still, enabled. We already use OF_BOARD for various boards that > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > > >> (as I said in the cover letter "Most boards do provide one, but some > > >> don't."). So this series is just completing the picture by enforcing > > >> that *some sort* of devicetree is always present. > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > I think the key point that will get you closer to where I am on this > > issue, is that OF_BOARD needs to be a run-time option. At present it > > has build-time effects and this is quite wrong. If you go through all > > the material I have written on this I think I have motivated that very > > clearly. > > > > Another big issue is that I believe we need ONE devicetree for U-Boot, > > not two that get merged by U-Boot. Again I have gone through that in a > > lot of detail. > > I have a long long reply to your first reply here saved, but, maybe > here's the biggest sticking point. To be clear, you agree that U-Boot > needs to support being passed a device tree to use, at run time, yes? Yes. The OF_BOARD feature provides this. > > And in that case, would not be using the "fake" tree we built in? Not at runtime. > > So is the sticking point here that we really have two classes of > devices, one class where we will never ever be given the device tree at > run time (think BeagleBone Black) and one where we will always be given > one at run time (think Raspberry Pi) ? I'm not sure it will be that black and white. I suspect there will be (many) boards which can boot happily with the U-Boot devicetree but can also accept one at runtime, if provided. For example, you may want to boot with or without TF-A or some other, earlier stage. I believe we have got unstuck because OF_BOARD (perhaps inadvertently) provided a way to entirely omit a devicetree from U-Boot, thus making things like binman and U-Boot /config impossible, for example. So I want to claw that back, so there is always some sort of devicetree in U-Boot, as we have for rpi_3, etc. Regards, Simon ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-14 15:17 ` Simon Glass @ 2021-10-14 15:28 ` Tom Rini 2021-10-14 17:58 ` François Ozog 2021-10-15 18:03 ` Simon Glass 2021-10-14 16:24 ` Andre Przywara 1 sibling, 2 replies; 73+ messages in thread From: Tom Rini @ 2021-10-14 15:28 UTC (permalink / raw) To: Simon Glass Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 10110 bytes --] On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > Hi François, > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > Hi Simon > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > > > >> > > > >> Hi Tom, Bin,François, > > > >> > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > > > >> > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > >> > > Hi Simon, > > > >> > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > >> > > > > > > >> > > > 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 at [1]. > > > >> > > > > > > >> > > > 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. > > > >> > > > > > >> > > Adding device trees that are never used sounds like a hack to me. > > > >> > > > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > > > >> > > command line parameters, and the device tree you put in this series > > > >> > > has various hardcoded <phandle> values which normally do not show up > > > >> > > in hand-written dts files. > > > >> > > > > > >> > > I am not sure I understand the whole point of this. > > > >> > > > > >> > I am also confused and do not like the idea of adding device trees for > > > >> > platforms that are capable of and can / do have a device tree to give us > > > >> > at run time. > > > >> > > > >> (I'll just reply to this one email, since the same points applies to > > > >> all replies I think) > > > >> > > > >> I have been thinking about this and discussing it with people for a > > > >> few months now. I've been signalling a change like this for over a > > > >> month now, on U-Boot contributor calls and in discussions with Linaro > > > >> people. I sent a patch (below) to try to explain things. I hope it is > > > >> not a surprise! > > > >> > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > > > >> Ilias' series and this one we can get ourselves on a stronger footing. > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > > > >> For more context: > > > >> > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > >> > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > >> maintainer would prefer there was no special support even for booting > > > >> Linux directly!) > > > > > > > > i understand their point of view and agree with it. > > > >> > > > >> But in any case it doesn't really help U-Boot. I > > > >> think the path forward might be to run QEMU twice, once to get its > > > >> generated tree and once to give the 'merged' tree with the U-Boot > > > >> properties in it, if people want to use U-Boot features. > > > >> > > > >> I do strongly believe that OF_BOARD must be a run-time option, not a > > > >> build-time one. It creates all sorts of problems and obscurity which > > > >> have taken months to unpick. See the above patch for the rationale. > > > >> > > > >> To add to that rationale, OF_BOARD needs to be an option available to > > > >> any board. At some point in the future it may become a common way > > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree > > > >> to it. It doesn't make any sense to have people decide whether or not > > > >> to set OF_BOARD at build time, thus affecting how the image is put > > > >> together. We'll end up with different U-Boot build targets like > > > >> capricorn, capricorn_of_board and the like. It should be obvious where > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used > > > >> option, perhaps enabled by most/all boards, so that this sort of build > > > >> explosion is not needed. > > > > > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. > > > >> > > > >> U-Boot needs to be flexible enough to > > > >> function correctly in whatever runtime environment in which it finds > > > >> itself. > > > >> > > > >> Also as binman is pressed into service more and more to build the > > > >> complex firmware images that are becoming fashionable, it needs a > > > >> definition (in the devicetree) that describes how to create the image. > > > >> We can't support that unless we are building a devicetree, nor can the > > > >> running program access the image layout without that information. > > > >> > > > >> François's point about 'don't use this with any kernel' is > > > >> germane...but of course I am not suggesting doing that, since OF_BOARD > > > >> is, still, enabled. We already use OF_BOARD for various boards that > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > > > >> (as I said in the cover letter "Most boards do provide one, but some > > > >> don't."). So this series is just completing the picture by enforcing > > > >> that *some sort* of devicetree is always present. > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > I think the key point that will get you closer to where I am on this > > > issue, is that OF_BOARD needs to be a run-time option. At present it > > > has build-time effects and this is quite wrong. If you go through all > > > the material I have written on this I think I have motivated that very > > > clearly. > > > > > > Another big issue is that I believe we need ONE devicetree for U-Boot, > > > not two that get merged by U-Boot. Again I have gone through that in a > > > lot of detail. > > > > I have a long long reply to your first reply here saved, but, maybe > > here's the biggest sticking point. To be clear, you agree that U-Boot > > needs to support being passed a device tree to use, at run time, yes? > > Yes. The OF_BOARD feature provides this. > > > > > And in that case, would not be using the "fake" tree we built in? > > Not at runtime. OK. > > So is the sticking point here that we really have two classes of > > devices, one class where we will never ever be given the device tree at > > run time (think BeagleBone Black) and one where we will always be given > > one at run time (think Raspberry Pi) ? > > I'm not sure it will be that black and white. I suspect there will be > (many) boards which can boot happily with the U-Boot devicetree but > can also accept one at runtime, if provided. For example, you may want > to boot with or without TF-A or some other, earlier stage. I'm not sure I see the value in making this a gray area. There's very much a class of "never" boards. There's also the class of "can" today. Maybe as part of a developer iterative flow it would be nice to not have to re-flash the prior stage to change a DT, and just do it in U-Boot until things are happy, but I'm not sure what the use case is for overriding the previous stage. Especially since the pushback on this series I think has all been "why are we copying in a tree to build with? We don't want to use it at run time!". And then softer push back like "Well, U-Boot says we have to include the device tree file here, but we won't use it...". > I believe we have got unstuck because OF_BOARD (perhaps inadvertently) > provided a way to entirely omit a devicetree from U-Boot, thus making > things like binman and U-Boot /config impossible, for example. So I > want to claw that back, so there is always some sort of devicetree in > U-Boot, as we have for rpi_3, etc. I really want to see what the binary case looks like since we could then kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could then also do a rpi_arm32_defconfig too. I want to see less device trees in U-Boot sources, if they can come functionally correct from the hardware/our caller. And I'm not seeing how we make use of "U-Boot /config" if we also don't use the device tree from build time at run time, ignoring the device tree provided to us at run time by the caller. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-14 15:28 ` Tom Rini @ 2021-10-14 17:58 ` François Ozog 2021-10-15 18:03 ` Simon Glass 1 sibling, 0 replies; 73+ messages in thread From: François Ozog @ 2021-10-14 17:58 UTC (permalink / raw) To: Tom Rini Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 11217 bytes --] Le jeu. 14 oct. 2021 à 17:28, Tom Rini <trini@konsulko.com> a écrit : > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > Hi François, > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > francois.ozog@linaro.org> wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a > écrit : > > > > >> > > > > >> Hi Tom, Bin,François, > > > > >> > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> > wrote: > > > > >> > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > >> > > Hi Simon, > > > > >> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > >> > > > > > > > >> > > > 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 at [1]. > > > > >> > > > > > > > >> > > > 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. > > > > >> > > > > > > >> > > Adding device trees that are never used sounds like a hack to > me. > > > > >> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > based on > > > > >> > > command line parameters, and the device tree you put in this > series > > > > >> > > has various hardcoded <phandle> values which normally do not > show up > > > > >> > > in hand-written dts files. > > > > >> > > > > > > >> > > I am not sure I understand the whole point of this. > > > > >> > > > > > >> > I am also confused and do not like the idea of adding device > trees for > > > > >> > platforms that are capable of and can / do have a device tree > to give us > > > > >> > at run time. > > > > >> > > > > >> (I'll just reply to this one email, since the same points applies > to > > > > >> all replies I think) > > > > >> > > > > >> I have been thinking about this and discussing it with people for > a > > > > >> few months now. I've been signalling a change like this for over a > > > > >> month now, on U-Boot contributor calls and in discussions with > Linaro > > > > >> people. I sent a patch (below) to try to explain things. I hope > it is > > > > >> not a surprise! > > > > >> > > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > > > > >> Ilias' series and this one we can get ourselves on a stronger > footing. > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > > > > >> For more context: > > > > >> > > > > >> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > >> > > > > >> BTW I did suggest to QEMU ARM that they support a way of adding > the > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > >> maintainer would prefer there was no special support even for > booting > > > > >> Linux directly!) > > > > > > > > > > i understand their point of view and agree with it. > > > > >> > > > > >> But in any case it doesn't really help U-Boot. I > > > > >> think the path forward might be to run QEMU twice, once to get its > > > > >> generated tree and once to give the 'merged' tree with the U-Boot > > > > >> properties in it, if people want to use U-Boot features. > > > > >> > > > > >> I do strongly believe that OF_BOARD must be a run-time option, > not a > > > > >> build-time one. It creates all sorts of problems and obscurity > which > > > > >> have taken months to unpick. See the above patch for the > rationale. > > > > >> > > > > >> To add to that rationale, OF_BOARD needs to be an option > available to > > > > >> any board. At some point in the future it may become a common way > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > devicetree > > > > >> to it. It doesn't make any sense to have people decide whether or > not > > > > >> to set OF_BOARD at build time, thus affecting how the image is put > > > > >> together. We'll end up with different U-Boot build targets like > > > > >> capricorn, capricorn_of_board and the like. It should be obvious > where > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used > > > > >> option, perhaps enabled by most/all boards, so that this sort of > build > > > > >> explosion is not needed. > > > > > > > > > > If you mean that when boards are by construction providing a DTB > to U-Boot then I agree very much. But I don’t understand how the patch set > supports it as it puts dts files for those boards to be built. > > > > >> > > > > >> U-Boot needs to be flexible enough to > > > > >> function correctly in whatever runtime environment in which it > finds > > > > >> itself. > > > > >> > > > > >> Also as binman is pressed into service more and more to build the > > > > >> complex firmware images that are becoming fashionable, it needs a > > > > >> definition (in the devicetree) that describes how to create the > image. > > > > >> We can't support that unless we are building a devicetree, nor > can the > > > > >> running program access the image layout without that information. > > > > >> > > > > >> François's point about 'don't use this with any kernel' is > > > > >> germane...but of course I am not suggesting doing that, since > OF_BOARD > > > > >> is, still, enabled. We already use OF_BOARD for various boards > that > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for > example > > > > >> (as I said in the cover letter "Most boards do provide one, but > some > > > > >> don't."). So this series is just completing the picture by > enforcing > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > I think the key point that will get you closer to where I am on this > > > > issue, is that OF_BOARD needs to be a run-time option. At present it > > > > has build-time effects and this is quite wrong. If you go through all > > > > the material I have written on this I think I have motivated that > very > > > > clearly. > > > > > > > > Another big issue is that I believe we need ONE devicetree for > U-Boot, > > > > not two that get merged by U-Boot. Again I have gone through that in > a > > > > lot of detail. > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > here's the biggest sticking point. To be clear, you agree that U-Boot > > > needs to support being passed a device tree to use, at run time, yes? > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > Not at runtime. > > OK. > > > > So is the sticking point here that we really have two classes of > > > devices, one class where we will never ever be given the device tree at > > > run time (think BeagleBone Black) and one where we will always be given > > > one at run time (think Raspberry Pi) ? > > > > I'm not sure it will be that black and white. I suspect there will be > > (many) boards which can boot happily with the U-Boot devicetree but > > can also accept one at runtime, if provided. For example, you may want > > to boot with or without TF-A or some other, earlier stage. > > I'm not sure I see the value in making this a gray area. There's very > much a class of "never" boards. There's also the class of "can" today. > Maybe as part of a developer iterative flow it would be nice to not have > to re-flash the prior stage to change a DT, and just do it in U-Boot > until things are happy, but I'm not sure what the use case is for > overriding the previous stage. > > Especially since the pushback on this series I think has all been "why > are we copying in a tree to build with? We don't want to use it at run > time!". And then softer push back like "Well, U-Boot says we have to > include the device tree file here, but we won't use it...". > > > I believe we have got unstuck because OF_BOARD (perhaps inadvertently) > > provided a way to entirely omit a devicetree from U-Boot, thus making > > things like binman and U-Boot /config impossible, for example. So I > > want to claw that back, so there is always some sort of devicetree in > > U-Boot, as we have for rpi_3, etc. > > I really want to see what the binary case looks like since we could then > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > then also do a rpi_arm32_defconfig too. > > I want to see less device trees in U-Boot sources, if they can come > functionally correct from the hardware/our caller. > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > use the device tree from build time at run time, ignoring the device > tree provided to us at run time by the caller. +1 if there is a complex build problem to solve when no DT is needed when OF_BOARD is needed i could agree to temporarily have a void.dts like /dts-v1/; / { /* required to pass build until proper makefike for OF_BOARD */ }; But not pseudo dts for boards that provide a DT to U-Boot. The pseudo dts are good for reference in the documentation part of the tree. > > -- > Tom > -- 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: 17988 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-14 15:28 ` Tom Rini 2021-10-14 17:58 ` François Ozog @ 2021-10-15 18:03 ` Simon Glass 2021-10-26 6:46 ` Ilias Apalodimas 2021-10-27 12:48 ` Tom Rini 1 sibling, 2 replies; 73+ messages in thread From: Simon Glass @ 2021-10-15 18:03 UTC (permalink / raw) To: Tom Rini Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari Hi all, On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > Hi François, > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > > > > >> > > > > >> Hi Tom, Bin,François, > > > > >> > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > > > > >> > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > >> > > Hi Simon, > > > > >> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > >> > > > > > > > >> > > > 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 at [1]. > > > > >> > > > > > > > >> > > > 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. > > > > >> > > > > > > >> > > Adding device trees that are never used sounds like a hack to me. > > > > >> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > > > > >> > > command line parameters, and the device tree you put in this series > > > > >> > > has various hardcoded <phandle> values which normally do not show up > > > > >> > > in hand-written dts files. > > > > >> > > > > > > >> > > I am not sure I understand the whole point of this. > > > > >> > > > > > >> > I am also confused and do not like the idea of adding device trees for > > > > >> > platforms that are capable of and can / do have a device tree to give us > > > > >> > at run time. > > > > >> > > > > >> (I'll just reply to this one email, since the same points applies to > > > > >> all replies I think) > > > > >> > > > > >> I have been thinking about this and discussing it with people for a > > > > >> few months now. I've been signalling a change like this for over a > > > > >> month now, on U-Boot contributor calls and in discussions with Linaro > > > > >> people. I sent a patch (below) to try to explain things. I hope it is > > > > >> not a surprise! > > > > >> > > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > > > > >> Ilias' series and this one we can get ourselves on a stronger footing. > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > > > > >> For more context: > > > > >> > > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > >> > > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > >> maintainer would prefer there was no special support even for booting > > > > >> Linux directly!) > > > > > > > > > > i understand their point of view and agree with it. > > > > >> > > > > >> But in any case it doesn't really help U-Boot. I > > > > >> think the path forward might be to run QEMU twice, once to get its > > > > >> generated tree and once to give the 'merged' tree with the U-Boot > > > > >> properties in it, if people want to use U-Boot features. > > > > >> > > > > >> I do strongly believe that OF_BOARD must be a run-time option, not a > > > > >> build-time one. It creates all sorts of problems and obscurity which > > > > >> have taken months to unpick. See the above patch for the rationale. > > > > >> > > > > >> To add to that rationale, OF_BOARD needs to be an option available to > > > > >> any board. At some point in the future it may become a common way > > > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree > > > > >> to it. It doesn't make any sense to have people decide whether or not > > > > >> to set OF_BOARD at build time, thus affecting how the image is put > > > > >> together. We'll end up with different U-Boot build targets like > > > > >> capricorn, capricorn_of_board and the like. It should be obvious where > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used > > > > >> option, perhaps enabled by most/all boards, so that this sort of build > > > > >> explosion is not needed. > > > > > > > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. > > > > >> > > > > >> U-Boot needs to be flexible enough to > > > > >> function correctly in whatever runtime environment in which it finds > > > > >> itself. > > > > >> > > > > >> Also as binman is pressed into service more and more to build the > > > > >> complex firmware images that are becoming fashionable, it needs a > > > > >> definition (in the devicetree) that describes how to create the image. > > > > >> We can't support that unless we are building a devicetree, nor can the > > > > >> running program access the image layout without that information. > > > > >> > > > > >> François's point about 'don't use this with any kernel' is > > > > >> germane...but of course I am not suggesting doing that, since OF_BOARD > > > > >> is, still, enabled. We already use OF_BOARD for various boards that > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > > > > >> (as I said in the cover letter "Most boards do provide one, but some > > > > >> don't."). So this series is just completing the picture by enforcing > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > I think the key point that will get you closer to where I am on this > > > > issue, is that OF_BOARD needs to be a run-time option. At present it > > > > has build-time effects and this is quite wrong. If you go through all > > > > the material I have written on this I think I have motivated that very > > > > clearly. > > > > > > > > Another big issue is that I believe we need ONE devicetree for U-Boot, > > > > not two that get merged by U-Boot. Again I have gone through that in a > > > > lot of detail. > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > here's the biggest sticking point. To be clear, you agree that U-Boot > > > needs to support being passed a device tree to use, at run time, yes? > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > Not at runtime. > > OK. > > > > So is the sticking point here that we really have two classes of > > > devices, one class where we will never ever be given the device tree at > > > run time (think BeagleBone Black) and one where we will always be given > > > one at run time (think Raspberry Pi) ? > > > > I'm not sure it will be that black and white. I suspect there will be > > (many) boards which can boot happily with the U-Boot devicetree but > > can also accept one at runtime, if provided. For example, you may want > > to boot with or without TF-A or some other, earlier stage. > > I'm not sure I see the value in making this a gray area. There's very > much a class of "never" boards. There's also the class of "can" today. > Maybe as part of a developer iterative flow it would be nice to not have > to re-flash the prior stage to change a DT, and just do it in U-Boot > until things are happy, but I'm not sure what the use case is for > overriding the previous stage. > > Especially since the pushback on this series I think has all been "why > are we copying in a tree to build with? We don't want to use it at run > time!". And then softer push back like "Well, U-Boot says we have to > include the device tree file here, but we won't use it...". See below. > > > I believe we have got unstuck because OF_BOARD (perhaps inadvertently) > > provided a way to entirely omit a devicetree from U-Boot, thus making > > things like binman and U-Boot /config impossible, for example. So I > > want to claw that back, so there is always some sort of devicetree in > > U-Boot, as we have for rpi_3, etc. > > I really want to see what the binary case looks like since we could then > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > then also do a rpi_arm32_defconfig too. > > I want to see less device trees in U-Boot sources, if they can come > functionally correct from the hardware/our caller. > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > use the device tree from build time at run time, ignoring the device > tree provided to us at run time by the caller. Firstly I should say that I find building firmware very messy and confusing these days. Lots of things to build and it's hard to find the instructions. It doesn't have to be that way, but if we carry on as we are, it will continue to be messy and in five years you will need a Ph.D and a lucky charm to boot on any modern board. My objective here is to simplify things, bringing some consistency to the different components. Binman was one effort there. I feel that putting at least the U-Boot house in order, in my role as devicetree maintainer (and as author of devicetree support in U-Boot back in 2011), is the next step. If we set things up correctly and agree on the bindings, devicetree can be the unifying configuration mechanism through the whole of firmware (except for very early bits) and into the OS, this will set us up very well to deal with the complexity that is coming. Anyway, here are the mental steps that I've gone through over the past two months: Step 1: At present, some people think U-Boot is not even allowed to have its own nodes/properties in the DT. It is an abuse of the devicetree standard, like the /chosen node but with less history. We should sacrifice efficiency, expedience and expandability on the altar of 'devicetree is a hardware description'. How do we get over that one? Wel, I just think we need to accept that U-Boot uses devicetree for its own purposes, as well as for booting the OS. I am not saying it always has to have those properties, but with existing features like verified boot, SPL as well as complex firmware images where U-Boot needs to be able to find things in the image, it is essential. So let's just assume that we need this everywhere, since we certainly need it in at least some places. (stop reading here if you disagree, because nothing below will make any sense...you can still use U-Boot v2011.06 which doesn't have OF_CONTROL :-) Step 2: Assume U-Boot has its own nodes/properties. How do they get there? Well, we have u-boot.dtsi files for that (the 2016 patch "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we have binman definitions, etc. So we need a way to overlay those things into the DT. We already support this for in-tree DTs, so IMO this is easy. Just require every board to have an in-tree DT. It helps with discoverability and documentation, anyway. That is this series. (I think most of us are at the beginning of step 2, unsure about it and worried about step 3) Step 3: Ah, but there are flows (i.e. boards that use a particular flow only, or boards that sometimes use a flow) which need the DT to come from a prior stage. How to handle that? IMO that is only going to grow as every man and his dog get into the write-a-bootloader business. We need a way to provide the U-Boot nodes/properties in a form that the prior stage can consume and integrate with its build system. Is TF-A the only thing being discussed here? If so, let's just do it. We have the u-boot.dtsi and we can use binman to put the image together, for example. Or we can get clever and create some sort of overlay dtb. Step 3a. But I don't want to do that. a) If U-Boot needs this stuff then it will need to build it in and use two devicetrees, one internal and one from the prior stage....well that is not very efficient and it is going to be confusing for people to figure out what U-Boot is actually doing. But we actually already do that in a lot of cases where U-Boot passes a DT to the kernel which is different to the one it uses. So perhaps we have three devicetrees? OMG. b) Well then U-Boot can have its own small devicetree with its bits and then U-Boot can merge the two when it starts. Again that is not very efficient. It means that U-Boot cannot be controlled by the prior stage (e.g. to get its public key from there or to enable/disable the console), so unified firmware config is not possible. It will get very confusing, particularly for debugging U-Boot. c) Some other scheme to avoid accepting step 3...please stop! Step 4: Yes, but there is QEMU, which makes the devicetree up out of whole cloth. What about that? Well, we are just going to have to deal with that. We can easily merge in the U-Boot nodes/properties and update the U-Boot CI scripts to do this, as needed, e.g. with qemu-riscv64_spl. It's only one use case, although Xen might do something similar. To my mind, that deals with both the build-time and run-time issues. We have a discoverable DT in U-Boot, which should be considered the source of truth for most boards. We can sync it with Linux automatically with the tooling that I hope Rob Herring will come up with. We can use an empty one where there really is no default, although I'd argue that is making perfect an enemy of the good. Step 5: If we get clever and want to remove them from the U-Boot tree and pick them up from somewhere else, we can do that with sufficient tooling. Perhaps we should set a timeline for that? A year? Two? Six? To repeat, if we set things up correctly and agree on the bindings, devicetree can be the unifying configuration mechanism through the whole of firmware (except for very early bits) and into the OS. I feel this will set us up very well to deal with the complexity that is coming. Regards, Simon ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-15 18:03 ` Simon Glass @ 2021-10-26 6:46 ` Ilias Apalodimas 2021-10-27 12:59 ` Tom Rini 2021-10-28 2:50 ` Simon Glass 2021-10-27 12:48 ` Tom Rini 1 sibling, 2 replies; 73+ messages in thread From: Ilias Apalodimas @ 2021-10-26 6:46 UTC (permalink / raw) To: Simon Glass Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stephen Warren, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, François Ozog, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari Hi Simon, A bit late to the party, sorry! [...] > > > > I really want to see what the binary case looks like since we could then > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > then also do a rpi_arm32_defconfig too. > > > > I want to see less device trees in U-Boot sources, if they can come > > functionally correct from the hardware/our caller. > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > use the device tree from build time at run time, ignoring the device > > tree provided to us at run time by the caller. > > Firstly I should say that I find building firmware very messy and > confusing these days. Lots of things to build and it's hard to find > the instructions. It doesn't have to be that way, but if we carry on > as we are, it will continue to be messy and in five years you will > need a Ph.D and a lucky charm to boot on any modern board. My > objective here is to simplify things, bringing some consistency to the > different components. Binman was one effort there. I feel that putting > at least the U-Boot house in order, in my role as devicetree > maintainer (and as author of devicetree support in U-Boot back in > 2011), is the next step. > > If we set things up correctly and agree on the bindings, devicetree > can be the unifying configuration mechanism through the whole of > firmware (except for very early bits) and into the OS, this will set > us up very well to deal with the complexity that is coming. > > Anyway, here are the mental steps that I've gone through over the past > two months: > > Step 1: At present, some people think U-Boot is not even allowed to > have its own nodes/properties in the DT. It is an abuse of the > devicetree standard, like the /chosen node but with less history. We > should sacrifice efficiency, expedience and expandability on the altar > of 'devicetree is a hardware description'. How do we get over that > one? Wel, I just think we need to accept that U-Boot uses devicetree > for its own purposes, as well as for booting the OS. I am not saying > it always has to have those properties, but with existing features > like verified boot, SPL as well as complex firmware images where > U-Boot needs to be able to find things in the image, it is essential. > So let's just assume that we need this everywhere, since we certainly > need it in at least some places. > > (stop reading here if you disagree, because nothing below will make > any sense...you can still use U-Boot v2011.06 which doesn't have > OF_CONTROL :-) Having U-Boot keep it's *internal* config state in DTs is fine. Adding that to the DTs that are copied over from linux isn't imho. There are various reasons for that. First of all syncing device trees is a huge pain and that's probably one of the main reasons our DTs are out of sync for a large number of boards. The point is this was fine in 2011 were we had SPL only, but the reality today is completely different. There's previous stage boot loaders (and enough cases were vendors prefer those over SPL). If that bootloader needs to use it's own device tree for whatever reason, imposing restrictions on it wrt to the device tree it has to include, and require them to have knowledge of U-Boot and it's internal config mechanism makes no sense not to mention it doesn't scale at all. > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > there? Well, we have u-boot.dtsi files for that (the 2016 patch > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > have binman definitions, etc. So we need a way to overlay those things > into the DT. We already support this for in-tree DTs, so IMO this is > easy. Just require every board to have an in-tree DT. It helps with > discoverability and documentation, anyway. That is this series. > Again, the board might decide for it's own reason to provide it's own DT. IMHO U-Boot must be able to cope with that and asking DTs to be included in U-Boot source is not the right way to do that, not to mention cases were that's completely unrealistic (e.g QEMU or a board that reads the DTB from it's flash). > (I think most of us are at the beginning of step 2, unsure about it > and worried about step 3) > > Step 3: Ah, but there are flows (i.e. boards that use a particular > flow only, or boards that sometimes use a flow) which need the DT to > come from a prior stage. How to handle that? IMO that is only going to > grow as every man and his dog get into the write-a-bootloader > business. And that's exactly why we have to come up with something that scales, without having to add a bunch of unusable DTs in U-Boot. > We need a way to provide the U-Boot nodes/properties in a > form that the prior stage can consume and integrate with its build > system. Is TF-A the only thing being discussed here? If so, let's just > do it. We have the u-boot.dtsi and we can use binman to put the image > together, for example. Or we can get clever and create some sort of > overlay dtb. > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > then it will need to build it in and use two devicetrees, one internal > and one from the prior stage....well that is not very efficient and it > is going to be confusing for people to figure out what U-Boot is > actually doing. But we actually already do that in a lot of cases > where U-Boot passes a DT to the kernel which is different to the one > it uses. So perhaps we have three devicetrees? OMG. No we don't. That's a moot point. If you separate the DTs U-Boot provides the internal one and inherits one 'generic'. Linux will be able to use that. So the only case were you'll need 3 DTs is if the *vendor* breaks the DT across kernel versions, In which case there's not much you can do to begin with and that's already a case we have to deal with. > b) Well then > U-Boot can have its own small devicetree with its bits and then U-Boot > can merge the two when it starts. Again that is not very efficient. It > means that U-Boot cannot be controlled by the prior stage (e.g. to get > its public key from there or to enable/disable the console), so > unified firmware config is not possible. It will get very confusing, > particularly for debugging U-Boot. c) Some other scheme to avoid > accepting step 3...please stop! > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > whole cloth. What about that? Well, we are just going to have to deal > with that. We can easily merge in the U-Boot nodes/properties and > update the U-Boot CI scripts to do this, as needed, e.g. with > qemu-riscv64_spl. It's only one use case, although Xen might do > something similar. > > To my mind, that deals with both the build-time and run-time issues. > We have a discoverable DT in U-Boot, which should be considered the > source of truth for most boards. We can sync it with Linux > automatically with the tooling that I hope Rob Herring will come up > with. We can use an empty one where there really is no default, > although I'd argue that is making perfect an enemy of the good. > > Step 5: If we get clever and want to remove them from the U-Boot tree > and pick them up from somewhere else, we can do that with sufficient > tooling. Perhaps we should set a timeline for that? A year? Two? Six? We can start slowly migrating boards and see how that works out. We could either use 2 device trees as you proposed, or have u-boot merge the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer if linux gets handed a clean device tree without the u-boot internals in it, so I think 2 discrete DTs is cleaner overall. Regards /Ilias > > To repeat, if we set things up correctly and agree on the bindings, > devicetree can be the unifying configuration mechanism through the > whole of firmware (except for very early bits) and into the OS. I feel > this will set us up very well to deal with the complexity that is > coming. > > Regards, > Simon ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-26 6:46 ` Ilias Apalodimas @ 2021-10-27 12:59 ` Tom Rini 2021-10-27 13:30 ` François Ozog 2021-10-28 2:50 ` Simon Glass 1 sibling, 1 reply; 73+ messages in thread From: Tom Rini @ 2021-10-27 12:59 UTC (permalink / raw) To: Ilias Apalodimas Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 9458 bytes --] On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > Hi Simon, > > A bit late to the party, sorry! > > [...] > > > > > > > I really want to see what the binary case looks like since we could then > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > then also do a rpi_arm32_defconfig too. > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > functionally correct from the hardware/our caller. > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > use the device tree from build time at run time, ignoring the device > > > tree provided to us at run time by the caller. > > > > Firstly I should say that I find building firmware very messy and > > confusing these days. Lots of things to build and it's hard to find > > the instructions. It doesn't have to be that way, but if we carry on > > as we are, it will continue to be messy and in five years you will > > need a Ph.D and a lucky charm to boot on any modern board. My > > objective here is to simplify things, bringing some consistency to the > > different components. Binman was one effort there. I feel that putting > > at least the U-Boot house in order, in my role as devicetree > > maintainer (and as author of devicetree support in U-Boot back in > > 2011), is the next step. > > > > If we set things up correctly and agree on the bindings, devicetree > > can be the unifying configuration mechanism through the whole of > > firmware (except for very early bits) and into the OS, this will set > > us up very well to deal with the complexity that is coming. > > > > Anyway, here are the mental steps that I've gone through over the past > > two months: > > > > Step 1: At present, some people think U-Boot is not even allowed to > > have its own nodes/properties in the DT. It is an abuse of the > > devicetree standard, like the /chosen node but with less history. We > > should sacrifice efficiency, expedience and expandability on the altar > > of 'devicetree is a hardware description'. How do we get over that > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > for its own purposes, as well as for booting the OS. I am not saying > > it always has to have those properties, but with existing features > > like verified boot, SPL as well as complex firmware images where > > U-Boot needs to be able to find things in the image, it is essential. > > So let's just assume that we need this everywhere, since we certainly > > need it in at least some places. > > > > (stop reading here if you disagree, because nothing below will make > > any sense...you can still use U-Boot v2011.06 which doesn't have > > OF_CONTROL :-) > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > that to the DTs that are copied over from linux isn't imho. There are > various reasons for that. First of all syncing device trees is a huge pain > and that's probably one of the main reasons our DTs are out of sync for a > large number of boards. This re-sync is only a pain because: 1. Some platforms have been modifying the core dts files LIKE THEY ARE NOT SUPPOSED TO. 2. DTS files are getting closer to being the super stable API that has been promised now that there's validation tools. Some SoCs, like stm32 are doing an amazing job and keeping things in sync, every release. Others like NXP are violating rule #1. Still others like some TI platforms get bit by #2 (I solved one of these, and need to cycle back to the one you and I talked about on IRC a while back, I bet it's another node name dash changed to underbar). > The point is this was fine in 2011 were we had SPL only, but the reality > today is completely different. There's previous stage boot loaders (and > enough cases were vendors prefer those over SPL). If that bootloader needs > to use it's own device tree for whatever reason, imposing restrictions on > it wrt to the device tree it has to include, and require them to have > knowledge of U-Boot and it's internal config mechanism makes no sense not > to mention it doesn't scale at all. If you are passing the full device tree around, a few more nodes/properties aren't going to make the situation worse. If we're talking about a 60 kilobyte blob one more kilobyte isn't where we call the line, especially since if we wait another 6 months it'll be a 62 kilobyte file coming in from Linux instead. > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > have binman definitions, etc. So we need a way to overlay those things > > into the DT. We already support this for in-tree DTs, so IMO this is > > easy. Just require every board to have an in-tree DT. It helps with > > discoverability and documentation, anyway. That is this series. > > Again, the board might decide for it's own reason to provide it's own DT. > IMHO U-Boot must be able to cope with that and asking DTs to be included in > U-Boot source is not the right way to do that, not to mention cases were > that's completely unrealistic (e.g QEMU or a board that reads the DTB from > it's flash). > > > (I think most of us are at the beginning of step 2, unsure about it > > and worried about step 3) > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > flow only, or boards that sometimes use a flow) which need the DT to > > come from a prior stage. How to handle that? IMO that is only going to > > grow as every man and his dog get into the write-a-bootloader > > business. > > And that's exactly why we have to come up with something that scales, without > having to add a bunch of unusable DTs in U-Boot. Both of these are solved by having our bindings reviewed and upstreamed and then what we need included in the authoritative dts files. > > We need a way to provide the U-Boot nodes/properties in a > > form that the prior stage can consume and integrate with its build > > system. Is TF-A the only thing being discussed here? If so, let's just > > do it. We have the u-boot.dtsi and we can use binman to put the image > > together, for example. Or we can get clever and create some sort of > > overlay dtb. > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > then it will need to build it in and use two devicetrees, one internal > > and one from the prior stage....well that is not very efficient and it > > is going to be confusing for people to figure out what U-Boot is > > actually doing. But we actually already do that in a lot of cases > > where U-Boot passes a DT to the kernel which is different to the one > > it uses. So perhaps we have three devicetrees? OMG. > > No we don't. That's a moot point. If you separate the DTs U-Boot > provides the internal one and inherits one 'generic'. Linux will be able to use > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the > DT across kernel versions, In which case there's not much you can do to > begin with and that's already a case we have to deal with. > > > b) Well then > > U-Boot can have its own small devicetree with its bits and then U-Boot > > can merge the two when it starts. Again that is not very efficient. It > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > its public key from there or to enable/disable the console), so > > unified firmware config is not possible. It will get very confusing, > > particularly for debugging U-Boot. c) Some other scheme to avoid > > accepting step 3...please stop! > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > whole cloth. What about that? Well, we are just going to have to deal > > with that. We can easily merge in the U-Boot nodes/properties and > > update the U-Boot CI scripts to do this, as needed, e.g. with > > qemu-riscv64_spl. It's only one use case, although Xen might do > > something similar. > > > > To my mind, that deals with both the build-time and run-time issues. > > We have a discoverable DT in U-Boot, which should be considered the > > source of truth for most boards. We can sync it with Linux > > automatically with the tooling that I hope Rob Herring will come up > > with. We can use an empty one where there really is no default, > > although I'd argue that is making perfect an enemy of the good. > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > and pick them up from somewhere else, we can do that with sufficient > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > We can start slowly migrating boards and see how that works out. > We could either use 2 device trees as you proposed, or have u-boot merge > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer > if linux gets handed a clean device tree without the u-boot internals in > it, so I think 2 discrete DTs is cleaner overall. Why does it matter if Linux sees some u-boot, properties? If some huge stink is going to be thrown, we could probably prune them out at run time but it's already being passed N disabled nodes, yes? -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 12:59 ` Tom Rini @ 2021-10-27 13:30 ` François Ozog 2021-10-27 13:38 ` Tom Rini 0 siblings, 1 reply; 73+ messages in thread From: François Ozog @ 2021-10-27 13:30 UTC (permalink / raw) To: Tom Rini Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 10787 bytes --] Hi Tom, On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote: > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > > Hi Simon, > > > > A bit late to the party, sorry! > > > > [...] > > > > > > > > > > I really want to see what the binary case looks like since we could > then > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > functionally correct from the hardware/our caller. > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > don't > > > > use the device tree from build time at run time, ignoring the device > > > > tree provided to us at run time by the caller. > > > > > > Firstly I should say that I find building firmware very messy and > > > confusing these days. Lots of things to build and it's hard to find > > > the instructions. It doesn't have to be that way, but if we carry on > > > as we are, it will continue to be messy and in five years you will > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > objective here is to simplify things, bringing some consistency to the > > > different components. Binman was one effort there. I feel that putting > > > at least the U-Boot house in order, in my role as devicetree > > > maintainer (and as author of devicetree support in U-Boot back in > > > 2011), is the next step. > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > can be the unifying configuration mechanism through the whole of > > > firmware (except for very early bits) and into the OS, this will set > > > us up very well to deal with the complexity that is coming. > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > two months: > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > have its own nodes/properties in the DT. It is an abuse of the > > > devicetree standard, like the /chosen node but with less history. We > > > should sacrifice efficiency, expedience and expandability on the altar > > > of 'devicetree is a hardware description'. How do we get over that > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > for its own purposes, as well as for booting the OS. I am not saying > > > it always has to have those properties, but with existing features > > > like verified boot, SPL as well as complex firmware images where > > > U-Boot needs to be able to find things in the image, it is essential. > > > So let's just assume that we need this everywhere, since we certainly > > > need it in at least some places. > > > > > > (stop reading here if you disagree, because nothing below will make > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > OF_CONTROL :-) > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > that to the DTs that are copied over from linux isn't imho. There are > > various reasons for that. First of all syncing device trees is a huge > pain > > and that's probably one of the main reasons our DTs are out of sync for a > > large number of boards. > > This re-sync is only a pain because: > 1. Some platforms have been modifying the core dts files LIKE THEY ARE > NOT SUPPOSED TO. > 2. DTS files are getting closer to being the super stable API that has > been promised now that there's validation tools. > > Some SoCs, like stm32 are doing an amazing job and keeping things in > sync, every release. Others like NXP are violating rule #1. With NXP commitment to SystemReady on some IMX8 boards, I think this is changing, at least for the SystemReady boards. > Still > others like some TI platforms get bit by #2 (I solved one of these, and > need to cycle back to the one you and I talked about on IRC a while > back, I bet it's another node name dash changed to underbar). > > > The point is this was fine in 2011 were we had SPL only, but the reality > > today is completely different. There's previous stage boot loaders (and > > enough cases were vendors prefer those over SPL). If that bootloader > needs > > to use it's own device tree for whatever reason, imposing restrictions > on > > it wrt to the device tree it has to include, and require them to have > > knowledge of U-Boot and it's internal config mechanism makes no sense not > > to mention it doesn't scale at all. > > If you are passing the full device tree around, a few more > nodes/properties aren't going to make the situation worse. If we're > talking about a 60 kilobyte blob one more kilobyte isn't where we call > the line, especially since if we wait another 6 months it'll be a 62 > kilobyte file coming in from Linux instead. > This is not about size but about firmware supply chain organization. > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > have binman definitions, etc. So we need a way to overlay those things > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > easy. Just require every board to have an in-tree DT. It helps with > > > discoverability and documentation, anyway. That is this series. > > > > Again, the board might decide for it's own reason to provide it's own > DT. > > IMHO U-Boot must be able to cope with that and asking DTs to be included > in > > U-Boot source is not the right way to do that, not to mention cases were > > that's completely unrealistic (e.g QEMU or a board that reads the DTB > from > > it's flash). > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > and worried about step 3) > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > flow only, or boards that sometimes use a flow) which need the DT to > > > come from a prior stage. How to handle that? IMO that is only going to > > > grow as every man and his dog get into the write-a-bootloader > > > business. > > > > And that's exactly why we have to come up with something that scales, > without > > having to add a bunch of unusable DTs in U-Boot. > > Both of these are solved by having our bindings reviewed and upstreamed > and then what we need included in the authoritative dts files. > There shall be authoritative System Device Trees as vendors are working on. Those System Device Trees cover all aspects of a board, not just the Cortex-A part that U-Boot cares about. Out of those system device trees, a tool (lopper) is going to carve out the "authoritative dts for the cortex-A". Essentially, that carve out will correspond to what would come out of Linux. This scheme will not be generalized, just adopted by vendors on some boards. DT for those board become part of the OS ABI (meaning, the driver developper is constrained). > > > > We need a way to provide the U-Boot nodes/properties in a > > > form that the prior stage can consume and integrate with its build > > > system. Is TF-A the only thing being discussed here? If so, let's just > > > do it. We have the u-boot.dtsi and we can use binman to put the image > > > together, for example. Or we can get clever and create some sort of > > > overlay dtb. > > > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > > then it will need to build it in and use two devicetrees, one internal > > > and one from the prior stage....well that is not very efficient and it > > > is going to be confusing for people to figure out what U-Boot is > > > actually doing. But we actually already do that in a lot of cases > > > where U-Boot passes a DT to the kernel which is different to the one > > > it uses. So perhaps we have three devicetrees? OMG. > > > > No we don't. That's a moot point. If you separate the DTs U-Boot > > provides the internal one and inherits one 'generic'. Linux will be > able to use > > that. So the only case were you'll need 3 DTs is if the *vendor* breaks > the > > DT across kernel versions, In which case there's not much you can do to > > begin with and that's already a case we have to deal with. > > > > > b) Well then > > > U-Boot can have its own small devicetree with its bits and then U-Boot > > > can merge the two when it starts. Again that is not very efficient. It > > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > > its public key from there or to enable/disable the console), so > > > unified firmware config is not possible. It will get very confusing, > > > particularly for debugging U-Boot. c) Some other scheme to avoid > > > accepting step 3...please stop! > > > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > > whole cloth. What about that? Well, we are just going to have to deal > > > with that. We can easily merge in the U-Boot nodes/properties and > > > update the U-Boot CI scripts to do this, as needed, e.g. with > > > qemu-riscv64_spl. It's only one use case, although Xen might do > > > something similar. > > > > > > To my mind, that deals with both the build-time and run-time issues. > > > We have a discoverable DT in U-Boot, which should be considered the > > > source of truth for most boards. We can sync it with Linux > > > automatically with the tooling that I hope Rob Herring will come up > > > with. We can use an empty one where there really is no default, > > > although I'd argue that is making perfect an enemy of the good. > > > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > > and pick them up from somewhere else, we can do that with sufficient > > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > > > We can start slowly migrating boards and see how that works out. > > We could either use 2 device trees as you proposed, or have u-boot merge > > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd > prefer > > if linux gets handed a clean device tree without the u-boot internals in > > it, so I think 2 discrete DTs is cleaner overall. > > Why does it matter if Linux sees some u-boot, properties? If some huge > stink is going to be thrown, we could probably prune them out at run > time but it's already being passed N disabled nodes, yes? > > -- > Tom > -- 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: 14433 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 13:30 ` François Ozog @ 2021-10-27 13:38 ` Tom Rini 2021-10-27 13:47 ` Ilias Apalodimas 2021-10-27 13:48 ` François Ozog 0 siblings, 2 replies; 73+ messages in thread From: Tom Rini @ 2021-10-27 13:38 UTC (permalink / raw) To: François Ozog Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 8011 bytes --] On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote: > Hi Tom, > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote: > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > > > Hi Simon, > > > > > > A bit late to the party, sorry! > > > > > > [...] > > > > > > > > > > > > > I really want to see what the binary case looks like since we could > > then > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > > don't > > > > > use the device tree from build time at run time, ignoring the device > > > > > tree provided to us at run time by the caller. > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > confusing these days. Lots of things to build and it's hard to find > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > as we are, it will continue to be messy and in five years you will > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > objective here is to simplify things, bringing some consistency to the > > > > different components. Binman was one effort there. I feel that putting > > > > at least the U-Boot house in order, in my role as devicetree > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > 2011), is the next step. > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > can be the unifying configuration mechanism through the whole of > > > > firmware (except for very early bits) and into the OS, this will set > > > > us up very well to deal with the complexity that is coming. > > > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > > two months: > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > have its own nodes/properties in the DT. It is an abuse of the > > > > devicetree standard, like the /chosen node but with less history. We > > > > should sacrifice efficiency, expedience and expandability on the altar > > > > of 'devicetree is a hardware description'. How do we get over that > > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > > for its own purposes, as well as for booting the OS. I am not saying > > > > it always has to have those properties, but with existing features > > > > like verified boot, SPL as well as complex firmware images where > > > > U-Boot needs to be able to find things in the image, it is essential. > > > > So let's just assume that we need this everywhere, since we certainly > > > > need it in at least some places. > > > > > > > > (stop reading here if you disagree, because nothing below will make > > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > > OF_CONTROL :-) > > > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > > that to the DTs that are copied over from linux isn't imho. There are > > > various reasons for that. First of all syncing device trees is a huge > > pain > > > and that's probably one of the main reasons our DTs are out of sync for a > > > large number of boards. > > > > This re-sync is only a pain because: > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE > > NOT SUPPOSED TO. > > 2. DTS files are getting closer to being the super stable API that has > > been promised now that there's validation tools. > > > > Some SoCs, like stm32 are doing an amazing job and keeping things in > > sync, every release. Others like NXP are violating rule #1. > > With NXP commitment to SystemReady on some IMX8 boards, I think this is > changing, > at least for the SystemReady boards. I'd really like to see some progress (as would the other non-NXP folks working on NXP SoCs) in that regard. > > Still > > others like some TI platforms get bit by #2 (I solved one of these, and > > need to cycle back to the one you and I talked about on IRC a while > > back, I bet it's another node name dash changed to underbar). > > > > > The point is this was fine in 2011 were we had SPL only, but the reality > > > today is completely different. There's previous stage boot loaders (and > > > enough cases were vendors prefer those over SPL). If that bootloader > > needs > > > to use it's own device tree for whatever reason, imposing restrictions > > on > > > it wrt to the device tree it has to include, and require them to have > > > knowledge of U-Boot and it's internal config mechanism makes no sense not > > > to mention it doesn't scale at all. > > > > If you are passing the full device tree around, a few more > > nodes/properties aren't going to make the situation worse. If we're > > talking about a 60 kilobyte blob one more kilobyte isn't where we call > > the line, especially since if we wait another 6 months it'll be a 62 > > kilobyte file coming in from Linux instead. > > This is not about size but about firmware supply chain organization. That's great since it means we just need the bindings reviewed then everyone can pass whatever everyone else needs. > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > > have binman definitions, etc. So we need a way to overlay those things > > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > > easy. Just require every board to have an in-tree DT. It helps with > > > > discoverability and documentation, anyway. That is this series. > > > > > > Again, the board might decide for it's own reason to provide it's own > > DT. > > > IMHO U-Boot must be able to cope with that and asking DTs to be included > > in > > > U-Boot source is not the right way to do that, not to mention cases were > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB > > from > > > it's flash). > > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > > and worried about step 3) > > > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > > flow only, or boards that sometimes use a flow) which need the DT to > > > > come from a prior stage. How to handle that? IMO that is only going to > > > > grow as every man and his dog get into the write-a-bootloader > > > > business. > > > > > > And that's exactly why we have to come up with something that scales, > > without > > > having to add a bunch of unusable DTs in U-Boot. > > > > Both of these are solved by having our bindings reviewed and upstreamed > > and then what we need included in the authoritative dts files. > > > There shall be authoritative System Device Trees as vendors are working on. > Those System Device Trees cover all aspects of a board, not just the > Cortex-A part that U-Boot cares about. > Out of those system device trees, a tool (lopper) is going to carve out the > "authoritative dts for the cortex-A". > Essentially, that carve out will correspond to what would come out of Linux. s/Linux/software/ > This scheme will not be generalized, just adopted by vendors on some > boards. > DT for those board become part of the OS ABI (meaning, the driver > developper is constrained). OK? And is going to pick and choose which valid bindings to implement? Or is it going to provide half a node for Linux? No? I assume no. So it will also provide whatever bindings we've upstreamed and say need to be passed. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 13:38 ` Tom Rini @ 2021-10-27 13:47 ` Ilias Apalodimas 2021-10-27 14:26 ` Tom Rini 2021-10-27 13:48 ` François Ozog 1 sibling, 1 reply; 73+ messages in thread From: Ilias Apalodimas @ 2021-10-27 13:47 UTC (permalink / raw) To: Tom Rini Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari Hi trying to reply to all at the same time! On Wed, Oct 27, 2021 at 09:38:40AM -0400, Tom Rini wrote: > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote: > > Hi Tom, > > > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote: > > > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > > > > Hi Simon, > > > > > > > > A bit late to the party, sorry! > > > > > > > > [...] > > > > > > > > > > > > > > > > I really want to see what the binary case looks like since we could > > > then > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > > > don't > > > > > > use the device tree from build time at run time, ignoring the device > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > confusing these days. Lots of things to build and it's hard to find > > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > > as we are, it will continue to be messy and in five years you will > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > objective here is to simplify things, bringing some consistency to the > > > > > different components. Binman was one effort there. I feel that putting > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > 2011), is the next step. > > > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > > can be the unifying configuration mechanism through the whole of > > > > > firmware (except for very early bits) and into the OS, this will set > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > > > two months: > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > > have its own nodes/properties in the DT. It is an abuse of the > > > > > devicetree standard, like the /chosen node but with less history. We > > > > > should sacrifice efficiency, expedience and expandability on the altar > > > > > of 'devicetree is a hardware description'. How do we get over that > > > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > > > for its own purposes, as well as for booting the OS. I am not saying > > > > > it always has to have those properties, but with existing features > > > > > like verified boot, SPL as well as complex firmware images where > > > > > U-Boot needs to be able to find things in the image, it is essential. > > > > > So let's just assume that we need this everywhere, since we certainly > > > > > need it in at least some places. > > > > > > > > > > (stop reading here if you disagree, because nothing below will make > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > > > OF_CONTROL :-) > > > > > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > > > that to the DTs that are copied over from linux isn't imho. There are > > > > various reasons for that. First of all syncing device trees is a huge > > > pain > > > > and that's probably one of the main reasons our DTs are out of sync for a > > > > large number of boards. > > > > > > This re-sync is only a pain because: > > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE > > > NOT SUPPOSED TO. > > > 2. DTS files are getting closer to being the super stable API that has > > > been promised now that there's validation tools. Agree on both, but still this is the reality we have to deal with right now > > > > > > Some SoCs, like stm32 are doing an amazing job and keeping things in > > > sync, every release. Others like NXP are violating rule #1. > > > > With NXP commitment to SystemReady on some IMX8 boards, I think this is > > changing, > > at least for the SystemReady boards. > > I'd really like to see some progress (as would the other non-NXP folks > working on NXP SoCs) in that regard. > > > > Still > > > others like some TI platforms get bit by #2 (I solved one of these, and > > > need to cycle back to the one you and I talked about on IRC a while > > > back, I bet it's another node name dash changed to underbar). > > > > > > > The point is this was fine in 2011 were we had SPL only, but the reality > > > > today is completely different. There's previous stage boot loaders (and > > > > enough cases were vendors prefer those over SPL). If that bootloader > > > needs > > > > to use it's own device tree for whatever reason, imposing restrictions > > > on > > > > it wrt to the device tree it has to include, and require them to have > > > > knowledge of U-Boot and it's internal config mechanism makes no sense not > > > > to mention it doesn't scale at all. > > > > > > If you are passing the full device tree around, a few more > > > nodes/properties aren't going to make the situation worse. If we're > > > talking about a 60 kilobyte blob one more kilobyte isn't where we call > > > the line, especially since if we wait another 6 months it'll be a 62 > > > kilobyte file coming in from Linux instead. > > > > This is not about size but about firmware supply chain organization. > > That's great since it means we just need the bindings reviewed then > everyone can pass whatever everyone else needs. > Size here is not my concern. If the bindings u-boot expects gets upstreamed I am obviously fine with the previous stage bootloader passing them over. What I strongly disagree, is *demand* the previous stage boot loader have knowledge about them if they are not in upstream. > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > > > have binman definitions, etc. So we need a way to overlay those things > > > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > > > easy. Just require every board to have an in-tree DT. It helps with > > > > > discoverability and documentation, anyway. That is this series. > > > > > > > > Again, the board might decide for it's own reason to provide it's own > > > DT. > > > > IMHO U-Boot must be able to cope with that and asking DTs to be included > > > in > > > > U-Boot source is not the right way to do that, not to mention cases were > > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB > > > from > > > > it's flash). > > > > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > > > and worried about step 3) > > > > > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > > > flow only, or boards that sometimes use a flow) which need the DT to > > > > > come from a prior stage. How to handle that? IMO that is only going to > > > > > grow as every man and his dog get into the write-a-bootloader > > > > > business. > > > > > > > > And that's exactly why we have to come up with something that scales, > > > without > > > > having to add a bunch of unusable DTs in U-Boot. > > > > > > Both of these are solved by having our bindings reviewed and upstreamed > > > and then what we need included in the authoritative dts files. > > > yes > > There shall be authoritative System Device Trees as vendors are working on. > > Those System Device Trees cover all aspects of a board, not just the > > Cortex-A part that U-Boot cares about. > > Out of those system device trees, a tool (lopper) is going to carve out the > > "authoritative dts for the cortex-A". > > Essentially, that carve out will correspond to what would come out of Linux. > > s/Linux/software/ > > > This scheme will not be generalized, just adopted by vendors on some > > boards. > > DT for those board become part of the OS ABI (meaning, the driver > > developper is constrained). > > OK? And is going to pick and choose which valid bindings to implement? > Or is it going to provide half a node for Linux? No? I assume no. So > it will also provide whatever bindings we've upstreamed and say need to > be passed. > > -- > Tom Regards /Ilias ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 13:47 ` Ilias Apalodimas @ 2021-10-27 14:26 ` Tom Rini 0 siblings, 0 replies; 73+ messages in thread From: Tom Rini @ 2021-10-27 14:26 UTC (permalink / raw) To: Ilias Apalodimas Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 6954 bytes --] On Wed, Oct 27, 2021 at 04:47:55PM +0300, Ilias Apalodimas wrote: > Hi trying to reply to all at the same time! > > On Wed, Oct 27, 2021 at 09:38:40AM -0400, Tom Rini wrote: > > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote: > > > Hi Tom, > > > > > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > > > > > Hi Simon, > > > > > > > > > > A bit late to the party, sorry! > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > I really want to see what the binary case looks like since we could > > > > then > > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > > > > don't > > > > > > > use the device tree from build time at run time, ignoring the device > > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > > confusing these days. Lots of things to build and it's hard to find > > > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > > > as we are, it will continue to be messy and in five years you will > > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > > objective here is to simplify things, bringing some consistency to the > > > > > > different components. Binman was one effort there. I feel that putting > > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > > 2011), is the next step. > > > > > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > > > can be the unifying configuration mechanism through the whole of > > > > > > firmware (except for very early bits) and into the OS, this will set > > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > > > > two months: > > > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > > > have its own nodes/properties in the DT. It is an abuse of the > > > > > > devicetree standard, like the /chosen node but with less history. We > > > > > > should sacrifice efficiency, expedience and expandability on the altar > > > > > > of 'devicetree is a hardware description'. How do we get over that > > > > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > > > > for its own purposes, as well as for booting the OS. I am not saying > > > > > > it always has to have those properties, but with existing features > > > > > > like verified boot, SPL as well as complex firmware images where > > > > > > U-Boot needs to be able to find things in the image, it is essential. > > > > > > So let's just assume that we need this everywhere, since we certainly > > > > > > need it in at least some places. > > > > > > > > > > > > (stop reading here if you disagree, because nothing below will make > > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > > > > OF_CONTROL :-) > > > > > > > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > > > > that to the DTs that are copied over from linux isn't imho. There are > > > > > various reasons for that. First of all syncing device trees is a huge > > > > pain > > > > > and that's probably one of the main reasons our DTs are out of sync for a > > > > > large number of boards. > > > > > > > > This re-sync is only a pain because: > > > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE > > > > NOT SUPPOSED TO. > > > > 2. DTS files are getting closer to being the super stable API that has > > > > been promised now that there's validation tools. > > Agree on both, but still this is the reality we have to deal with right now > > > > > > > > > Some SoCs, like stm32 are doing an amazing job and keeping things in > > > > sync, every release. Others like NXP are violating rule #1. > > > > > > With NXP commitment to SystemReady on some IMX8 boards, I think this is > > > changing, > > > at least for the SystemReady boards. > > > > I'd really like to see some progress (as would the other non-NXP folks > > working on NXP SoCs) in that regard. > > > > > > Still > > > > others like some TI platforms get bit by #2 (I solved one of these, and > > > > need to cycle back to the one you and I talked about on IRC a while > > > > back, I bet it's another node name dash changed to underbar). > > > > > > > > > The point is this was fine in 2011 were we had SPL only, but the reality > > > > > today is completely different. There's previous stage boot loaders (and > > > > > enough cases were vendors prefer those over SPL). If that bootloader > > > > needs > > > > > to use it's own device tree for whatever reason, imposing restrictions > > > > on > > > > > it wrt to the device tree it has to include, and require them to have > > > > > knowledge of U-Boot and it's internal config mechanism makes no sense not > > > > > to mention it doesn't scale at all. > > > > > > > > If you are passing the full device tree around, a few more > > > > nodes/properties aren't going to make the situation worse. If we're > > > > talking about a 60 kilobyte blob one more kilobyte isn't where we call > > > > the line, especially since if we wait another 6 months it'll be a 62 > > > > kilobyte file coming in from Linux instead. > > > > > > This is not about size but about firmware supply chain organization. > > > > That's great since it means we just need the bindings reviewed then > > everyone can pass whatever everyone else needs. > > > > Size here is not my concern. If the bindings u-boot expects gets > upstreamed I am obviously fine with the previous stage bootloader passing > them over. What I strongly disagree, is *demand* the previous stage boot > loader have knowledge about them if they are not in upstream. I also agree that bindings MUST be upstreamed for there to be a reasonable expectation that any other project (or human creating a dts) be adding them, either statically or any sort of run-time modification (think memory information, this gets fixed up at run-time often still). And it may end up being zero "u-boot,FOO" bindings where this is the case. Or it may end up being related to secure / verified boot stuff only. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 13:38 ` Tom Rini 2021-10-27 13:47 ` Ilias Apalodimas @ 2021-10-27 13:48 ` François Ozog 2021-10-27 14:30 ` Tom Rini 1 sibling, 1 reply; 73+ messages in thread From: François Ozog @ 2021-10-27 13:48 UTC (permalink / raw) To: Tom Rini Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 9257 bytes --] On Wed, 27 Oct 2021 at 15:38, Tom Rini <trini@konsulko.com> wrote: > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote: > > Hi Tom, > > > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote: > > > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > > > > Hi Simon, > > > > > > > > A bit late to the party, sorry! > > > > > > > > [...] > > > > > > > > > > > > > > > > I really want to see what the binary case looks like since we > could > > > then > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > could > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can > come > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > > > don't > > > > > > use the device tree from build time at run time, ignoring the > device > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > confusing these days. Lots of things to build and it's hard to find > > > > > the instructions. It doesn't have to be that way, but if we carry > on > > > > > as we are, it will continue to be messy and in five years you will > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > objective here is to simplify things, bringing some consistency to > the > > > > > different components. Binman was one effort there. I feel that > putting > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > 2011), is the next step. > > > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > > can be the unifying configuration mechanism through the whole of > > > > > firmware (except for very early bits) and into the OS, this will > set > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the > past > > > > > two months: > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > > have its own nodes/properties in the DT. It is an abuse of the > > > > > devicetree standard, like the /chosen node but with less history. > We > > > > > should sacrifice efficiency, expedience and expandability on the > altar > > > > > of 'devicetree is a hardware description'. How do we get over that > > > > > one? Wel, I just think we need to accept that U-Boot uses > devicetree > > > > > for its own purposes, as well as for booting the OS. I am not > saying > > > > > it always has to have those properties, but with existing features > > > > > like verified boot, SPL as well as complex firmware images where > > > > > U-Boot needs to be able to find things in the image, it is > essential. > > > > > So let's just assume that we need this everywhere, since we > certainly > > > > > need it in at least some places. > > > > > > > > > > (stop reading here if you disagree, because nothing below will make > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > > > OF_CONTROL :-) > > > > > > > > Having U-Boot keep it's *internal* config state in DTs is fine. > Adding > > > > that to the DTs that are copied over from linux isn't imho. There > are > > > > various reasons for that. First of all syncing device trees is a > huge > > > pain > > > > and that's probably one of the main reasons our DTs are out of sync > for a > > > > large number of boards. > > > > > > This re-sync is only a pain because: > > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE > > > NOT SUPPOSED TO. > > > 2. DTS files are getting closer to being the super stable API that has > > > been promised now that there's validation tools. > > > > > > Some SoCs, like stm32 are doing an amazing job and keeping things in > > > sync, every release. Others like NXP are violating rule #1. > > > > With NXP commitment to SystemReady on some IMX8 boards, I think this is > > changing, > > at least for the SystemReady boards. > > I'd really like to see some progress (as would the other non-NXP folks > working on NXP SoCs) in that regard. > > > > Still > > > others like some TI platforms get bit by #2 (I solved one of these, and > > > need to cycle back to the one you and I talked about on IRC a while > > > back, I bet it's another node name dash changed to underbar). > > > > > > > The point is this was fine in 2011 were we had SPL only, but the > reality > > > > today is completely different. There's previous stage boot loaders > (and > > > > enough cases were vendors prefer those over SPL). If that bootloader > > > needs > > > > to use it's own device tree for whatever reason, imposing > restrictions > > > on > > > > it wrt to the device tree it has to include, and require them to > have > > > > knowledge of U-Boot and it's internal config mechanism makes no > sense not > > > > to mention it doesn't scale at all. > > > > > > If you are passing the full device tree around, a few more > > > nodes/properties aren't going to make the situation worse. If we're > > > talking about a 60 kilobyte blob one more kilobyte isn't where we call > > > the line, especially since if we wait another 6 months it'll be a 62 > > > kilobyte file coming in from Linux instead. > > > > This is not about size but about firmware supply chain organization. > > That's great since it means we just need the bindings reviewed then > everyone can pass whatever everyone else needs. > > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), > we > > > > > have binman definitions, etc. So we need a way to overlay those > things > > > > > into the DT. We already support this for in-tree DTs, so IMO this > is > > > > > easy. Just require every board to have an in-tree DT. It helps with > > > > > discoverability and documentation, anyway. That is this series. > > > > > > > > Again, the board might decide for it's own reason to provide it's own > > > DT. > > > > IMHO U-Boot must be able to cope with that and asking DTs to be > included > > > in > > > > U-Boot source is not the right way to do that, not to mention cases > were > > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB > > > from > > > > it's flash). > > > > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > > > and worried about step 3) > > > > > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > > > flow only, or boards that sometimes use a flow) which need the DT > to > > > > > come from a prior stage. How to handle that? IMO that is only > going to > > > > > grow as every man and his dog get into the write-a-bootloader > > > > > business. > > > > > > > > And that's exactly why we have to come up with something that scales, > > > without > > > > having to add a bunch of unusable DTs in U-Boot. > > > > > > Both of these are solved by having our bindings reviewed and upstreamed > > > and then what we need included in the authoritative dts files. > > > > > There shall be authoritative System Device Trees as vendors are working > on. > > Those System Device Trees cover all aspects of a board, not just the > > Cortex-A part that U-Boot cares about. > > Out of those system device trees, a tool (lopper) is going to carve out > the > > "authoritative dts for the cortex-A". > > Essentially, that carve out will correspond to what would come out of > Linux. > > s/Linux/software/ > > > This scheme will not be generalized, just adopted by vendors on some > > boards. > > DT for those board become part of the OS ABI (meaning, the driver > > developper is constrained). > > OK? And is going to pick and choose which valid bindings to implement? > Or is it going to provide half a node for Linux? No? I assume no. So > it will also provide whatever bindings we've upstreamed and say need to > be passed. > Until we can agree on a better scheme, Linux will server as the basis for most of the bindings. Some projects, like TF-A maintain their own bindings specifications. I guess U-Boot shall do the same. The U-Boot DT (for properties or whatever purpose) can be stored in a various of U-Boot decided ways and as part of the TF-A FIP image in the ad-hoc section: NT_FW_CONFIG. Passing FIP information to U-Boot to retrieve the NF_FW_CONFIG should be part of the blob_list discussion that started a while ago. For System Device Tree, the bindings and the master repo will be maintained in devicetree.org (AFAIK). > > -- > Tom > -- 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: 12982 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 13:48 ` François Ozog @ 2021-10-27 14:30 ` Tom Rini 0 siblings, 0 replies; 73+ messages in thread From: Tom Rini @ 2021-10-27 14:30 UTC (permalink / raw) To: François Ozog Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 10081 bytes --] On Wed, Oct 27, 2021 at 03:48:48PM +0200, François Ozog wrote: > On Wed, 27 Oct 2021 at 15:38, Tom Rini <trini@konsulko.com> wrote: > > > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote: > > > Hi Tom, > > > > > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > > > > > Hi Simon, > > > > > > > > > > A bit late to the party, sorry! > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > I really want to see what the binary case looks like since we > > could > > > > then > > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > > could > > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can > > come > > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > > > > don't > > > > > > > use the device tree from build time at run time, ignoring the > > device > > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > > confusing these days. Lots of things to build and it's hard to find > > > > > > the instructions. It doesn't have to be that way, but if we carry > > on > > > > > > as we are, it will continue to be messy and in five years you will > > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > > objective here is to simplify things, bringing some consistency to > > the > > > > > > different components. Binman was one effort there. I feel that > > putting > > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > > 2011), is the next step. > > > > > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > > > can be the unifying configuration mechanism through the whole of > > > > > > firmware (except for very early bits) and into the OS, this will > > set > > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the > > past > > > > > > two months: > > > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > > > have its own nodes/properties in the DT. It is an abuse of the > > > > > > devicetree standard, like the /chosen node but with less history. > > We > > > > > > should sacrifice efficiency, expedience and expandability on the > > altar > > > > > > of 'devicetree is a hardware description'. How do we get over that > > > > > > one? Wel, I just think we need to accept that U-Boot uses > > devicetree > > > > > > for its own purposes, as well as for booting the OS. I am not > > saying > > > > > > it always has to have those properties, but with existing features > > > > > > like verified boot, SPL as well as complex firmware images where > > > > > > U-Boot needs to be able to find things in the image, it is > > essential. > > > > > > So let's just assume that we need this everywhere, since we > > certainly > > > > > > need it in at least some places. > > > > > > > > > > > > (stop reading here if you disagree, because nothing below will make > > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > > > > OF_CONTROL :-) > > > > > > > > > > Having U-Boot keep it's *internal* config state in DTs is fine. > > Adding > > > > > that to the DTs that are copied over from linux isn't imho. There > > are > > > > > various reasons for that. First of all syncing device trees is a > > huge > > > > pain > > > > > and that's probably one of the main reasons our DTs are out of sync > > for a > > > > > large number of boards. > > > > > > > > This re-sync is only a pain because: > > > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE > > > > NOT SUPPOSED TO. > > > > 2. DTS files are getting closer to being the super stable API that has > > > > been promised now that there's validation tools. > > > > > > > > Some SoCs, like stm32 are doing an amazing job and keeping things in > > > > sync, every release. Others like NXP are violating rule #1. > > > > > > With NXP commitment to SystemReady on some IMX8 boards, I think this is > > > changing, > > > at least for the SystemReady boards. > > > > I'd really like to see some progress (as would the other non-NXP folks > > working on NXP SoCs) in that regard. > > > > > > Still > > > > others like some TI platforms get bit by #2 (I solved one of these, and > > > > need to cycle back to the one you and I talked about on IRC a while > > > > back, I bet it's another node name dash changed to underbar). > > > > > > > > > The point is this was fine in 2011 were we had SPL only, but the > > reality > > > > > today is completely different. There's previous stage boot loaders > > (and > > > > > enough cases were vendors prefer those over SPL). If that bootloader > > > > needs > > > > > to use it's own device tree for whatever reason, imposing > > restrictions > > > > on > > > > > it wrt to the device tree it has to include, and require them to > > have > > > > > knowledge of U-Boot and it's internal config mechanism makes no > > sense not > > > > > to mention it doesn't scale at all. > > > > > > > > If you are passing the full device tree around, a few more > > > > nodes/properties aren't going to make the situation worse. If we're > > > > talking about a 60 kilobyte blob one more kilobyte isn't where we call > > > > the line, especially since if we wait another 6 months it'll be a 62 > > > > kilobyte file coming in from Linux instead. > > > > > > This is not about size but about firmware supply chain organization. > > > > That's great since it means we just need the bindings reviewed then > > everyone can pass whatever everyone else needs. > > > > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), > > we > > > > > > have binman definitions, etc. So we need a way to overlay those > > things > > > > > > into the DT. We already support this for in-tree DTs, so IMO this > > is > > > > > > easy. Just require every board to have an in-tree DT. It helps with > > > > > > discoverability and documentation, anyway. That is this series. > > > > > > > > > > Again, the board might decide for it's own reason to provide it's own > > > > DT. > > > > > IMHO U-Boot must be able to cope with that and asking DTs to be > > included > > > > in > > > > > U-Boot source is not the right way to do that, not to mention cases > > were > > > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB > > > > from > > > > > it's flash). > > > > > > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > > > > and worried about step 3) > > > > > > > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > > > > flow only, or boards that sometimes use a flow) which need the DT > > to > > > > > > come from a prior stage. How to handle that? IMO that is only > > going to > > > > > > grow as every man and his dog get into the write-a-bootloader > > > > > > business. > > > > > > > > > > And that's exactly why we have to come up with something that scales, > > > > without > > > > > having to add a bunch of unusable DTs in U-Boot. > > > > > > > > Both of these are solved by having our bindings reviewed and upstreamed > > > > and then what we need included in the authoritative dts files. > > > > > > > There shall be authoritative System Device Trees as vendors are working > > on. > > > Those System Device Trees cover all aspects of a board, not just the > > > Cortex-A part that U-Boot cares about. > > > Out of those system device trees, a tool (lopper) is going to carve out > > the > > > "authoritative dts for the cortex-A". > > > Essentially, that carve out will correspond to what would come out of > > Linux. > > > > s/Linux/software/ > > > > > This scheme will not be generalized, just adopted by vendors on some > > > boards. > > > DT for those board become part of the OS ABI (meaning, the driver > > > developper is constrained). > > > > OK? And is going to pick and choose which valid bindings to implement? > > Or is it going to provide half a node for Linux? No? I assume no. So > > it will also provide whatever bindings we've upstreamed and say need to > > be passed. > > > Until we can agree on a better scheme, Linux will server as the basis for > most of the bindings. Yes, this is the de-facto standard since the beginning. > Some projects, like TF-A maintain their own bindings specifications. I And as I keep saying I believe this to be totally wrong. Unless and only unless the TF-A bindings are for TF-A only to care about, and then it's just one-off do what you guys want non-standard stuff. > guess U-Boot shall do the same. No, U-Boot is going to upstream the bindings that we want to have be considered official. > The U-Boot DT (for properties or whatever purpose) can be stored in a > various of U-Boot decided ways and as part of the TF-A FIP image in the > ad-hoc section: NT_FW_CONFIG. Passing FIP information to U-Boot to retrieve > the NF_FW_CONFIG should be part of the blob_list discussion that started a > while ago. Yes, we'll have to see where things progress about what bindings are needed, and where. > For System Device Tree, the bindings and the master repo will be maintained > in devicetree.org (AFAIK). Interesting, okay. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-26 6:46 ` Ilias Apalodimas 2021-10-27 12:59 ` Tom Rini @ 2021-10-28 2:50 ` Simon Glass 2021-10-28 8:21 ` François Ozog 2021-11-01 11:04 ` Ilias Apalodimas 1 sibling, 2 replies; 73+ messages in thread From: Simon Glass @ 2021-10-28 2:50 UTC (permalink / raw) To: Ilias Apalodimas Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stephen Warren, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, François Ozog, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari Hi Ilias, On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > Hi Simon, > > A bit late to the party, sorry! (Did you remember the beer? I am replying to this but I don't think it is all that helpful for me to reply to a lot of things on this thread, since I would not be adding much to my cover letter and patches) > > [...] > > > > > > > I really want to see what the binary case looks like since we could then > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > then also do a rpi_arm32_defconfig too. > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > functionally correct from the hardware/our caller. > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > use the device tree from build time at run time, ignoring the device > > > tree provided to us at run time by the caller. > > > > Firstly I should say that I find building firmware very messy and > > confusing these days. Lots of things to build and it's hard to find > > the instructions. It doesn't have to be that way, but if we carry on > > as we are, it will continue to be messy and in five years you will > > need a Ph.D and a lucky charm to boot on any modern board. My > > objective here is to simplify things, bringing some consistency to the > > different components. Binman was one effort there. I feel that putting > > at least the U-Boot house in order, in my role as devicetree > > maintainer (and as author of devicetree support in U-Boot back in > > 2011), is the next step. > > > > If we set things up correctly and agree on the bindings, devicetree > > can be the unifying configuration mechanism through the whole of > > firmware (except for very early bits) and into the OS, this will set > > us up very well to deal with the complexity that is coming. > > > > Anyway, here are the mental steps that I've gone through over the past > > two months: > > > > Step 1: At present, some people think U-Boot is not even allowed to > > have its own nodes/properties in the DT. It is an abuse of the > > devicetree standard, like the /chosen node but with less history. We > > should sacrifice efficiency, expedience and expandability on the altar > > of 'devicetree is a hardware description'. How do we get over that > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > for its own purposes, as well as for booting the OS. I am not saying > > it always has to have those properties, but with existing features > > like verified boot, SPL as well as complex firmware images where > > U-Boot needs to be able to find things in the image, it is essential. > > So let's just assume that we need this everywhere, since we certainly > > need it in at least some places. > > > > (stop reading here if you disagree, because nothing below will make > > any sense...you can still use U-Boot v2011.06 which doesn't have > > OF_CONTROL :-) > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > that to the DTs that are copied over from linux isn't imho. There are > various reasons for that. First of all syncing device trees is a huge pain > and that's probably one of the main reasons our DTs are out of sync for a > large number of boards. > The point is this was fine in 2011 were we had SPL only, but the reality > today is completely different. There's previous stage boot loaders (and > enough cases were vendors prefer those over SPL). If that bootloader needs > to use it's own device tree for whatever reason, imposing restrictions on > it wrt to the device tree it has to include, and require them to have > knowledge of U-Boot and it's internal config mechanism makes no sense not > to mention it doesn't scale at all. I think the solution here may be the binman image packer. It works from a description of the image (i.e. is data-driver) and can collect all the pieces together. The U-Boot properties (and the ones required by TF-A, etc.) can be added at package time. If you think about it, it doesn't matter what properties are in the DT that is put into the firmware image. TF-A, for example, is presumably reading a devicetree from flash, so what does it care if it has some U-Boot properties in it? As to syncing, we have solved this using u-boot.dtsi files in U-Boot, so I think this can be dealt with. > > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > have binman definitions, etc. So we need a way to overlay those things > > into the DT. We already support this for in-tree DTs, so IMO this is > > easy. Just require every board to have an in-tree DT. It helps with > > discoverability and documentation, anyway. That is this series. > > > > Again, the board might decide for it's own reason to provide it's own DT. > IMHO U-Boot must be able to cope with that and asking DTs to be included in > U-Boot source is not the right way to do that, not to mention cases were > that's completely unrealistic (e.g QEMU or a board that reads the DTB from > it's flash). I think you are at step 2. See above for my response. > > > (I think most of us are at the beginning of step 2, unsure about it > > and worried about step 3) > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > flow only, or boards that sometimes use a flow) which need the DT to > > come from a prior stage. How to handle that? IMO that is only going to > > grow as every man and his dog get into the write-a-bootloader > > business. > > And that's exactly why we have to come up with something that scales, without > having to add a bunch of unusable DTs in U-Boot. In what way does this not scale? How are the DTs unusable? If there is a standard binding, we should be fine. > > > We need a way to provide the U-Boot nodes/properties in a > > form that the prior stage can consume and integrate with its build > > system. Is TF-A the only thing being discussed here? If so, let's just > > do it. We have the u-boot.dtsi and we can use binman to put the image > > together, for example. Or we can get clever and create some sort of > > overlay dtb. > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > then it will need to build it in and use two devicetrees, one internal > > and one from the prior stage....well that is not very efficient and it > > is going to be confusing for people to figure out what U-Boot is > > actually doing. But we actually already do that in a lot of cases > > where U-Boot passes a DT to the kernel which is different to the one > > it uses. So perhaps we have three devicetrees? OMG. > > No we don't. That's a moot point. If you separate the DTs U-Boot > provides the internal one and inherits one 'generic'. Linux will be able to use > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the > DT across kernel versions, In which case there's not much you can do to > begin with and that's already a case we have to deal with. Linux actually doesn't care if the U-Boot properties are in the tree, so long as we have proper bindings. My point here is we only need either: a. one devicetree, shared with Linux and U-Boot (and TF-A?) b. two devicetrees, one for use in firmware and one for passing to Linux We don't need to separate out the U-Boot properties into a second (or third) devicetree. There just isn't any point. > > > b) Well then > > U-Boot can have its own small devicetree with its bits and then U-Boot > > can merge the two when it starts. Again that is not very efficient. It > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > its public key from there or to enable/disable the console), so > > unified firmware config is not possible. It will get very confusing, > > particularly for debugging U-Boot. c) Some other scheme to avoid > > accepting step 3...please stop! > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > whole cloth. What about that? Well, we are just going to have to deal > > with that. We can easily merge in the U-Boot nodes/properties and > > update the U-Boot CI scripts to do this, as needed, e.g. with > > qemu-riscv64_spl. It's only one use case, although Xen might do > > something similar. > > > > To my mind, that deals with both the build-time and run-time issues. > > We have a discoverable DT in U-Boot, which should be considered the > > source of truth for most boards. We can sync it with Linux > > automatically with the tooling that I hope Rob Herring will come up > > with. We can use an empty one where there really is no default, > > although I'd argue that is making perfect an enemy of the good. > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > and pick them up from somewhere else, we can do that with sufficient > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > We can start slowly migrating boards and see how that works out. > We could either use 2 device trees as you proposed, or have u-boot merge > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer > if linux gets handed a clean device tree without the u-boot internals in > it, so I think 2 discrete DTs is cleaner overall. I know you would prefer that, but does it really matter in practice? What is the objection, actually? As I mentioned on the call, I think the prior stage should do any merging or fixing up. Trying to do that sort of thing in 'early' code in U-Boot (or any other program, including Linux) is such a pain. With U-Boot, for example, we don't even have any RAM available to do it with half the time and it would dramatically increase the amount of memory needed prior to relocation. It just isn't a very good idea to try to do this in early code. It is also completely unnecessary, once you get past the philosophical objections. If TF-A wants to be in the picture, let it deal with the implications and responsibility thus incurred. TF-A has no right to tell U-Boot how to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter of the size of U-Boot. It duplicates loads of things in there. No one will even *notice* an FDT merge function, which is actually only 70 LOC: /** * overlay_apply_node - Merges a node into the base device tree * @fdt: Base Device Tree blob * @target: Node offset in the base device tree to apply the fragment to * @fdto: Device tree overlay blob * @node: Node offset in the overlay holding the changes to merge * * overlay_apply_node() merges a node into a target base device tree * node pointed. * * This is part of the final step in the device tree overlay * application process, when all the phandles have been adjusted and * resolved and you just have to merge overlay into the base device * tree. * * returns: * 0 on success * Negative error code on failure */ static int overlay_apply_node(void *fdt, int target, void *fdto, int node) { int property; int subnode; fdt_for_each_property_offset(property, fdto, node) { const char *name; const void *prop; int prop_len; int ret; prop = fdt_getprop_by_offset(fdto, property, &name, &prop_len); if (prop_len == -FDT_ERR_NOTFOUND) return -FDT_ERR_INTERNAL; if (prop_len < 0) return prop_len; ret = fdt_setprop(fdt, target, name, prop, prop_len); if (ret) return ret; } fdt_for_each_subnode(subnode, fdto, node) { const char *name = fdt_get_name(fdto, subnode, NULL); int nnode; int ret; nnode = fdt_add_subnode(fdt, target, name); if (nnode == -FDT_ERR_EXISTS) { nnode = fdt_subnode_offset(fdt, target, name); if (nnode == -FDT_ERR_NOTFOUND) return -FDT_ERR_INTERNAL; } if (nnode < 0) return nnode; ret = overlay_apply_node(fdt, nnode, fdto, subnode); if (ret) return ret; } return 0; } > > Regards > /Ilias > > > > To repeat, if we set things up correctly and agree on the bindings, > > devicetree can be the unifying configuration mechanism through the > > whole of firmware (except for very early bits) and into the OS. I feel > > this will set us up very well to deal with the complexity that is > > coming. > > Regards, Simon ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-28 2:50 ` Simon Glass @ 2021-10-28 8:21 ` François Ozog 2021-10-28 14:30 ` Simon Glass 2021-11-01 11:04 ` Ilias Apalodimas 1 sibling, 1 reply; 73+ messages in thread From: François Ozog @ 2021-10-28 8:21 UTC (permalink / raw) To: Simon Glass Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 14640 bytes --] Hi Simon, Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit : > Hi Ilias, > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > <ilias.apalodimas@linaro.org> wrote: > > > > Hi Simon, > > > > A bit late to the party, sorry! > > (Did you remember the beer? I am replying to this but I don't think it > is all that helpful for me to reply to a lot of things on this thread, > since I would not be adding much to my cover letter and patches) > > > > > [...] > > > > > > > > > > I really want to see what the binary case looks like since we could > then > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > functionally correct from the hardware/our caller. > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > don't > > > > use the device tree from build time at run time, ignoring the device > > > > tree provided to us at run time by the caller. > > > > > > Firstly I should say that I find building firmware very messy and > > > confusing these days. Lots of things to build and it's hard to find > > > the instructions. It doesn't have to be that way, but if we carry on > > > as we are, it will continue to be messy and in five years you will > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > objective here is to simplify things, bringing some consistency to the > > > different components. Binman was one effort there. I feel that putting > > > at least the U-Boot house in order, in my role as devicetree > > > maintainer (and as author of devicetree support in U-Boot back in > > > 2011), is the next step. > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > can be the unifying configuration mechanism through the whole of > > > firmware (except for very early bits) and into the OS, this will set > > > us up very well to deal with the complexity that is coming. > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > two months: > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > have its own nodes/properties in the DT. It is an abuse of the > > > devicetree standard, like the /chosen node but with less history. We > > > should sacrifice efficiency, expedience and expandability on the altar > > > of 'devicetree is a hardware description'. How do we get over that > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > for its own purposes, as well as for booting the OS. I am not saying > > > it always has to have those properties, but with existing features > > > like verified boot, SPL as well as complex firmware images where > > > U-Boot needs to be able to find things in the image, it is essential. > > > So let's just assume that we need this everywhere, since we certainly > > > need it in at least some places. > > > > > > (stop reading here if you disagree, because nothing below will make > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > OF_CONTROL :-) > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > that to the DTs that are copied over from linux isn't imho. There are > > various reasons for that. First of all syncing device trees is a huge > pain > > and that's probably one of the main reasons our DTs are out of sync for a > > large number of boards. > > The point is this was fine in 2011 were we had SPL only, but the reality > > today is completely different. There's previous stage boot loaders (and > > enough cases were vendors prefer those over SPL). If that bootloader > needs > > to use it's own device tree for whatever reason, imposing restrictions > on > > it wrt to the device tree it has to include, and require them to have > > knowledge of U-Boot and it's internal config mechanism makes no sense not > > to mention it doesn't scale at all. > > I think the solution here may be the binman image packer. It works > from a description of the image (i.e. is data-driver) and can collect > all the pieces together. The U-Boot properties (and the ones required > by TF-A, etc.) can be added at package time. > > If you think about it, it doesn't matter what properties are in the DT > that is put into the firmware image. TF-A, for example, is presumably > reading a devicetree from flash, so what does it care if it has some > U-Boot properties in it? I am going to change my position in all mail threads I participate. I was trying to make patches relevant in the future and conceptually clean. That may not be the most effective position: I should just care about Linaro and its members being able to implement SystemReady concepts. If you mandate U-Boot has nodes in the device tree passed to the OS, we can put DT fragment in the nt_fw_config section of the fip and merge it at boot time. So there is a solution compatible with SystemReady. If you want to put fake, non future proof, DT sources in the dts for platforms that are organized to provide the authoritative DT to U-Boot at runtime, that's kind of your choice (hopefully representing the rest of U-Boot community). There will be quirk code in U-Boot to redo the adaptations on its non authoritative DT that the platform previous stage firmware does (already saw one in the past month); as Mark said there will be issues over time; and it will confuse people about the role of the DT. But I am fine with it as it does not impair Linaro and its members ability to implement SystemReady way of handling DT. > > As to syncing, we have solved this using u-boot.dtsi files in U-Boot, > so I think this can be dealt with. > > > > > > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > have binman definitions, etc. So we need a way to overlay those things > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > easy. Just require every board to have an in-tree DT. It helps with > > > discoverability and documentation, anyway. That is this series. > > > > > > > Again, the board might decide for it's own reason to provide it's own DT. > > IMHO U-Boot must be able to cope with that and asking DTs to be included > in > > U-Boot source is not the right way to do that, not to mention cases were > > that's completely unrealistic (e.g QEMU or a board that reads the DTB > from > > it's flash). > > I think you are at step 2. See above for my response. > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > and worried about step 3) > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > flow only, or boards that sometimes use a flow) which need the DT to > > > come from a prior stage. How to handle that? IMO that is only going to > > > grow as every man and his dog get into the write-a-bootloader > > > business. > > > > And that's exactly why we have to come up with something that scales, > without > > having to add a bunch of unusable DTs in U-Boot. > > In what way does this not scale? How are the DTs unusable? If there is > a standard binding, we should be fine. > > > > > > We need a way to provide the U-Boot nodes/properties in a > > > form that the prior stage can consume and integrate with its build > > > system. Is TF-A the only thing being discussed here? If so, let's just > > > do it. We have the u-boot.dtsi and we can use binman to put the image > > > together, for example. Or we can get clever and create some sort of > > > overlay dtb. > > > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > > then it will need to build it in and use two devicetrees, one internal > > > and one from the prior stage....well that is not very efficient and it > > > is going to be confusing for people to figure out what U-Boot is > > > actually doing. But we actually already do that in a lot of cases > > > where U-Boot passes a DT to the kernel which is different to the one > > > it uses. So perhaps we have three devicetrees? OMG. > > > > No we don't. That's a moot point. If you separate the DTs U-Boot > > provides the internal one and inherits one 'generic'. Linux will be > able to use > > that. So the only case were you'll need 3 DTs is if the *vendor* breaks > the > > DT across kernel versions, In which case there's not much you can do to > > begin with and that's already a case we have to deal with. > > Linux actually doesn't care if the U-Boot properties are in the tree, > so long as we have proper bindings. My point here is we only need > either: > > a. one devicetree, shared with Linux and U-Boot (and TF-A?) > b. two devicetrees, one for use in firmware and one for passing to Linux > > We don't need to separate out the U-Boot properties into a second (or > third) devicetree. There just isn't any point. > > > > > > b) Well then > > > U-Boot can have its own small devicetree with its bits and then U-Boot > > > can merge the two when it starts. Again that is not very efficient. It > > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > > its public key from there or to enable/disable the console), so > > > unified firmware config is not possible. It will get very confusing, > > > particularly for debugging U-Boot. c) Some other scheme to avoid > > > accepting step 3...please stop! > > > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > > whole cloth. What about that? Well, we are just going to have to deal > > > with that. We can easily merge in the U-Boot nodes/properties and > > > update the U-Boot CI scripts to do this, as needed, e.g. with > > > qemu-riscv64_spl. It's only one use case, although Xen might do > > > something similar. > > > > > > To my mind, that deals with both the build-time and run-time issues. > > > We have a discoverable DT in U-Boot, which should be considered the > > > source of truth for most boards. We can sync it with Linux > > > automatically with the tooling that I hope Rob Herring will come up > > > with. We can use an empty one where there really is no default, > > > although I'd argue that is making perfect an enemy of the good. > > > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > > and pick them up from somewhere else, we can do that with sufficient > > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > > > We can start slowly migrating boards and see how that works out. > > We could either use 2 device trees as you proposed, or have u-boot merge > > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd > prefer > > if linux gets handed a clean device tree without the u-boot internals in > > it, so I think 2 discrete DTs is cleaner overall. > > I know you would prefer that, but does it really matter in practice? > What is the objection, actually? > > As I mentioned on the call, I think the prior stage should do any > merging or fixing up. Trying to do that sort of thing in 'early' code > in U-Boot (or any other program, including Linux) is such a pain. With > U-Boot, for example, we don't even have any RAM available to do it > with half the time and it would dramatically increase the amount of > memory needed prior to relocation. It just isn't a very good idea to > try to do this in early code. It is also completely unnecessary, once > you get past the philosophical objections. > > If TF-A wants to be in the picture, let it deal with the implications > and responsibility thus incurred. TF-A has no right to tell U-Boot how > to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter > of the size of U-Boot. It duplicates loads of things in there. No one > will even *notice* an FDT merge function, which is actually only 70 > LOC: > > /** > * overlay_apply_node - Merges a node into the base device tree > * @fdt: Base Device Tree blob > * @target: Node offset in the base device tree to apply the fragment to > * @fdto: Device tree overlay blob > * @node: Node offset in the overlay holding the changes to merge > * > * overlay_apply_node() merges a node into a target base device tree > * node pointed. > * > * This is part of the final step in the device tree overlay > * application process, when all the phandles have been adjusted and > * resolved and you just have to merge overlay into the base device > * tree. > * > * returns: > * 0 on success > * Negative error code on failure > */ > static int overlay_apply_node(void *fdt, int target, > void *fdto, int node) > { > int property; > int subnode; > > fdt_for_each_property_offset(property, fdto, node) { > const char *name; > const void *prop; > int prop_len; > int ret; > > prop = fdt_getprop_by_offset(fdto, property, &name, > &prop_len); > if (prop_len == -FDT_ERR_NOTFOUND) > return -FDT_ERR_INTERNAL; > if (prop_len < 0) > return prop_len; > > ret = fdt_setprop(fdt, target, name, prop, prop_len); > if (ret) > return ret; > } > > fdt_for_each_subnode(subnode, fdto, node) { > const char *name = fdt_get_name(fdto, subnode, NULL); > int nnode; > int ret; > > nnode = fdt_add_subnode(fdt, target, name); > if (nnode == -FDT_ERR_EXISTS) { > nnode = fdt_subnode_offset(fdt, target, name); > if (nnode == -FDT_ERR_NOTFOUND) > return -FDT_ERR_INTERNAL; > } > > if (nnode < 0) > return nnode; > > ret = overlay_apply_node(fdt, nnode, fdto, subnode); > if (ret) > return ret; > } > > return 0; > > > > } > > > > > > Regards > > /Ilias > > > > > > To repeat, if we set things up correctly and agree on the bindings, > > > devicetree can be the unifying configuration mechanism through the > > > whole of firmware (except for very early bits) and into the OS. I feel > > > this will set us up very well to deal with the complexity that is > > > coming. > > > > > Regards, > Simon > [-- Attachment #2: Type: text/html, Size: 17138 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-28 8:21 ` François Ozog @ 2021-10-28 14:30 ` Simon Glass 2021-10-28 14:50 ` François Ozog 0 siblings, 1 reply; 73+ messages in thread From: Simon Glass @ 2021-10-28 14:30 UTC (permalink / raw) To: François Ozog Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari Hi François, On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> wrote: > > Hi Simon, > > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit : >> >> Hi Ilias, >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas >> <ilias.apalodimas@linaro.org> wrote: >> > >> > Hi Simon, >> > >> > A bit late to the party, sorry! >> >> (Did you remember the beer? I am replying to this but I don't think it >> is all that helpful for me to reply to a lot of things on this thread, >> since I would not be adding much to my cover letter and patches) >> >> > >> > [...] >> > >> > > > >> > > > I really want to see what the binary case looks like since we could then >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could >> > > > then also do a rpi_arm32_defconfig too. >> > > > >> > > > I want to see less device trees in U-Boot sources, if they can come >> > > > functionally correct from the hardware/our caller. >> > > > >> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't >> > > > use the device tree from build time at run time, ignoring the device >> > > > tree provided to us at run time by the caller. >> > > >> > > Firstly I should say that I find building firmware very messy and >> > > confusing these days. Lots of things to build and it's hard to find >> > > the instructions. It doesn't have to be that way, but if we carry on >> > > as we are, it will continue to be messy and in five years you will >> > > need a Ph.D and a lucky charm to boot on any modern board. My >> > > objective here is to simplify things, bringing some consistency to the >> > > different components. Binman was one effort there. I feel that putting >> > > at least the U-Boot house in order, in my role as devicetree >> > > maintainer (and as author of devicetree support in U-Boot back in >> > > 2011), is the next step. >> > > >> > > If we set things up correctly and agree on the bindings, devicetree >> > > can be the unifying configuration mechanism through the whole of >> > > firmware (except for very early bits) and into the OS, this will set >> > > us up very well to deal with the complexity that is coming. >> > > >> > > Anyway, here are the mental steps that I've gone through over the past >> > > two months: >> > > >> > > Step 1: At present, some people think U-Boot is not even allowed to >> > > have its own nodes/properties in the DT. It is an abuse of the >> > > devicetree standard, like the /chosen node but with less history. We >> > > should sacrifice efficiency, expedience and expandability on the altar >> > > of 'devicetree is a hardware description'. How do we get over that >> > > one? Wel, I just think we need to accept that U-Boot uses devicetree >> > > for its own purposes, as well as for booting the OS. I am not saying >> > > it always has to have those properties, but with existing features >> > > like verified boot, SPL as well as complex firmware images where >> > > U-Boot needs to be able to find things in the image, it is essential. >> > > So let's just assume that we need this everywhere, since we certainly >> > > need it in at least some places. >> > > >> > > (stop reading here if you disagree, because nothing below will make >> > > any sense...you can still use U-Boot v2011.06 which doesn't have >> > > OF_CONTROL :-) >> > >> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding >> > that to the DTs that are copied over from linux isn't imho. There are >> > various reasons for that. First of all syncing device trees is a huge pain >> > and that's probably one of the main reasons our DTs are out of sync for a >> > large number of boards. >> > The point is this was fine in 2011 were we had SPL only, but the reality >> > today is completely different. There's previous stage boot loaders (and >> > enough cases were vendors prefer those over SPL). If that bootloader needs >> > to use it's own device tree for whatever reason, imposing restrictions on >> > it wrt to the device tree it has to include, and require them to have >> > knowledge of U-Boot and it's internal config mechanism makes no sense not >> > to mention it doesn't scale at all. >> >> I think the solution here may be the binman image packer. It works >> from a description of the image (i.e. is data-driver) and can collect >> all the pieces together. The U-Boot properties (and the ones required >> by TF-A, etc.) can be added at package time. >> >> If you think about it, it doesn't matter what properties are in the DT >> that is put into the firmware image. TF-A, for example, is presumably >> reading a devicetree from flash, so what does it care if it has some >> U-Boot properties in it? > > > I am going to change my position in all mail threads I participate. > I was trying to make patches relevant in the future and conceptually clean. That may not be the most effective position: I should just care about Linaro and its members being able to implement SystemReady concepts. > > > If you mandate U-Boot has nodes in the device tree passed to the OS, we can put DT fragment in the nt_fw_config section of the fip and merge it at boot time. So there is a solution compatible with SystemReady. > > If you want to put fake, non future proof, DT sources in the dts for platforms that are organized to provide the authoritative DT to U-Boot at runtime, that's kind of your choice (hopefully representing the rest of U-Boot community). There will be quirk code in U-Boot to redo the adaptations on its non authoritative DT that the platform previous stage firmware does (already saw one in the past month); as Mark said there will be issues over time; and it will confuse people about the role of the DT. But I am fine with it as it does not impair Linaro and its members ability to implement SystemReady way of handling DT. OK thank you. It doesn't sound like you are very on-board though. Also, you mischaracterise my intent with in-tree devicetrees. I would be happy enough for now if you could accept that U-Boot has nodes/properties of its own in the devicetree. It has been a feature of U-Boot for 10 years now. Regards, Simon > >> >> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot, >> so I think this can be dealt with. >> >> > >> > > >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we >> > > have binman definitions, etc. So we need a way to overlay those things >> > > into the DT. We already support this for in-tree DTs, so IMO this is >> > > easy. Just require every board to have an in-tree DT. It helps with >> > > discoverability and documentation, anyway. That is this series. >> > > >> > >> > Again, the board might decide for it's own reason to provide it's own DT. >> > IMHO U-Boot must be able to cope with that and asking DTs to be included in >> > U-Boot source is not the right way to do that, not to mention cases were >> > that's completely unrealistic (e.g QEMU or a board that reads the DTB from >> > it's flash). >> >> I think you are at step 2. See above for my response. >> >> > >> > > (I think most of us are at the beginning of step 2, unsure about it >> > > and worried about step 3) >> > > >> > > Step 3: Ah, but there are flows (i.e. boards that use a particular >> > > flow only, or boards that sometimes use a flow) which need the DT to >> > > come from a prior stage. How to handle that? IMO that is only going to >> > > grow as every man and his dog get into the write-a-bootloader >> > > business. >> > >> > And that's exactly why we have to come up with something that scales, without >> > having to add a bunch of unusable DTs in U-Boot. >> >> In what way does this not scale? How are the DTs unusable? If there is >> a standard binding, we should be fine. >> >> > >> > > We need a way to provide the U-Boot nodes/properties in a >> > > form that the prior stage can consume and integrate with its build >> > > system. Is TF-A the only thing being discussed here? If so, let's just >> > > do it. We have the u-boot.dtsi and we can use binman to put the image >> > > together, for example. Or we can get clever and create some sort of >> > > overlay dtb. >> > > >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff >> > > then it will need to build it in and use two devicetrees, one internal >> > > and one from the prior stage....well that is not very efficient and it >> > > is going to be confusing for people to figure out what U-Boot is >> > > actually doing. But we actually already do that in a lot of cases >> > > where U-Boot passes a DT to the kernel which is different to the one >> > > it uses. So perhaps we have three devicetrees? OMG. >> > >> > No we don't. That's a moot point. If you separate the DTs U-Boot >> > provides the internal one and inherits one 'generic'. Linux will be able to use >> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the >> > DT across kernel versions, In which case there's not much you can do to >> > begin with and that's already a case we have to deal with. >> >> Linux actually doesn't care if the U-Boot properties are in the tree, >> so long as we have proper bindings. My point here is we only need >> either: >> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?) >> b. two devicetrees, one for use in firmware and one for passing to Linux >> >> We don't need to separate out the U-Boot properties into a second (or >> third) devicetree. There just isn't any point. >> >> > >> > > b) Well then >> > > U-Boot can have its own small devicetree with its bits and then U-Boot >> > > can merge the two when it starts. Again that is not very efficient. It >> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get >> > > its public key from there or to enable/disable the console), so >> > > unified firmware config is not possible. It will get very confusing, >> > > particularly for debugging U-Boot. c) Some other scheme to avoid >> > > accepting step 3...please stop! >> > > >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of >> > > whole cloth. What about that? Well, we are just going to have to deal >> > > with that. We can easily merge in the U-Boot nodes/properties and >> > > update the U-Boot CI scripts to do this, as needed, e.g. with >> > > qemu-riscv64_spl. It's only one use case, although Xen might do >> > > something similar. >> > > >> > > To my mind, that deals with both the build-time and run-time issues. >> > > We have a discoverable DT in U-Boot, which should be considered the >> > > source of truth for most boards. We can sync it with Linux >> > > automatically with the tooling that I hope Rob Herring will come up >> > > with. We can use an empty one where there really is no default, >> > > although I'd argue that is making perfect an enemy of the good. >> > > >> > > Step 5: If we get clever and want to remove them from the U-Boot tree >> > > and pick them up from somewhere else, we can do that with sufficient >> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? >> > >> > We can start slowly migrating boards and see how that works out. >> > We could either use 2 device trees as you proposed, or have u-boot merge >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer >> > if linux gets handed a clean device tree without the u-boot internals in >> > it, so I think 2 discrete DTs is cleaner overall. >> >> I know you would prefer that, but does it really matter in practice? >> What is the objection, actually? >> >> As I mentioned on the call, I think the prior stage should do any >> merging or fixing up. Trying to do that sort of thing in 'early' code >> in U-Boot (or any other program, including Linux) is such a pain. With >> U-Boot, for example, we don't even have any RAM available to do it >> with half the time and it would dramatically increase the amount of >> memory needed prior to relocation. It just isn't a very good idea to >> try to do this in early code. It is also completely unnecessary, once >> you get past the philosophical objections. >> >> If TF-A wants to be in the picture, let it deal with the implications >> and responsibility thus incurred. TF-A has no right to tell U-Boot how >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter >> of the size of U-Boot. It duplicates loads of things in there. No one >> will even *notice* an FDT merge function, which is actually only 70 >> LOC: >> >> /** >> * overlay_apply_node - Merges a node into the base device tree >> * @fdt: Base Device Tree blob >> * @target: Node offset in the base device tree to apply the fragment to >> * @fdto: Device tree overlay blob >> * @node: Node offset in the overlay holding the changes to merge >> * >> * overlay_apply_node() merges a node into a target base device tree >> * node pointed. >> * >> * This is part of the final step in the device tree overlay >> * application process, when all the phandles have been adjusted and >> * resolved and you just have to merge overlay into the base device >> * tree. >> * >> * returns: >> * 0 on success >> * Negative error code on failure >> */ >> static int overlay_apply_node(void *fdt, int target, >> void *fdto, int node) >> { >> int property; >> int subnode; >> >> fdt_for_each_property_offset(property, fdto, node) { >> const char *name; >> const void *prop; >> int prop_len; >> int ret; >> >> prop = fdt_getprop_by_offset(fdto, property, &name, >> &prop_len); >> if (prop_len == -FDT_ERR_NOTFOUND) >> return -FDT_ERR_INTERNAL; >> if (prop_len < 0) >> return prop_len; >> >> ret = fdt_setprop(fdt, target, name, prop, prop_len); >> if (ret) >> return ret; >> } >> >> fdt_for_each_subnode(subnode, fdto, node) { >> const char *name = fdt_get_name(fdto, subnode, NULL); >> int nnode; >> int ret; >> >> nnode = fdt_add_subnode(fdt, target, name); >> if (nnode == -FDT_ERR_EXISTS) { >> nnode = fdt_subnode_offset(fdt, target, name); >> if (nnode == -FDT_ERR_NOTFOUND) >> return -FDT_ERR_INTERNAL; >> } >> >> if (nnode < 0) >> return nnode; >> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode); >> if (ret) >> return ret; >> } >> >> return 0; >> >> >> >> } >> >> >> > >> > Regards >> > /Ilias >> > > >> > > To repeat, if we set things up correctly and agree on the bindings, >> > > devicetree can be the unifying configuration mechanism through the >> > > whole of firmware (except for very early bits) and into the OS. I feel >> > > this will set us up very well to deal with the complexity that is >> > > coming. >> > > >> >> Regards, >> Simon ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-28 14:30 ` Simon Glass @ 2021-10-28 14:50 ` François Ozog 2021-10-28 15:44 ` Simon Glass 0 siblings, 1 reply; 73+ messages in thread From: François Ozog @ 2021-10-28 14:50 UTC (permalink / raw) To: Simon Glass Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 17228 bytes --] Hi Simon Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit : > Hi François, > > On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> > wrote: > > > > Hi Simon, > > > > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit : > >> > >> Hi Ilias, > >> > >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > >> <ilias.apalodimas@linaro.org> wrote: > >> > > >> > Hi Simon, > >> > > >> > A bit late to the party, sorry! > >> > >> (Did you remember the beer? I am replying to this but I don't think it > >> is all that helpful for me to reply to a lot of things on this thread, > >> since I would not be adding much to my cover letter and patches) > >> > >> > > >> > [...] > >> > > >> > > > > >> > > > I really want to see what the binary case looks like since we > could then > >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > could > >> > > > then also do a rpi_arm32_defconfig too. > >> > > > > >> > > > I want to see less device trees in U-Boot sources, if they can > come > >> > > > functionally correct from the hardware/our caller. > >> > > > > >> > > > And I'm not seeing how we make use of "U-Boot /config" if we also > don't > >> > > > use the device tree from build time at run time, ignoring the > device > >> > > > tree provided to us at run time by the caller. > >> > > > >> > > Firstly I should say that I find building firmware very messy and > >> > > confusing these days. Lots of things to build and it's hard to find > >> > > the instructions. It doesn't have to be that way, but if we carry on > >> > > as we are, it will continue to be messy and in five years you will > >> > > need a Ph.D and a lucky charm to boot on any modern board. My > >> > > objective here is to simplify things, bringing some consistency to > the > >> > > different components. Binman was one effort there. I feel that > putting > >> > > at least the U-Boot house in order, in my role as devicetree > >> > > maintainer (and as author of devicetree support in U-Boot back in > >> > > 2011), is the next step. > >> > > > >> > > If we set things up correctly and agree on the bindings, devicetree > >> > > can be the unifying configuration mechanism through the whole of > >> > > firmware (except for very early bits) and into the OS, this will set > >> > > us up very well to deal with the complexity that is coming. > >> > > > >> > > Anyway, here are the mental steps that I've gone through over the > past > >> > > two months: > >> > > > >> > > Step 1: At present, some people think U-Boot is not even allowed to > >> > > have its own nodes/properties in the DT. It is an abuse of the > >> > > devicetree standard, like the /chosen node but with less history. We > >> > > should sacrifice efficiency, expedience and expandability on the > altar > >> > > of 'devicetree is a hardware description'. How do we get over that > >> > > one? Wel, I just think we need to accept that U-Boot uses devicetree > >> > > for its own purposes, as well as for booting the OS. I am not saying > >> > > it always has to have those properties, but with existing features > >> > > like verified boot, SPL as well as complex firmware images where > >> > > U-Boot needs to be able to find things in the image, it is > essential. > >> > > So let's just assume that we need this everywhere, since we > certainly > >> > > need it in at least some places. > >> > > > >> > > (stop reading here if you disagree, because nothing below will make > >> > > any sense...you can still use U-Boot v2011.06 which doesn't have > >> > > OF_CONTROL :-) > >> > > >> > Having U-Boot keep it's *internal* config state in DTs is fine. > Adding > >> > that to the DTs that are copied over from linux isn't imho. There are > >> > various reasons for that. First of all syncing device trees is a > huge pain > >> > and that's probably one of the main reasons our DTs are out of sync > for a > >> > large number of boards. > >> > The point is this was fine in 2011 were we had SPL only, but the > reality > >> > today is completely different. There's previous stage boot loaders > (and > >> > enough cases were vendors prefer those over SPL). If that bootloader > needs > >> > to use it's own device tree for whatever reason, imposing > restrictions on > >> > it wrt to the device tree it has to include, and require them to have > >> > knowledge of U-Boot and it's internal config mechanism makes no sense > not > >> > to mention it doesn't scale at all. > >> > >> I think the solution here may be the binman image packer. It works > >> from a description of the image (i.e. is data-driver) and can collect > >> all the pieces together. The U-Boot properties (and the ones required > >> by TF-A, etc.) can be added at package time. > >> > >> If you think about it, it doesn't matter what properties are in the DT > >> that is put into the firmware image. TF-A, for example, is presumably > >> reading a devicetree from flash, so what does it care if it has some > >> U-Boot properties in it? > > > > > > I am going to change my position in all mail threads I participate. > > I was trying to make patches relevant in the future and conceptually > clean. That may not be the most effective position: I should just care > about Linaro and its members being able to implement SystemReady concepts. > > > > > > If you mandate U-Boot has nodes in the device tree passed to the OS, we > can put DT fragment in the nt_fw_config section of the fip and merge it at > boot time. So there is a solution compatible with SystemReady. > > > > If you want to put fake, non future proof, DT sources in the dts for > platforms that are organized to provide the authoritative DT to U-Boot at > runtime, that's kind of your choice (hopefully representing the rest of > U-Boot community). There will be quirk code in U-Boot to redo the > adaptations on its non authoritative DT that the platform previous stage > firmware does (already saw one in the past month); as Mark said there will > be issues over time; and it will confuse people about the role of the DT. > But I am fine with it as it does not impair Linaro and its members ability > to implement SystemReady way of handling DT. > > OK thank you. It doesn't sound like you are very on-board though. > Also, you mischaracterise my intent with in-tree devicetrees. > > I would be happy enough for now if you could accept that U-Boot has > nodes/properties of its own in the devicetree. It has been a feature > of U-Boot for 10 years now. On SystemReady systems the DT passed to U-Boot for the OS will be assembled from the board DT and a U-Boot fragment/overlay. The board DT is free from any software/firmware aspects, just contains hardware description. The U-Boot fragment/overlay can contain any nodes it wants. The location of the bindings specification is essentially irrelevant: it could be devicetree.org, U-Boot doc or Linux kernel. Both DTs will be stored in the FIP. OEMs making their firmware will just put whatever is needed in this “dynamic config” DT. On SystemReady platforms U-Boot will always be given a DT, like on the RPI4. U-Boot will be able to ignore it obviously. That said, doing so, a platform may end-up failing compliance tests. I think we need to document the above in U-Boot and refer to relevant specifications. I’ll let Ilias propose something. > > > > Regards, > Simon > > > > > >> > >> > >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot, > >> so I think this can be dealt with. > >> > >> > > >> > > > >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > >> > > have binman definitions, etc. So we need a way to overlay those > things > >> > > into the DT. We already support this for in-tree DTs, so IMO this is > >> > > easy. Just require every board to have an in-tree DT. It helps with > >> > > discoverability and documentation, anyway. That is this series. > >> > > > >> > > >> > Again, the board might decide for it's own reason to provide it's own > DT. > >> > IMHO U-Boot must be able to cope with that and asking DTs to be > included in > >> > U-Boot source is not the right way to do that, not to mention cases > were > >> > that's completely unrealistic (e.g QEMU or a board that reads the DTB > from > >> > it's flash). > >> > >> I think you are at step 2. See above for my response. > >> > >> > > >> > > (I think most of us are at the beginning of step 2, unsure about it > >> > > and worried about step 3) > >> > > > >> > > Step 3: Ah, but there are flows (i.e. boards that use a particular > >> > > flow only, or boards that sometimes use a flow) which need the DT to > >> > > come from a prior stage. How to handle that? IMO that is only going > to > >> > > grow as every man and his dog get into the write-a-bootloader > >> > > business. > >> > > >> > And that's exactly why we have to come up with something that > scales, without > >> > having to add a bunch of unusable DTs in U-Boot. > >> > >> In what way does this not scale? How are the DTs unusable? If there is > >> a standard binding, we should be fine. > >> > >> > > >> > > We need a way to provide the U-Boot nodes/properties in a > >> > > form that the prior stage can consume and integrate with its build > >> > > system. Is TF-A the only thing being discussed here? If so, let's > just > >> > > do it. We have the u-boot.dtsi and we can use binman to put the > image > >> > > together, for example. Or we can get clever and create some sort of > >> > > overlay dtb. > >> > > > >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > >> > > then it will need to build it in and use two devicetrees, one > internal > >> > > and one from the prior stage....well that is not very efficient and > it > >> > > is going to be confusing for people to figure out what U-Boot is > >> > > actually doing. But we actually already do that in a lot of cases > >> > > where U-Boot passes a DT to the kernel which is different to the one > >> > > it uses. So perhaps we have three devicetrees? OMG. > >> > > >> > No we don't. That's a moot point. If you separate the DTs U-Boot > >> > provides the internal one and inherits one 'generic'. Linux will be > able to use > >> > that. So the only case were you'll need 3 DTs is if the *vendor* > breaks the > >> > DT across kernel versions, In which case there's not much you can do > to > >> > begin with and that's already a case we have to deal with. > >> > >> Linux actually doesn't care if the U-Boot properties are in the tree, > >> so long as we have proper bindings. My point here is we only need > >> either: > >> > >> a. one devicetree, shared with Linux and U-Boot (and TF-A?) > >> b. two devicetrees, one for use in firmware and one for passing to Linux > >> > >> We don't need to separate out the U-Boot properties into a second (or > >> third) devicetree. There just isn't any point. > >> > >> > > >> > > b) Well then > >> > > U-Boot can have its own small devicetree with its bits and then > U-Boot > >> > > can merge the two when it starts. Again that is not very efficient. > It > >> > > means that U-Boot cannot be controlled by the prior stage (e.g. to > get > >> > > its public key from there or to enable/disable the console), so > >> > > unified firmware config is not possible. It will get very confusing, > >> > > particularly for debugging U-Boot. c) Some other scheme to avoid > >> > > accepting step 3...please stop! > >> > > > >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > >> > > whole cloth. What about that? Well, we are just going to have to > deal > >> > > with that. We can easily merge in the U-Boot nodes/properties and > >> > > update the U-Boot CI scripts to do this, as needed, e.g. with > >> > > qemu-riscv64_spl. It's only one use case, although Xen might do > >> > > something similar. > >> > > > >> > > To my mind, that deals with both the build-time and run-time issues. > >> > > We have a discoverable DT in U-Boot, which should be considered the > >> > > source of truth for most boards. We can sync it with Linux > >> > > automatically with the tooling that I hope Rob Herring will come up > >> > > with. We can use an empty one where there really is no default, > >> > > although I'd argue that is making perfect an enemy of the good. > >> > > > >> > > Step 5: If we get clever and want to remove them from the U-Boot > tree > >> > > and pick them up from somewhere else, we can do that with sufficient > >> > > tooling. Perhaps we should set a timeline for that? A year? Two? > Six? > >> > > >> > We can start slowly migrating boards and see how that works out. > >> > We could either use 2 device trees as you proposed, or have u-boot > merge > >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd > prefer > >> > if linux gets handed a clean device tree without the u-boot internals > in > >> > it, so I think 2 discrete DTs is cleaner overall. > >> > >> I know you would prefer that, but does it really matter in practice? > >> What is the objection, actually? > >> > >> As I mentioned on the call, I think the prior stage should do any > >> merging or fixing up. Trying to do that sort of thing in 'early' code > >> in U-Boot (or any other program, including Linux) is such a pain. With > >> U-Boot, for example, we don't even have any RAM available to do it > >> with half the time and it would dramatically increase the amount of > >> memory needed prior to relocation. It just isn't a very good idea to > >> try to do this in early code. It is also completely unnecessary, once > >> you get past the philosophical objections. > >> > >> If TF-A wants to be in the picture, let it deal with the implications > >> and responsibility thus incurred. TF-A has no right to tell U-Boot how > >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter > >> of the size of U-Boot. It duplicates loads of things in there. No one > >> will even *notice* an FDT merge function, which is actually only 70 > >> LOC: > >> > >> /** > >> * overlay_apply_node - Merges a node into the base device tree > >> * @fdt: Base Device Tree blob > >> * @target: Node offset in the base device tree to apply the fragment to > >> * @fdto: Device tree overlay blob > >> * @node: Node offset in the overlay holding the changes to merge > >> * > >> * overlay_apply_node() merges a node into a target base device tree > >> * node pointed. > >> * > >> * This is part of the final step in the device tree overlay > >> * application process, when all the phandles have been adjusted and > >> * resolved and you just have to merge overlay into the base device > >> * tree. > >> * > >> * returns: > >> * 0 on success > >> * Negative error code on failure > >> */ > >> static int overlay_apply_node(void *fdt, int target, > >> void *fdto, int node) > >> { > >> int property; > >> int subnode; > >> > >> fdt_for_each_property_offset(property, fdto, node) { > >> const char *name; > >> const void *prop; > >> int prop_len; > >> int ret; > >> > >> prop = fdt_getprop_by_offset(fdto, property, &name, > >> &prop_len); > >> if (prop_len == -FDT_ERR_NOTFOUND) > >> return -FDT_ERR_INTERNAL; > >> if (prop_len < 0) > >> return prop_len; > >> > >> ret = fdt_setprop(fdt, target, name, prop, prop_len); > >> if (ret) > >> return ret; > >> } > >> > >> fdt_for_each_subnode(subnode, fdto, node) { > >> const char *name = fdt_get_name(fdto, subnode, NULL); > >> int nnode; > >> int ret; > >> > >> nnode = fdt_add_subnode(fdt, target, name); > >> if (nnode == -FDT_ERR_EXISTS) { > >> nnode = fdt_subnode_offset(fdt, target, name); > >> if (nnode == -FDT_ERR_NOTFOUND) > >> return -FDT_ERR_INTERNAL; > >> } > >> > >> if (nnode < 0) > >> return nnode; > >> > >> ret = overlay_apply_node(fdt, nnode, fdto, subnode); > >> if (ret) > >> return ret; > >> } > >> > >> return 0; > >> > >> > >> > >> } > >> > >> > >> > > >> > Regards > >> > /Ilias > >> > > > >> > > To repeat, if we set things up correctly and agree on the bindings, > >> > > devicetree can be the unifying configuration mechanism through the > >> > > whole of firmware (except for very early bits) and into the OS. I > feel > >> > > this will set us up very well to deal with the complexity that is > >> > > coming. > >> > > > >> > >> 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: 22933 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-28 14:50 ` François Ozog @ 2021-10-28 15:44 ` Simon Glass 2021-10-28 16:25 ` François Ozog 0 siblings, 1 reply; 73+ messages in thread From: Simon Glass @ 2021-10-28 15:44 UTC (permalink / raw) To: François Ozog Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari Hi François, On Thu, 28 Oct 2021 at 08:50, François Ozog <francois.ozog@linaro.org> wrote: > > Hi Simon > > Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit : >> >> Hi François, >> >> On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> wrote: >> > >> > Hi Simon, >> > >> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit : >> >> >> >> Hi Ilias, >> >> >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas >> >> <ilias.apalodimas@linaro.org> wrote: >> >> > >> >> > Hi Simon, >> >> > >> >> > A bit late to the party, sorry! >> >> >> >> (Did you remember the beer? I am replying to this but I don't think it >> >> is all that helpful for me to reply to a lot of things on this thread, >> >> since I would not be adding much to my cover letter and patches) >> >> >> >> > >> >> > [...] >> >> > >> >> > > > >> >> > > > I really want to see what the binary case looks like since we could then >> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could >> >> > > > then also do a rpi_arm32_defconfig too. >> >> > > > >> >> > > > I want to see less device trees in U-Boot sources, if they can come >> >> > > > functionally correct from the hardware/our caller. >> >> > > > >> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't >> >> > > > use the device tree from build time at run time, ignoring the device >> >> > > > tree provided to us at run time by the caller. >> >> > > >> >> > > Firstly I should say that I find building firmware very messy and >> >> > > confusing these days. Lots of things to build and it's hard to find >> >> > > the instructions. It doesn't have to be that way, but if we carry on >> >> > > as we are, it will continue to be messy and in five years you will >> >> > > need a Ph.D and a lucky charm to boot on any modern board. My >> >> > > objective here is to simplify things, bringing some consistency to the >> >> > > different components. Binman was one effort there. I feel that putting >> >> > > at least the U-Boot house in order, in my role as devicetree >> >> > > maintainer (and as author of devicetree support in U-Boot back in >> >> > > 2011), is the next step. >> >> > > >> >> > > If we set things up correctly and agree on the bindings, devicetree >> >> > > can be the unifying configuration mechanism through the whole of >> >> > > firmware (except for very early bits) and into the OS, this will set >> >> > > us up very well to deal with the complexity that is coming. >> >> > > >> >> > > Anyway, here are the mental steps that I've gone through over the past >> >> > > two months: >> >> > > >> >> > > Step 1: At present, some people think U-Boot is not even allowed to >> >> > > have its own nodes/properties in the DT. It is an abuse of the >> >> > > devicetree standard, like the /chosen node but with less history. We >> >> > > should sacrifice efficiency, expedience and expandability on the altar >> >> > > of 'devicetree is a hardware description'. How do we get over that >> >> > > one? Wel, I just think we need to accept that U-Boot uses devicetree >> >> > > for its own purposes, as well as for booting the OS. I am not saying >> >> > > it always has to have those properties, but with existing features >> >> > > like verified boot, SPL as well as complex firmware images where >> >> > > U-Boot needs to be able to find things in the image, it is essential. >> >> > > So let's just assume that we need this everywhere, since we certainly >> >> > > need it in at least some places. >> >> > > >> >> > > (stop reading here if you disagree, because nothing below will make >> >> > > any sense...you can still use U-Boot v2011.06 which doesn't have >> >> > > OF_CONTROL :-) >> >> > >> >> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding >> >> > that to the DTs that are copied over from linux isn't imho. There are >> >> > various reasons for that. First of all syncing device trees is a huge pain >> >> > and that's probably one of the main reasons our DTs are out of sync for a >> >> > large number of boards. >> >> > The point is this was fine in 2011 were we had SPL only, but the reality >> >> > today is completely different. There's previous stage boot loaders (and >> >> > enough cases were vendors prefer those over SPL). If that bootloader needs >> >> > to use it's own device tree for whatever reason, imposing restrictions on >> >> > it wrt to the device tree it has to include, and require them to have >> >> > knowledge of U-Boot and it's internal config mechanism makes no sense not >> >> > to mention it doesn't scale at all. >> >> >> >> I think the solution here may be the binman image packer. It works >> >> from a description of the image (i.e. is data-driver) and can collect >> >> all the pieces together. The U-Boot properties (and the ones required >> >> by TF-A, etc.) can be added at package time. >> >> >> >> If you think about it, it doesn't matter what properties are in the DT >> >> that is put into the firmware image. TF-A, for example, is presumably >> >> reading a devicetree from flash, so what does it care if it has some >> >> U-Boot properties in it? >> > >> > >> > I am going to change my position in all mail threads I participate. >> > I was trying to make patches relevant in the future and conceptually clean. That may not be the most effective position: I should just care about Linaro and its members being able to implement SystemReady concepts. >> > >> > >> > If you mandate U-Boot has nodes in the device tree passed to the OS, we can put DT fragment in the nt_fw_config section of the fip and merge it at boot time. So there is a solution compatible with SystemReady. >> > >> > If you want to put fake, non future proof, DT sources in the dts for platforms that are organized to provide the authoritative DT to U-Boot at runtime, that's kind of your choice (hopefully representing the rest of U-Boot community). There will be quirk code in U-Boot to redo the adaptations on its non authoritative DT that the platform previous stage firmware does (already saw one in the past month); as Mark said there will be issues over time; and it will confuse people about the role of the DT. But I am fine with it as it does not impair Linaro and its members ability to implement SystemReady way of handling DT. >> >> OK thank you. It doesn't sound like you are very on-board though. >> Also, you mischaracterise my intent with in-tree devicetrees. >> >> I would be happy enough for now if you could accept that U-Boot has >> nodes/properties of its own in the devicetree. It has been a feature >> of U-Boot for 10 years now. > > On SystemReady systems the DT passed to U-Boot for the OS will be assembled from the board DT and a U-Boot fragment/overlay. The board DT is free from any software/firmware aspects, just contains hardware description. The U-Boot fragment/overlay can contain any nodes it wants. The location of the bindings specification is essentially irrelevant: it could be devicetree.org, U-Boot doc or Linux kernel. Both DTs will be stored in the FIP. OEMs making their firmware will just put whatever is needed in this “dynamic config” DT. On SystemReady platforms U-Boot will always be given a DT, like on the RPI4. U-Boot will be able to ignore it obviously. That said, doing so, a platform may end-up failing compliance tests. > I think we need to document the above in U-Boot and refer to relevant specifications. I’ll let Ilias propose something. Hmm. So long as OF_BOARD is enabled, the devicetree will not be 'ignored'. Are you talking here about what TF-A will do? I assume so, since you mention FIP and I believe that is a TF-A invention. Of course the image is all packaged together in fact, so binman could presumably merge the DTs at build time, if desired. Regards, Simon >> >> >> >> >> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot, >> >> so I think this can be dealt with. >> >> >> >> > >> >> > > >> >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get >> >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch >> >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we >> >> > > have binman definitions, etc. So we need a way to overlay those things >> >> > > into the DT. We already support this for in-tree DTs, so IMO this is >> >> > > easy. Just require every board to have an in-tree DT. It helps with >> >> > > discoverability and documentation, anyway. That is this series. >> >> > > >> >> > >> >> > Again, the board might decide for it's own reason to provide it's own DT. >> >> > IMHO U-Boot must be able to cope with that and asking DTs to be included in >> >> > U-Boot source is not the right way to do that, not to mention cases were >> >> > that's completely unrealistic (e.g QEMU or a board that reads the DTB from >> >> > it's flash). >> >> >> >> I think you are at step 2. See above for my response. >> >> >> >> > >> >> > > (I think most of us are at the beginning of step 2, unsure about it >> >> > > and worried about step 3) >> >> > > >> >> > > Step 3: Ah, but there are flows (i.e. boards that use a particular >> >> > > flow only, or boards that sometimes use a flow) which need the DT to >> >> > > come from a prior stage. How to handle that? IMO that is only going to >> >> > > grow as every man and his dog get into the write-a-bootloader >> >> > > business. >> >> > >> >> > And that's exactly why we have to come up with something that scales, without >> >> > having to add a bunch of unusable DTs in U-Boot. >> >> >> >> In what way does this not scale? How are the DTs unusable? If there is >> >> a standard binding, we should be fine. >> >> >> >> > >> >> > > We need a way to provide the U-Boot nodes/properties in a >> >> > > form that the prior stage can consume and integrate with its build >> >> > > system. Is TF-A the only thing being discussed here? If so, let's just >> >> > > do it. We have the u-boot.dtsi and we can use binman to put the image >> >> > > together, for example. Or we can get clever and create some sort of >> >> > > overlay dtb. >> >> > > >> >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff >> >> > > then it will need to build it in and use two devicetrees, one internal >> >> > > and one from the prior stage....well that is not very efficient and it >> >> > > is going to be confusing for people to figure out what U-Boot is >> >> > > actually doing. But we actually already do that in a lot of cases >> >> > > where U-Boot passes a DT to the kernel which is different to the one >> >> > > it uses. So perhaps we have three devicetrees? OMG. >> >> > >> >> > No we don't. That's a moot point. If you separate the DTs U-Boot >> >> > provides the internal one and inherits one 'generic'. Linux will be able to use >> >> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the >> >> > DT across kernel versions, In which case there's not much you can do to >> >> > begin with and that's already a case we have to deal with. >> >> >> >> Linux actually doesn't care if the U-Boot properties are in the tree, >> >> so long as we have proper bindings. My point here is we only need >> >> either: >> >> >> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?) >> >> b. two devicetrees, one for use in firmware and one for passing to Linux >> >> >> >> We don't need to separate out the U-Boot properties into a second (or >> >> third) devicetree. There just isn't any point. >> >> >> >> > >> >> > > b) Well then >> >> > > U-Boot can have its own small devicetree with its bits and then U-Boot >> >> > > can merge the two when it starts. Again that is not very efficient. It >> >> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get >> >> > > its public key from there or to enable/disable the console), so >> >> > > unified firmware config is not possible. It will get very confusing, >> >> > > particularly for debugging U-Boot. c) Some other scheme to avoid >> >> > > accepting step 3...please stop! >> >> > > >> >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of >> >> > > whole cloth. What about that? Well, we are just going to have to deal >> >> > > with that. We can easily merge in the U-Boot nodes/properties and >> >> > > update the U-Boot CI scripts to do this, as needed, e.g. with >> >> > > qemu-riscv64_spl. It's only one use case, although Xen might do >> >> > > something similar. >> >> > > >> >> > > To my mind, that deals with both the build-time and run-time issues. >> >> > > We have a discoverable DT in U-Boot, which should be considered the >> >> > > source of truth for most boards. We can sync it with Linux >> >> > > automatically with the tooling that I hope Rob Herring will come up >> >> > > with. We can use an empty one where there really is no default, >> >> > > although I'd argue that is making perfect an enemy of the good. >> >> > > >> >> > > Step 5: If we get clever and want to remove them from the U-Boot tree >> >> > > and pick them up from somewhere else, we can do that with sufficient >> >> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? >> >> > >> >> > We can start slowly migrating boards and see how that works out. >> >> > We could either use 2 device trees as you proposed, or have u-boot merge >> >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer >> >> > if linux gets handed a clean device tree without the u-boot internals in >> >> > it, so I think 2 discrete DTs is cleaner overall. >> >> >> >> I know you would prefer that, but does it really matter in practice? >> >> What is the objection, actually? >> >> >> >> As I mentioned on the call, I think the prior stage should do any >> >> merging or fixing up. Trying to do that sort of thing in 'early' code >> >> in U-Boot (or any other program, including Linux) is such a pain. With >> >> U-Boot, for example, we don't even have any RAM available to do it >> >> with half the time and it would dramatically increase the amount of >> >> memory needed prior to relocation. It just isn't a very good idea to >> >> try to do this in early code. It is also completely unnecessary, once >> >> you get past the philosophical objections. >> >> >> >> If TF-A wants to be in the picture, let it deal with the implications >> >> and responsibility thus incurred. TF-A has no right to tell U-Boot how >> >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter >> >> of the size of U-Boot. It duplicates loads of things in there. No one >> >> will even *notice* an FDT merge function, which is actually only 70 >> >> LOC: >> >> >> >> /** >> >> * overlay_apply_node - Merges a node into the base device tree >> >> * @fdt: Base Device Tree blob >> >> * @target: Node offset in the base device tree to apply the fragment to >> >> * @fdto: Device tree overlay blob >> >> * @node: Node offset in the overlay holding the changes to merge >> >> * >> >> * overlay_apply_node() merges a node into a target base device tree >> >> * node pointed. >> >> * >> >> * This is part of the final step in the device tree overlay >> >> * application process, when all the phandles have been adjusted and >> >> * resolved and you just have to merge overlay into the base device >> >> * tree. >> >> * >> >> * returns: >> >> * 0 on success >> >> * Negative error code on failure >> >> */ >> >> static int overlay_apply_node(void *fdt, int target, >> >> void *fdto, int node) >> >> { >> >> int property; >> >> int subnode; >> >> >> >> fdt_for_each_property_offset(property, fdto, node) { >> >> const char *name; >> >> const void *prop; >> >> int prop_len; >> >> int ret; >> >> >> >> prop = fdt_getprop_by_offset(fdto, property, &name, >> >> &prop_len); >> >> if (prop_len == -FDT_ERR_NOTFOUND) >> >> return -FDT_ERR_INTERNAL; >> >> if (prop_len < 0) >> >> return prop_len; >> >> >> >> ret = fdt_setprop(fdt, target, name, prop, prop_len); >> >> if (ret) >> >> return ret; >> >> } >> >> >> >> fdt_for_each_subnode(subnode, fdto, node) { >> >> const char *name = fdt_get_name(fdto, subnode, NULL); >> >> int nnode; >> >> int ret; >> >> >> >> nnode = fdt_add_subnode(fdt, target, name); >> >> if (nnode == -FDT_ERR_EXISTS) { >> >> nnode = fdt_subnode_offset(fdt, target, name); >> >> if (nnode == -FDT_ERR_NOTFOUND) >> >> return -FDT_ERR_INTERNAL; >> >> } >> >> >> >> if (nnode < 0) >> >> return nnode; >> >> >> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode); >> >> if (ret) >> >> return ret; >> >> } >> >> >> >> return 0; >> >> >> >> >> >> >> >> } >> >> >> >> >> >> > >> >> > Regards >> >> > /Ilias >> >> > > >> >> > > To repeat, if we set things up correctly and agree on the bindings, >> >> > > devicetree can be the unifying configuration mechanism through the >> >> > > whole of firmware (except for very early bits) and into the OS. I feel >> >> > > this will set us up very well to deal with the complexity that is >> >> > > coming. >> >> > > >> >> >> >> Regards, >> >> Simon > > -- > François-Frédéric Ozog | Director Business Development > T: +33.67221.6485 > francois.ozog@linaro.org | Skype: ffozog > ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-28 15:44 ` Simon Glass @ 2021-10-28 16:25 ` François Ozog 2021-11-02 14:59 ` Simon Glass 0 siblings, 1 reply; 73+ messages in thread From: François Ozog @ 2021-10-28 16:25 UTC (permalink / raw) To: Simon Glass Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 19475 bytes --] Hi Simon Le jeu. 28 oct. 2021 à 17:44, Simon Glass <sjg@chromium.org> a écrit : > Hi François, > > On Thu, 28 Oct 2021 at 08:50, François Ozog <francois.ozog@linaro.org> > wrote: > > > > Hi Simon > > > > Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit : > >> > >> Hi François, > >> > >> On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> > wrote: > >> > > >> > Hi Simon, > >> > > >> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit > : > >> >> > >> >> Hi Ilias, > >> >> > >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > >> >> <ilias.apalodimas@linaro.org> wrote: > >> >> > > >> >> > Hi Simon, > >> >> > > >> >> > A bit late to the party, sorry! > >> >> > >> >> (Did you remember the beer? I am replying to this but I don't think > it > >> >> is all that helpful for me to reply to a lot of things on this > thread, > >> >> since I would not be adding much to my cover letter and patches) > >> >> > >> >> > > >> >> > [...] > >> >> > > >> >> > > > > >> >> > > > I really want to see what the binary case looks like since we > could then > >> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > could > >> >> > > > then also do a rpi_arm32_defconfig too. > >> >> > > > > >> >> > > > I want to see less device trees in U-Boot sources, if they can > come > >> >> > > > functionally correct from the hardware/our caller. > >> >> > > > > >> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we > also don't > >> >> > > > use the device tree from build time at run time, ignoring the > device > >> >> > > > tree provided to us at run time by the caller. > >> >> > > > >> >> > > Firstly I should say that I find building firmware very messy and > >> >> > > confusing these days. Lots of things to build and it's hard to > find > >> >> > > the instructions. It doesn't have to be that way, but if we > carry on > >> >> > > as we are, it will continue to be messy and in five years you > will > >> >> > > need a Ph.D and a lucky charm to boot on any modern board. My > >> >> > > objective here is to simplify things, bringing some consistency > to the > >> >> > > different components. Binman was one effort there. I feel that > putting > >> >> > > at least the U-Boot house in order, in my role as devicetree > >> >> > > maintainer (and as author of devicetree support in U-Boot back in > >> >> > > 2011), is the next step. > >> >> > > > >> >> > > If we set things up correctly and agree on the bindings, > devicetree > >> >> > > can be the unifying configuration mechanism through the whole of > >> >> > > firmware (except for very early bits) and into the OS, this will > set > >> >> > > us up very well to deal with the complexity that is coming. > >> >> > > > >> >> > > Anyway, here are the mental steps that I've gone through over > the past > >> >> > > two months: > >> >> > > > >> >> > > Step 1: At present, some people think U-Boot is not even allowed > to > >> >> > > have its own nodes/properties in the DT. It is an abuse of the > >> >> > > devicetree standard, like the /chosen node but with less > history. We > >> >> > > should sacrifice efficiency, expedience and expandability on the > altar > >> >> > > of 'devicetree is a hardware description'. How do we get over > that > >> >> > > one? Wel, I just think we need to accept that U-Boot uses > devicetree > >> >> > > for its own purposes, as well as for booting the OS. I am not > saying > >> >> > > it always has to have those properties, but with existing > features > >> >> > > like verified boot, SPL as well as complex firmware images where > >> >> > > U-Boot needs to be able to find things in the image, it is > essential. > >> >> > > So let's just assume that we need this everywhere, since we > certainly > >> >> > > need it in at least some places. > >> >> > > > >> >> > > (stop reading here if you disagree, because nothing below will > make > >> >> > > any sense...you can still use U-Boot v2011.06 which doesn't have > >> >> > > OF_CONTROL :-) > >> >> > > >> >> > Having U-Boot keep it's *internal* config state in DTs is fine. > Adding > >> >> > that to the DTs that are copied over from linux isn't imho. There > are > >> >> > various reasons for that. First of all syncing device trees is a > huge pain > >> >> > and that's probably one of the main reasons our DTs are out of > sync for a > >> >> > large number of boards. > >> >> > The point is this was fine in 2011 were we had SPL only, but the > reality > >> >> > today is completely different. There's previous stage boot > loaders (and > >> >> > enough cases were vendors prefer those over SPL). If that > bootloader needs > >> >> > to use it's own device tree for whatever reason, imposing > restrictions on > >> >> > it wrt to the device tree it has to include, and require them to > have > >> >> > knowledge of U-Boot and it's internal config mechanism makes no > sense not > >> >> > to mention it doesn't scale at all. > >> >> > >> >> I think the solution here may be the binman image packer. It works > >> >> from a description of the image (i.e. is data-driver) and can collect > >> >> all the pieces together. The U-Boot properties (and the ones required > >> >> by TF-A, etc.) can be added at package time. > >> >> > >> >> If you think about it, it doesn't matter what properties are in the > DT > >> >> that is put into the firmware image. TF-A, for example, is presumably > >> >> reading a devicetree from flash, so what does it care if it has some > >> >> U-Boot properties in it? > >> > > >> > > >> > I am going to change my position in all mail threads I participate. > >> > I was trying to make patches relevant in the future and conceptually > clean. That may not be the most effective position: I should just care > about Linaro and its members being able to implement SystemReady concepts. > >> > > >> > > >> > If you mandate U-Boot has nodes in the device tree passed to the OS, > we can put DT fragment in the nt_fw_config section of the fip and merge it > at boot time. So there is a solution compatible with SystemReady. > >> > > >> > If you want to put fake, non future proof, DT sources in the dts for > platforms that are organized to provide the authoritative DT to U-Boot at > runtime, that's kind of your choice (hopefully representing the rest of > U-Boot community). There will be quirk code in U-Boot to redo the > adaptations on its non authoritative DT that the platform previous stage > firmware does (already saw one in the past month); as Mark said there will > be issues over time; and it will confuse people about the role of the DT. > But I am fine with it as it does not impair Linaro and its members ability > to implement SystemReady way of handling DT. > >> > >> OK thank you. It doesn't sound like you are very on-board though. > >> Also, you mischaracterise my intent with in-tree devicetrees. > >> > >> I would be happy enough for now if you could accept that U-Boot has > >> nodes/properties of its own in the devicetree. It has been a feature > >> of U-Boot for 10 years now. > > > > On SystemReady systems the DT passed to U-Boot for the OS will be > assembled from the board DT and a U-Boot fragment/overlay. The board DT is > free from any software/firmware aspects, just contains hardware > description. The U-Boot fragment/overlay can contain any nodes it wants. > The location of the bindings specification is essentially irrelevant: it > could be devicetree.org, U-Boot doc or Linux kernel. Both DTs will be > stored in the FIP. OEMs making their firmware will just put whatever is > needed in this “dynamic config” DT. On SystemReady platforms U-Boot will > always be given a DT, like on the RPI4. U-Boot will be able to ignore it > obviously. That said, doing so, a platform may end-up failing compliance > tests. > > I think we need to document the above in U-Boot and refer to relevant > specifications. I’ll let Ilias propose something. > > Hmm. So long as OF_BOARD is enabled, the devicetree will not be 'ignored'. > > Are you talking here about what TF-A will do? I assume so, since you > mention FIP and I believe that is a TF-A invention. > Yes > > Of course the image is all packaged together in fact, so binman could > presumably merge the DTs at build time, if desired. Practically I don’t think so. The passed device tree will contain all authoritative information such as discovered normal memory (excluded the secure memory ranges), architectural nodes such as PSCI and other nodes coming from TEE-OS or secure partitions such as SCMI interface or firmwareTPM. If you combine the two static parts at build time you will have to extract the runtime pieces from the DT passed to U-Boot. > > > Regards, > Simon > > >> >> > >> >> > >> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot, > >> >> so I think this can be dealt with. > >> >> > >> >> > > >> >> > > > >> >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they > get > >> >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > >> >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi > file"), we > >> >> > > have binman definitions, etc. So we need a way to overlay those > things > >> >> > > into the DT. We already support this for in-tree DTs, so IMO > this is > >> >> > > easy. Just require every board to have an in-tree DT. It helps > with > >> >> > > discoverability and documentation, anyway. That is this series. > >> >> > > > >> >> > > >> >> > Again, the board might decide for it's own reason to provide it's > own DT. > >> >> > IMHO U-Boot must be able to cope with that and asking DTs to be > included in > >> >> > U-Boot source is not the right way to do that, not to mention > cases were > >> >> > that's completely unrealistic (e.g QEMU or a board that reads the > DTB from > >> >> > it's flash). > >> >> > >> >> I think you are at step 2. See above for my response. > >> >> > >> >> > > >> >> > > (I think most of us are at the beginning of step 2, unsure about > it > >> >> > > and worried about step 3) > >> >> > > > >> >> > > Step 3: Ah, but there are flows (i.e. boards that use a > particular > >> >> > > flow only, or boards that sometimes use a flow) which need the > DT to > >> >> > > come from a prior stage. How to handle that? IMO that is only > going to > >> >> > > grow as every man and his dog get into the write-a-bootloader > >> >> > > business. > >> >> > > >> >> > And that's exactly why we have to come up with something that > scales, without > >> >> > having to add a bunch of unusable DTs in U-Boot. > >> >> > >> >> In what way does this not scale? How are the DTs unusable? If there > is > >> >> a standard binding, we should be fine. > >> >> > >> >> > > >> >> > > We need a way to provide the U-Boot nodes/properties in a > >> >> > > form that the prior stage can consume and integrate with its > build > >> >> > > system. Is TF-A the only thing being discussed here? If so, > let's just > >> >> > > do it. We have the u-boot.dtsi and we can use binman to put the > image > >> >> > > together, for example. Or we can get clever and create some sort > of > >> >> > > overlay dtb. > >> >> > > > >> >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this > stuff > >> >> > > then it will need to build it in and use two devicetrees, one > internal > >> >> > > and one from the prior stage....well that is not very efficient > and it > >> >> > > is going to be confusing for people to figure out what U-Boot is > >> >> > > actually doing. But we actually already do that in a lot of cases > >> >> > > where U-Boot passes a DT to the kernel which is different to the > one > >> >> > > it uses. So perhaps we have three devicetrees? OMG. > >> >> > > >> >> > No we don't. That's a moot point. If you separate the DTs U-Boot > >> >> > provides the internal one and inherits one 'generic'. Linux will > be able to use > >> >> > that. So the only case were you'll need 3 DTs is if the *vendor* > breaks the > >> >> > DT across kernel versions, In which case there's not much you can > do to > >> >> > begin with and that's already a case we have to deal with. > >> >> > >> >> Linux actually doesn't care if the U-Boot properties are in the tree, > >> >> so long as we have proper bindings. My point here is we only need > >> >> either: > >> >> > >> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?) > >> >> b. two devicetrees, one for use in firmware and one for passing to > Linux > >> >> > >> >> We don't need to separate out the U-Boot properties into a second (or > >> >> third) devicetree. There just isn't any point. > >> >> > >> >> > > >> >> > > b) Well then > >> >> > > U-Boot can have its own small devicetree with its bits and then > U-Boot > >> >> > > can merge the two when it starts. Again that is not very > efficient. It > >> >> > > means that U-Boot cannot be controlled by the prior stage (e.g. > to get > >> >> > > its public key from there or to enable/disable the console), so > >> >> > > unified firmware config is not possible. It will get very > confusing, > >> >> > > particularly for debugging U-Boot. c) Some other scheme to avoid > >> >> > > accepting step 3...please stop! > >> >> > > > >> >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up > out of > >> >> > > whole cloth. What about that? Well, we are just going to have to > deal > >> >> > > with that. We can easily merge in the U-Boot nodes/properties and > >> >> > > update the U-Boot CI scripts to do this, as needed, e.g. with > >> >> > > qemu-riscv64_spl. It's only one use case, although Xen might do > >> >> > > something similar. > >> >> > > > >> >> > > To my mind, that deals with both the build-time and run-time > issues. > >> >> > > We have a discoverable DT in U-Boot, which should be considered > the > >> >> > > source of truth for most boards. We can sync it with Linux > >> >> > > automatically with the tooling that I hope Rob Herring will come > up > >> >> > > with. We can use an empty one where there really is no default, > >> >> > > although I'd argue that is making perfect an enemy of the good. > >> >> > > > >> >> > > Step 5: If we get clever and want to remove them from the U-Boot > tree > >> >> > > and pick them up from somewhere else, we can do that with > sufficient > >> >> > > tooling. Perhaps we should set a timeline for that? A year? Two? > Six? > >> >> > > >> >> > We can start slowly migrating boards and see how that works out. > >> >> > We could either use 2 device trees as you proposed, or have u-boot > merge > >> >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH > I'd prefer > >> >> > if linux gets handed a clean device tree without the u-boot > internals in > >> >> > it, so I think 2 discrete DTs is cleaner overall. > >> >> > >> >> I know you would prefer that, but does it really matter in practice? > >> >> What is the objection, actually? > >> >> > >> >> As I mentioned on the call, I think the prior stage should do any > >> >> merging or fixing up. Trying to do that sort of thing in 'early' code > >> >> in U-Boot (or any other program, including Linux) is such a pain. > With > >> >> U-Boot, for example, we don't even have any RAM available to do it > >> >> with half the time and it would dramatically increase the amount of > >> >> memory needed prior to relocation. It just isn't a very good idea to > >> >> try to do this in early code. It is also completely unnecessary, once > >> >> you get past the philosophical objections. > >> >> > >> >> If TF-A wants to be in the picture, let it deal with the implications > >> >> and responsibility thus incurred. TF-A has no right to tell U-Boot > how > >> >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter > >> >> of the size of U-Boot. It duplicates loads of things in there. No one > >> >> will even *notice* an FDT merge function, which is actually only 70 > >> >> LOC: > >> >> > >> >> /** > >> >> * overlay_apply_node - Merges a node into the base device tree > >> >> * @fdt: Base Device Tree blob > >> >> * @target: Node offset in the base device tree to apply the > fragment to > >> >> * @fdto: Device tree overlay blob > >> >> * @node: Node offset in the overlay holding the changes to merge > >> >> * > >> >> * overlay_apply_node() merges a node into a target base device tree > >> >> * node pointed. > >> >> * > >> >> * This is part of the final step in the device tree overlay > >> >> * application process, when all the phandles have been adjusted and > >> >> * resolved and you just have to merge overlay into the base device > >> >> * tree. > >> >> * > >> >> * returns: > >> >> * 0 on success > >> >> * Negative error code on failure > >> >> */ > >> >> static int overlay_apply_node(void *fdt, int target, > >> >> void *fdto, int node) > >> >> { > >> >> int property; > >> >> int subnode; > >> >> > >> >> fdt_for_each_property_offset(property, fdto, node) { > >> >> const char *name; > >> >> const void *prop; > >> >> int prop_len; > >> >> int ret; > >> >> > >> >> prop = fdt_getprop_by_offset(fdto, property, &name, > >> >> &prop_len); > >> >> if (prop_len == -FDT_ERR_NOTFOUND) > >> >> return -FDT_ERR_INTERNAL; > >> >> if (prop_len < 0) > >> >> return prop_len; > >> >> > >> >> ret = fdt_setprop(fdt, target, name, prop, prop_len); > >> >> if (ret) > >> >> return ret; > >> >> } > >> >> > >> >> fdt_for_each_subnode(subnode, fdto, node) { > >> >> const char *name = fdt_get_name(fdto, subnode, NULL); > >> >> int nnode; > >> >> int ret; > >> >> > >> >> nnode = fdt_add_subnode(fdt, target, name); > >> >> if (nnode == -FDT_ERR_EXISTS) { > >> >> nnode = fdt_subnode_offset(fdt, target, name); > >> >> if (nnode == -FDT_ERR_NOTFOUND) > >> >> return -FDT_ERR_INTERNAL; > >> >> } > >> >> > >> >> if (nnode < 0) > >> >> return nnode; > >> >> > >> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode); > >> >> if (ret) > >> >> return ret; > >> >> } > >> >> > >> >> return 0; > >> >> > >> >> > >> >> > >> >> } > >> >> > >> >> > >> >> > > >> >> > Regards > >> >> > /Ilias > >> >> > > > >> >> > > To repeat, if we set things up correctly and agree on the > bindings, > >> >> > > devicetree can be the unifying configuration mechanism through > the > >> >> > > whole of firmware (except for very early bits) and into the OS. > I feel > >> >> > > this will set us up very well to deal with the complexity that is > >> >> > > coming. > >> >> > > > >> >> > >> >> Regards, > >> >> Simon > > > > -- > > François-Frédéric Ozog | Director Business Development > > T: +33.67221.6485 > > francois.ozog@linaro.org | Skype: ffozog > > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog [-- Attachment #2: Type: text/html, Size: 27251 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-28 16:25 ` François Ozog @ 2021-11-02 14:59 ` Simon Glass 0 siblings, 0 replies; 73+ messages in thread From: Simon Glass @ 2021-11-02 14:59 UTC (permalink / raw) To: François Ozog Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari Hi François, On Thu, 28 Oct 2021 at 10:26, François Ozog <francois.ozog@linaro.org> wrote: > > Hi Simon > > Le jeu. 28 oct. 2021 à 17:44, Simon Glass <sjg@chromium.org> a écrit : >> >> Hi François, >> >> On Thu, 28 Oct 2021 at 08:50, François Ozog <francois.ozog@linaro.org> wrote: >> > >> > Hi Simon >> > >> > Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit : >> >> >> >> Hi François, >> >> >> >> On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> wrote: >> >> > >> >> > Hi Simon, >> >> > >> >> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit : >> >> >> >> >> >> Hi Ilias, >> >> >> >> >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas >> >> >> <ilias.apalodimas@linaro.org> wrote: >> >> >> > >> >> >> > Hi Simon, >> >> >> > >> >> >> > A bit late to the party, sorry! >> >> >> >> >> >> (Did you remember the beer? I am replying to this but I don't think it >> >> >> is all that helpful for me to reply to a lot of things on this thread, >> >> >> since I would not be adding much to my cover letter and patches) >> >> >> >> >> >> > >> >> >> > [...] >> >> >> > >> >> >> > > > >> >> >> > > > I really want to see what the binary case looks like since we could then >> >> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could >> >> >> > > > then also do a rpi_arm32_defconfig too. >> >> >> > > > >> >> >> > > > I want to see less device trees in U-Boot sources, if they can come >> >> >> > > > functionally correct from the hardware/our caller. >> >> >> > > > >> >> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't >> >> >> > > > use the device tree from build time at run time, ignoring the device >> >> >> > > > tree provided to us at run time by the caller. >> >> >> > > >> >> >> > > Firstly I should say that I find building firmware very messy and >> >> >> > > confusing these days. Lots of things to build and it's hard to find >> >> >> > > the instructions. It doesn't have to be that way, but if we carry on >> >> >> > > as we are, it will continue to be messy and in five years you will >> >> >> > > need a Ph.D and a lucky charm to boot on any modern board. My >> >> >> > > objective here is to simplify things, bringing some consistency to the >> >> >> > > different components. Binman was one effort there. I feel that putting >> >> >> > > at least the U-Boot house in order, in my role as devicetree >> >> >> > > maintainer (and as author of devicetree support in U-Boot back in >> >> >> > > 2011), is the next step. >> >> >> > > >> >> >> > > If we set things up correctly and agree on the bindings, devicetree >> >> >> > > can be the unifying configuration mechanism through the whole of >> >> >> > > firmware (except for very early bits) and into the OS, this will set >> >> >> > > us up very well to deal with the complexity that is coming. >> >> >> > > >> >> >> > > Anyway, here are the mental steps that I've gone through over the past >> >> >> > > two months: >> >> >> > > >> >> >> > > Step 1: At present, some people think U-Boot is not even allowed to >> >> >> > > have its own nodes/properties in the DT. It is an abuse of the >> >> >> > > devicetree standard, like the /chosen node but with less history. We >> >> >> > > should sacrifice efficiency, expedience and expandability on the altar >> >> >> > > of 'devicetree is a hardware description'. How do we get over that >> >> >> > > one? Wel, I just think we need to accept that U-Boot uses devicetree >> >> >> > > for its own purposes, as well as for booting the OS. I am not saying >> >> >> > > it always has to have those properties, but with existing features >> >> >> > > like verified boot, SPL as well as complex firmware images where >> >> >> > > U-Boot needs to be able to find things in the image, it is essential. >> >> >> > > So let's just assume that we need this everywhere, since we certainly >> >> >> > > need it in at least some places. >> >> >> > > >> >> >> > > (stop reading here if you disagree, because nothing below will make >> >> >> > > any sense...you can still use U-Boot v2011.06 which doesn't have >> >> >> > > OF_CONTROL :-) >> >> >> > >> >> >> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding >> >> >> > that to the DTs that are copied over from linux isn't imho. There are >> >> >> > various reasons for that. First of all syncing device trees is a huge pain >> >> >> > and that's probably one of the main reasons our DTs are out of sync for a >> >> >> > large number of boards. >> >> >> > The point is this was fine in 2011 were we had SPL only, but the reality >> >> >> > today is completely different. There's previous stage boot loaders (and >> >> >> > enough cases were vendors prefer those over SPL). If that bootloader needs >> >> >> > to use it's own device tree for whatever reason, imposing restrictions on >> >> >> > it wrt to the device tree it has to include, and require them to have >> >> >> > knowledge of U-Boot and it's internal config mechanism makes no sense not >> >> >> > to mention it doesn't scale at all. >> >> >> >> >> >> I think the solution here may be the binman image packer. It works >> >> >> from a description of the image (i.e. is data-driver) and can collect >> >> >> all the pieces together. The U-Boot properties (and the ones required >> >> >> by TF-A, etc.) can be added at package time. >> >> >> >> >> >> If you think about it, it doesn't matter what properties are in the DT >> >> >> that is put into the firmware image. TF-A, for example, is presumably >> >> >> reading a devicetree from flash, so what does it care if it has some >> >> >> U-Boot properties in it? >> >> > >> >> > >> >> > I am going to change my position in all mail threads I participate. >> >> > I was trying to make patches relevant in the future and conceptually clean. That may not be the most effective position: I should just care about Linaro and its members being able to implement SystemReady concepts. >> >> > >> >> > >> >> > If you mandate U-Boot has nodes in the device tree passed to the OS, we can put DT fragment in the nt_fw_config section of the fip and merge it at boot time. So there is a solution compatible with SystemReady. >> >> > >> >> > If you want to put fake, non future proof, DT sources in the dts for platforms that are organized to provide the authoritative DT to U-Boot at runtime, that's kind of your choice (hopefully representing the rest of U-Boot community). There will be quirk code in U-Boot to redo the adaptations on its non authoritative DT that the platform previous stage firmware does (already saw one in the past month); as Mark said there will be issues over time; and it will confuse people about the role of the DT. But I am fine with it as it does not impair Linaro and its members ability to implement SystemReady way of handling DT. >> >> >> >> OK thank you. It doesn't sound like you are very on-board though. >> >> Also, you mischaracterise my intent with in-tree devicetrees. >> >> >> >> I would be happy enough for now if you could accept that U-Boot has >> >> nodes/properties of its own in the devicetree. It has been a feature >> >> of U-Boot for 10 years now. >> > >> > On SystemReady systems the DT passed to U-Boot for the OS will be assembled from the board DT and a U-Boot fragment/overlay. The board DT is free from any software/firmware aspects, just contains hardware description. The U-Boot fragment/overlay can contain any nodes it wants. The location of the bindings specification is essentially irrelevant: it could be devicetree.org, U-Boot doc or Linux kernel. Both DTs will be stored in the FIP. OEMs making their firmware will just put whatever is needed in this “dynamic config” DT. On SystemReady platforms U-Boot will always be given a DT, like on the RPI4. U-Boot will be able to ignore it obviously. That said, doing so, a platform may end-up failing compliance tests. >> > I think we need to document the above in U-Boot and refer to relevant specifications. I’ll let Ilias propose something. >> >> Hmm. So long as OF_BOARD is enabled, the devicetree will not be 'ignored'. >> >> Are you talking here about what TF-A will do? I assume so, since you >> mention FIP and I believe that is a TF-A invention. > > Yes >> >> >> Of course the image is all packaged together in fact, so binman could >> presumably merge the DTs at build time, if desired. > > Practically I don’t think so. The passed device tree will contain all authoritative information such as discovered normal memory (excluded the secure memory ranges), architectural nodes such as PSCI and other nodes coming from TEE-OS or secure partitions such as SCMI interface or firmwareTPM. > If you combine the two static parts at build time you will have to extract the runtime pieces from the DT passed to U-Boot. This could be the subject of some future discussion, perhaps, as I don't think we are talking about the same thing. I am talking about the DT packaged in the firmware, but I think you are talking about the things detected at runtime. Binman is for the first problem, not the second. Regards, Simon >> >> >> >> Regards, >> Simon >> >> >> >> >> >> >> >> >> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot, >> >> >> so I think this can be dealt with. >> >> >> >> >> >> > >> >> >> > > >> >> >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get >> >> >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch >> >> >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we >> >> >> > > have binman definitions, etc. So we need a way to overlay those things >> >> >> > > into the DT. We already support this for in-tree DTs, so IMO this is >> >> >> > > easy. Just require every board to have an in-tree DT. It helps with >> >> >> > > discoverability and documentation, anyway. That is this series. >> >> >> > > >> >> >> > >> >> >> > Again, the board might decide for it's own reason to provide it's own DT. >> >> >> > IMHO U-Boot must be able to cope with that and asking DTs to be included in >> >> >> > U-Boot source is not the right way to do that, not to mention cases were >> >> >> > that's completely unrealistic (e.g QEMU or a board that reads the DTB from >> >> >> > it's flash). >> >> >> >> >> >> I think you are at step 2. See above for my response. >> >> >> >> >> >> > >> >> >> > > (I think most of us are at the beginning of step 2, unsure about it >> >> >> > > and worried about step 3) >> >> >> > > >> >> >> > > Step 3: Ah, but there are flows (i.e. boards that use a particular >> >> >> > > flow only, or boards that sometimes use a flow) which need the DT to >> >> >> > > come from a prior stage. How to handle that? IMO that is only going to >> >> >> > > grow as every man and his dog get into the write-a-bootloader >> >> >> > > business. >> >> >> > >> >> >> > And that's exactly why we have to come up with something that scales, without >> >> >> > having to add a bunch of unusable DTs in U-Boot. >> >> >> >> >> >> In what way does this not scale? How are the DTs unusable? If there is >> >> >> a standard binding, we should be fine. >> >> >> >> >> >> > >> >> >> > > We need a way to provide the U-Boot nodes/properties in a >> >> >> > > form that the prior stage can consume and integrate with its build >> >> >> > > system. Is TF-A the only thing being discussed here? If so, let's just >> >> >> > > do it. We have the u-boot.dtsi and we can use binman to put the image >> >> >> > > together, for example. Or we can get clever and create some sort of >> >> >> > > overlay dtb. >> >> >> > > >> >> >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff >> >> >> > > then it will need to build it in and use two devicetrees, one internal >> >> >> > > and one from the prior stage....well that is not very efficient and it >> >> >> > > is going to be confusing for people to figure out what U-Boot is >> >> >> > > actually doing. But we actually already do that in a lot of cases >> >> >> > > where U-Boot passes a DT to the kernel which is different to the one >> >> >> > > it uses. So perhaps we have three devicetrees? OMG. >> >> >> > >> >> >> > No we don't. That's a moot point. If you separate the DTs U-Boot >> >> >> > provides the internal one and inherits one 'generic'. Linux will be able to use >> >> >> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the >> >> >> > DT across kernel versions, In which case there's not much you can do to >> >> >> > begin with and that's already a case we have to deal with. >> >> >> >> >> >> Linux actually doesn't care if the U-Boot properties are in the tree, >> >> >> so long as we have proper bindings. My point here is we only need >> >> >> either: >> >> >> >> >> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?) >> >> >> b. two devicetrees, one for use in firmware and one for passing to Linux >> >> >> >> >> >> We don't need to separate out the U-Boot properties into a second (or >> >> >> third) devicetree. There just isn't any point. >> >> >> >> >> >> > >> >> >> > > b) Well then >> >> >> > > U-Boot can have its own small devicetree with its bits and then U-Boot >> >> >> > > can merge the two when it starts. Again that is not very efficient. It >> >> >> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get >> >> >> > > its public key from there or to enable/disable the console), so >> >> >> > > unified firmware config is not possible. It will get very confusing, >> >> >> > > particularly for debugging U-Boot. c) Some other scheme to avoid >> >> >> > > accepting step 3...please stop! >> >> >> > > >> >> >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of >> >> >> > > whole cloth. What about that? Well, we are just going to have to deal >> >> >> > > with that. We can easily merge in the U-Boot nodes/properties and >> >> >> > > update the U-Boot CI scripts to do this, as needed, e.g. with >> >> >> > > qemu-riscv64_spl. It's only one use case, although Xen might do >> >> >> > > something similar. >> >> >> > > >> >> >> > > To my mind, that deals with both the build-time and run-time issues. >> >> >> > > We have a discoverable DT in U-Boot, which should be considered the >> >> >> > > source of truth for most boards. We can sync it with Linux >> >> >> > > automatically with the tooling that I hope Rob Herring will come up >> >> >> > > with. We can use an empty one where there really is no default, >> >> >> > > although I'd argue that is making perfect an enemy of the good. >> >> >> > > >> >> >> > > Step 5: If we get clever and want to remove them from the U-Boot tree >> >> >> > > and pick them up from somewhere else, we can do that with sufficient >> >> >> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? >> >> >> > >> >> >> > We can start slowly migrating boards and see how that works out. >> >> >> > We could either use 2 device trees as you proposed, or have u-boot merge >> >> >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer >> >> >> > if linux gets handed a clean device tree without the u-boot internals in >> >> >> > it, so I think 2 discrete DTs is cleaner overall. >> >> >> >> >> >> I know you would prefer that, but does it really matter in practice? >> >> >> What is the objection, actually? >> >> >> >> >> >> As I mentioned on the call, I think the prior stage should do any >> >> >> merging or fixing up. Trying to do that sort of thing in 'early' code >> >> >> in U-Boot (or any other program, including Linux) is such a pain. With >> >> >> U-Boot, for example, we don't even have any RAM available to do it >> >> >> with half the time and it would dramatically increase the amount of >> >> >> memory needed prior to relocation. It just isn't a very good idea to >> >> >> try to do this in early code. It is also completely unnecessary, once >> >> >> you get past the philosophical objections. >> >> >> >> >> >> If TF-A wants to be in the picture, let it deal with the implications >> >> >> and responsibility thus incurred. TF-A has no right to tell U-Boot how >> >> >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter >> >> >> of the size of U-Boot. It duplicates loads of things in there. No one >> >> >> will even *notice* an FDT merge function, which is actually only 70 >> >> >> LOC: >> >> >> >> >> >> /** >> >> >> * overlay_apply_node - Merges a node into the base device tree >> >> >> * @fdt: Base Device Tree blob >> >> >> * @target: Node offset in the base device tree to apply the fragment to >> >> >> * @fdto: Device tree overlay blob >> >> >> * @node: Node offset in the overlay holding the changes to merge >> >> >> * >> >> >> * overlay_apply_node() merges a node into a target base device tree >> >> >> * node pointed. >> >> >> * >> >> >> * This is part of the final step in the device tree overlay >> >> >> * application process, when all the phandles have been adjusted and >> >> >> * resolved and you just have to merge overlay into the base device >> >> >> * tree. >> >> >> * >> >> >> * returns: >> >> >> * 0 on success >> >> >> * Negative error code on failure >> >> >> */ >> >> >> static int overlay_apply_node(void *fdt, int target, >> >> >> void *fdto, int node) >> >> >> { >> >> >> int property; >> >> >> int subnode; >> >> >> >> >> >> fdt_for_each_property_offset(property, fdto, node) { >> >> >> const char *name; >> >> >> const void *prop; >> >> >> int prop_len; >> >> >> int ret; >> >> >> >> >> >> prop = fdt_getprop_by_offset(fdto, property, &name, >> >> >> &prop_len); >> >> >> if (prop_len == -FDT_ERR_NOTFOUND) >> >> >> return -FDT_ERR_INTERNAL; >> >> >> if (prop_len < 0) >> >> >> return prop_len; >> >> >> >> >> >> ret = fdt_setprop(fdt, target, name, prop, prop_len); >> >> >> if (ret) >> >> >> return ret; >> >> >> } >> >> >> >> >> >> fdt_for_each_subnode(subnode, fdto, node) { >> >> >> const char *name = fdt_get_name(fdto, subnode, NULL); >> >> >> int nnode; >> >> >> int ret; >> >> >> >> >> >> nnode = fdt_add_subnode(fdt, target, name); >> >> >> if (nnode == -FDT_ERR_EXISTS) { >> >> >> nnode = fdt_subnode_offset(fdt, target, name); >> >> >> if (nnode == -FDT_ERR_NOTFOUND) >> >> >> return -FDT_ERR_INTERNAL; >> >> >> } >> >> >> >> >> >> if (nnode < 0) >> >> >> return nnode; >> >> >> >> >> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode); >> >> >> if (ret) >> >> >> return ret; >> >> >> } >> >> >> >> >> >> return 0; >> >> >> >> >> >> >> >> >> >> >> >> } >> >> >> >> >> >> >> >> >> > >> >> >> > Regards >> >> >> > /Ilias >> >> >> > > >> >> >> > > To repeat, if we set things up correctly and agree on the bindings, >> >> >> > > devicetree can be the unifying configuration mechanism through the >> >> >> > > whole of firmware (except for very early bits) and into the OS. I feel >> >> >> > > this will set us up very well to deal with the complexity that is >> >> >> > > coming. >> >> >> > > >> >> >> >> >> >> Regards, >> >> >> Simon >> > >> > -- >> > François-Frédéric Ozog | Director Business Development >> > T: +33.67221.6485 >> > francois.ozog@linaro.org | Skype: ffozog >> > > > -- > François-Frédéric Ozog | Director Business Development > T: +33.67221.6485 > francois.ozog@linaro.org | Skype: ffozog > ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-28 2:50 ` Simon Glass 2021-10-28 8:21 ` François Ozog @ 2021-11-01 11:04 ` Ilias Apalodimas 2021-11-02 10:06 ` Michael Walle 2021-11-02 14:59 ` Simon Glass 1 sibling, 2 replies; 73+ messages in thread From: Ilias Apalodimas @ 2021-11-01 11:04 UTC (permalink / raw) To: Simon Glass Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stephen Warren, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, François Ozog, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari Hi Simon, On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote: > > Hi Ilias, > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > <ilias.apalodimas@linaro.org> wrote: > > > > Hi Simon, > > > > A bit late to the party, sorry! > > (Did you remember the beer? We'll probably need something stronger to sort this out :) > I am replying to this but I don't think it > is all that helpful for me to reply to a lot of things on this thread, > since I would not be adding much to my cover letter and patches) > > > > > [...] > > > > > > > > > > I really want to see what the binary case looks like since we could then > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > functionally correct from the hardware/our caller. > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > > use the device tree from build time at run time, ignoring the device > > > > tree provided to us at run time by the caller. > > > > > > Firstly I should say that I find building firmware very messy and > > > confusing these days. Lots of things to build and it's hard to find > > > the instructions. It doesn't have to be that way, but if we carry on > > > as we are, it will continue to be messy and in five years you will > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > objective here is to simplify things, bringing some consistency to the > > > different components. Binman was one effort there. I feel that putting > > > at least the U-Boot house in order, in my role as devicetree > > > maintainer (and as author of devicetree support in U-Boot back in > > > 2011), is the next step. > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > can be the unifying configuration mechanism through the whole of > > > firmware (except for very early bits) and into the OS, this will set > > > us up very well to deal with the complexity that is coming. > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > two months: > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > have its own nodes/properties in the DT. It is an abuse of the > > > devicetree standard, like the /chosen node but with less history. We > > > should sacrifice efficiency, expedience and expandability on the altar > > > of 'devicetree is a hardware description'. How do we get over that > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > for its own purposes, as well as for booting the OS. I am not saying > > > it always has to have those properties, but with existing features > > > like verified boot, SPL as well as complex firmware images where > > > U-Boot needs to be able to find things in the image, it is essential. > > > So let's just assume that we need this everywhere, since we certainly > > > need it in at least some places. > > > > > > (stop reading here if you disagree, because nothing below will make > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > OF_CONTROL :-) > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > that to the DTs that are copied over from linux isn't imho. There are > > various reasons for that. First of all syncing device trees is a huge pain > > and that's probably one of the main reasons our DTs are out of sync for a > > large number of boards. > > The point is this was fine in 2011 were we had SPL only, but the reality > > today is completely different. There's previous stage boot loaders (and > > enough cases were vendors prefer those over SPL). If that bootloader needs > > to use it's own device tree for whatever reason, imposing restrictions on > > it wrt to the device tree it has to include, and require them to have > > knowledge of U-Boot and it's internal config mechanism makes no sense not > > to mention it doesn't scale at all. > > I think the solution here may be the binman image packer. It works > from a description of the image (i.e. is data-driver) and can collect > all the pieces together. The U-Boot properties (and the ones required > by TF-A, etc.) can be added at package time. I am not sure I am following you here or why binman is relevant to this discussion. If the boot process doesn't require a FIP (e.g SPL + U-Boot proper or SPL -> EL3 -> U-Boot proper or TF-A + U-Boot) then using binman makes a lot of sense. If the boot process is TF-A -> U-Boot and requires a FIP, TF-A has it's own set of tools for preparing that [1] [2] , why would we want to teach binman FIP packaging? And if we do are you willing to keep it up to date with everything they come up with? IOW packaging the firmware is not U-Boot's responsibility, it's the vendors. Why should he not be able to choose FIP? (ST already changed that in u-boot btw). > > If you think about it, it doesn't matter what properties are in the DT > that is put into the firmware image. TF-A, for example, is presumably > reading a devicetree from flash, so what does it care if it has some > U-Boot properties in it? It doesn't, but the point here is entirely different. Today there's a number of U-Boot DTBs that are unable to boot a kernel. The direction we would like to is have the firmware provide a DTB that's usable for the kernel. Yes I know vendors mess things up and there's a correlation of the DTB and the kernel version, but let's set that aside for a moment. If we want to use a 'generic' DT then we have to make sure that whoever packages it knows what to put in there. That's why for me, it's very important to only allow *upstreamed only* DT properties for whoever ends up being responsible for the packaging. In that case you can demand TF-A to bundle U-Boot nodes in the DTB it produces if the board is supposed to use U-Boot. If those are internal only to U-Boot and not upstreamed this makes little sense to me and I don't see why people will agree to that. > > As to syncing, we have solved this using u-boot.dtsi files in U-Boot, > so I think this can be dealt with. > > > > > > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > have binman definitions, etc. So we need a way to overlay those things > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > easy. Just require every board to have an in-tree DT. It helps with > > > discoverability and documentation, anyway. That is this series. > > > > > > > Again, the board might decide for it's own reason to provide it's own DT. > > IMHO U-Boot must be able to cope with that and asking DTs to be included in > > U-Boot source is not the right way to do that, not to mention cases were > > that's completely unrealistic (e.g QEMU or a board that reads the DTB from > > it's flash). > > I think you are at step 2. See above for my response. > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > and worried about step 3) > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > flow only, or boards that sometimes use a flow) which need the DT to > > > come from a prior stage. How to handle that? IMO that is only going to > > > grow as every man and his dog get into the write-a-bootloader > > > business. > > > > And that's exactly why we have to come up with something that scales, without > > having to add a bunch of unusable DTs in U-Boot. > > In what way does this not scale? How are the DTs unusable? If there is > a standard binding, we should be fine. The keyword here is the definition of 'standard'. If standard means upstreamed to DT spec, as I said before I don't see any problem. By unusable I was referring to the QEMU DTs you are trying to push into U-Boot or the RPI one. It doesn't scale because you have to maintain and upstream all the DTs in the U-Boot tree. The story so far is merge and forget for a big number of DTs, so I find it hard to believe that everyone will start behaving and sync up their DTs. I'd much rather prefer having a central repo and force people to use that. > > > > > > We need a way to provide the U-Boot nodes/properties in a > > > form that the prior stage can consume and integrate with its build > > > system. Is TF-A the only thing being discussed here? If so, let's just > > > do it. We have the u-boot.dtsi and we can use binman to put the image > > > together, for example. Or we can get clever and create some sort of > > > overlay dtb. > > > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > > then it will need to build it in and use two devicetrees, one internal > > > and one from the prior stage....well that is not very efficient and it > > > is going to be confusing for people to figure out what U-Boot is > > > actually doing. But we actually already do that in a lot of cases > > > where U-Boot passes a DT to the kernel which is different to the one > > > it uses. So perhaps we have three devicetrees? OMG. > > > > No we don't. That's a moot point. If you separate the DTs U-Boot > > provides the internal one and inherits one 'generic'. Linux will be able to use > > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the > > DT across kernel versions, In which case there's not much you can do to > > begin with and that's already a case we have to deal with. > > Linux actually doesn't care if the U-Boot properties are in the tree, > so long as we have proper bindings. My point here is we only need > either: > > a. one devicetree, shared with Linux and U-Boot (and TF-A?) > b. two devicetrees, one for use in firmware and one for passing to Linux > > We don't need to separate out the U-Boot properties into a second (or > third) devicetree. There just isn't any point. Again if we are talking about bindings that are upstream in the spec, then we agree. Depending on the SRAM limitation we can even do (a). If the vendor messes up the DT backwards compatibility then we can do (b). If you expect TF-A and FIP to go pick up the special bindings U-Boot needs, then we disagree. > > > > > > b) Well then > > > U-Boot can have its own small devicetree with its bits and then U-Boot > > > can merge the two when it starts. Again that is not very efficient. It > > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > > its public key from there or to enable/disable the console), so > > > unified firmware config is not possible. It will get very confusing, > > > particularly for debugging U-Boot. c) Some other scheme to avoid > > > accepting step 3...please stop! > > > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > > whole cloth. What about that? Well, we are just going to have to deal > > > with that. We can easily merge in the U-Boot nodes/properties and > > > update the U-Boot CI scripts to do this, as needed, e.g. with > > > qemu-riscv64_spl. It's only one use case, although Xen might do > > > something similar. > > > > > > To my mind, that deals with both the build-time and run-time issues. > > > We have a discoverable DT in U-Boot, which should be considered the > > > source of truth for most boards. We can sync it with Linux > > > automatically with the tooling that I hope Rob Herring will come up > > > with. We can use an empty one where there really is no default, > > > although I'd argue that is making perfect an enemy of the good. > > > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > > and pick them up from somewhere else, we can do that with sufficient > > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > > > We can start slowly migrating boards and see how that works out. > > We could either use 2 device trees as you proposed, or have u-boot merge > > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer > > if linux gets handed a clean device tree without the u-boot internals in > > it, so I think 2 discrete DTs is cleaner overall. > > I know you would prefer that, but does it really matter in practice? > What is the objection, actually? > > As I mentioned on the call, I think the prior stage should do any > merging or fixing up. Trying to do that sort of thing in 'early' code > in U-Boot (or any other program, including Linux) is such a pain. With > U-Boot, for example, we don't even have any RAM available to do it > with half the time and it would dramatically increase the amount of > memory needed prior to relocation. It just isn't a very good idea to > try to do this in early code. It is also completely unnecessary, once > you get past the philosophical objections. > > If TF-A wants to be in the picture, let it deal with the implications > and responsibility thus incurred. TF-A has no right to tell U-Boot how > to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter > of the size of U-Boot. It duplicates loads of things in there. No one > will even *notice* an FDT merge function, which is actually only 70 > LOC: > Again I am repeating myself so here's a tl;dr of how I view this: 1. All DT bindings u-boot expect become part of the DT spec -- I am fine with whatever, since at this point it makes sense to say "You are booting u-boot go add whatever it expects, it's part of the spec". The prior stage boot loader can then obviously merge the DT fragments and everyone will be happy. 2. For the bindings that are not upstreamed, I'd prefer having u-boot do the fixup. Alternatively, we could provide fragments that are easy for TF-A to merge? By easy I don't mean read U-Boot code, it's .dts files, find the fragments you need and add them manually... [...] [1] https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_FW_CONFIG [2] https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot-build.html Regards /Ilias ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-11-01 11:04 ` Ilias Apalodimas @ 2021-11-02 10:06 ` Michael Walle 2021-11-02 12:34 ` François Ozog 2021-11-02 14:59 ` Simon Glass 1 sibling, 1 reply; 73+ messages in thread From: Michael Walle @ 2021-11-02 10:06 UTC (permalink / raw) To: ilias.apalodimas Cc: liviu.dudau, narmstrong, rick, vladimir.oltean, linus.walleij, fitzsim, kever.yang, seanga2, atish.patra, zong.li, sr, festevam, rainer.boschung, francois.ozog, swarren, oleksandr_andrushchenko, xypron.glpk, lusus, michal.simek, marek.behun, vanbaren, rfried.dev, jagan, valentin.longchamp, hs, pbrobinson, sinan, bin.meng, wd, swarren, andre.przywara, tharvey, ashok.reddy.soma, qemu-devel, agraf, green.wan, t.karthik.reddy, anastasiia_lukianenko, albert.u.boot, monstr, mbrugger, ycliang, kristo, u-boot, david.abdurachmanov, priyanka.jain, sjg, christianshewitt, awilliams, tuomas.tynkkynen, heinrich.schuchardt, tianrui-wei, bmeng.cn, pali, trini, dimitri.ledkov, padmarao.begari Hi, > On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote: > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > > <ilias.apalodimas@linaro.org> wrote: .. > > Linux actually doesn't care if the U-Boot properties are in the tree, > > so long as we have proper bindings. My point here is we only need > > either: > > > > a. one devicetree, shared with Linux and U-Boot (and TF-A?) > > b. two devicetrees, one for use in firmware and one for passing to Linux > > > > We don't need to separate out the U-Boot properties into a second (or > > third) devicetree. There just isn't any point. > > Again if we are talking about bindings that are upstream in the spec, > then we agree. Depending on the SRAM limitation we can even do (a). > If the vendor messes up the DT backwards compatibility then we can do > (b). If you expect TF-A and FIP to go pick up the special bindings > U-Boot needs, then we disagree. *puts developer at board vendor hat on* Sometimes (personally I'd say usually) it isn't possible to have a backwards compatible tree. Also, like it or not, in the device tree there *are* configuration options which are not hardware dependent (eg. internal ethernet connection on the ls1028a). So a vendor doesn't necessarily need to "mess things up" to need (b). And as you know, my point is, that this device tree has to come from the distribution, it must not be compiled in into the firmware. I feel like I've repeated this far too many times. Therefore, this will be my last comment about it and I would really like to see that this - very real - scenario is treated as a valid use case and will be supported in your systemready vision. -michael ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-11-02 10:06 ` Michael Walle @ 2021-11-02 12:34 ` François Ozog 0 siblings, 0 replies; 73+ messages in thread From: François Ozog @ 2021-11-02 12:34 UTC (permalink / raw) To: Michael Walle Cc: liviu.dudau, narmstrong, rick, vladimir.oltean, linus.walleij, bin.meng, kever.yang, seanga2, atish.patra, zong.li, sr, festevam, rainer.boschung, trini, swarren, oleksandr_andrushchenko, xypron.glpk, lusus, michal.simek, marek.behun, vanbaren, rfried.dev, jagan, valentin.longchamp, hs, pbrobinson, sinan, fitzsim, wd, swarren, andre.przywara, tharvey, ashok.reddy.soma, qemu-devel, agraf, green.wan, t.karthik.reddy, anastasiia_lukianenko, albert.u.boot, monstr, mbrugger, ycliang, kristo, u-boot, david.abdurachmanov, priyanka.jain, sjg, ilias.apalodimas, christianshewitt, awilliams, tuomas.tynkkynen, heinrich.schuchardt, tianrui-wei, bmeng.cn, pali, dimitri.ledkov, padmarao.begari [-- Attachment #1: Type: text/plain, Size: 3044 bytes --] On Tue, 2 Nov 2021 at 11:07, Michael Walle <michael@walle.cc> wrote: > Hi, > > > On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote: > > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > > > <ilias.apalodimas@linaro.org> wrote: > > .. > > > > Linux actually doesn't care if the U-Boot properties are in the tree, > > > so long as we have proper bindings. My point here is we only need > > > either: > > > > > > a. one devicetree, shared with Linux and U-Boot (and TF-A?) > > > b. two devicetrees, one for use in firmware and one for passing to > Linux > > > > > > We don't need to separate out the U-Boot properties into a second (or > > > third) devicetree. There just isn't any point. > > > > Again if we are talking about bindings that are upstream in the spec, > > then we agree. Depending on the SRAM limitation we can even do (a). > > If the vendor messes up the DT backwards compatibility then we can do > > (b). If you expect TF-A and FIP to go pick up the special bindings > > U-Boot needs, then we disagree. > > *puts developer at board vendor hat on* Sometimes (personally I'd say > usually) it isn't possible to have a backwards compatible tree. Also, > like it or not, in the device tree there *are* configuration options > which are not hardware dependent (eg. internal ethernet connection on > the ls1028a). Are you referring to DPAA2 configuration to create the ethernet port itself ? This is indeed configuration. There are many ways to handle those ones. As well as SerDes configuration to make PCI lanes or MDIO lanes. Yet the two are different in nature: SerDes configuration must match board layout, so it is about "no user choice" configuration. This configuration could be statically defined and attached with the board. But it there is a SoM with a carrier board, we may need to compose that at runtime for development, or make it static build for product packaging. DPAA2 configuration is user choice driven. Those choices can be merged in the DT to be passed to the OS at runtime. There are multiple ways to deal with that, from DT overlays to U-Boot DPAA2 command line extensions that would inject the DT necessary nodes. > So a vendor doesn't necessarily need to "mess things up" > to need (b). And as you know, my point is, that this device tree has > to come from the distribution, it must not be compiled in into the > firmware. > I wouldn't bet that all distro providers will always come with a DT... > > I feel like I've repeated this far too many times. Therefore, this > will be my last comment about it and I would really like to see that > this - very real - scenario is treated as a valid use case and will be > supported in your systemready vision. > I have been building (shared it on the list) a deck to go into those details. I am almost ready to talk to it. > > -michael > -- 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: 5753 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-11-01 11:04 ` Ilias Apalodimas 2021-11-02 10:06 ` Michael Walle @ 2021-11-02 14:59 ` Simon Glass 1 sibling, 0 replies; 73+ messages in thread From: Simon Glass @ 2021-11-02 14:59 UTC (permalink / raw) To: Ilias Apalodimas Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stephen Warren, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, François Ozog, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari Hi Ilias, On Mon, 1 Nov 2021 at 05:05, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > Hi Simon, > > On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote: > > > > Hi Ilias, > > > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > > <ilias.apalodimas@linaro.org> wrote: > > > > > > Hi Simon, > > > > > > A bit late to the party, sorry! > > > > (Did you remember the beer? > > We'll probably need something stronger to sort this out :) Yes I agree! > > > I am replying to this but I don't think it > > is all that helpful for me to reply to a lot of things on this thread, > > since I would not be adding much to my cover letter and patches) > > > > > > > > [...] > > > > > > > > > > > > > I really want to see what the binary case looks like since we could then > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > > > use the device tree from build time at run time, ignoring the device > > > > > tree provided to us at run time by the caller. > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > confusing these days. Lots of things to build and it's hard to find > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > as we are, it will continue to be messy and in five years you will > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > objective here is to simplify things, bringing some consistency to the > > > > different components. Binman was one effort there. I feel that putting > > > > at least the U-Boot house in order, in my role as devicetree > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > 2011), is the next step. > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > can be the unifying configuration mechanism through the whole of > > > > firmware (except for very early bits) and into the OS, this will set > > > > us up very well to deal with the complexity that is coming. > > > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > > two months: > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > have its own nodes/properties in the DT. It is an abuse of the > > > > devicetree standard, like the /chosen node but with less history. We > > > > should sacrifice efficiency, expedience and expandability on the altar > > > > of 'devicetree is a hardware description'. How do we get over that > > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > > for its own purposes, as well as for booting the OS. I am not saying > > > > it always has to have those properties, but with existing features > > > > like verified boot, SPL as well as complex firmware images where > > > > U-Boot needs to be able to find things in the image, it is essential. > > > > So let's just assume that we need this everywhere, since we certainly > > > > need it in at least some places. > > > > > > > > (stop reading here if you disagree, because nothing below will make > > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > > OF_CONTROL :-) > > > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > > that to the DTs that are copied over from linux isn't imho. There are > > > various reasons for that. First of all syncing device trees is a huge pain > > > and that's probably one of the main reasons our DTs are out of sync for a > > > large number of boards. > > > The point is this was fine in 2011 were we had SPL only, but the reality > > > today is completely different. There's previous stage boot loaders (and > > > enough cases were vendors prefer those over SPL). If that bootloader needs > > > to use it's own device tree for whatever reason, imposing restrictions on > > > it wrt to the device tree it has to include, and require them to have > > > knowledge of U-Boot and it's internal config mechanism makes no sense not > > > to mention it doesn't scale at all. > > > > I think the solution here may be the binman image packer. It works > > from a description of the image (i.e. is data-driver) and can collect > > all the pieces together. The U-Boot properties (and the ones required > > by TF-A, etc.) can be added at package time. > > I am not sure I am following you here or why binman is relevant to > this discussion. If the boot process doesn't require a FIP (e.g SPL > + U-Boot proper or SPL -> EL3 -> U-Boot proper or TF-A + U-Boot) then > using binman makes a lot of sense. If the boot process is TF-A -> > U-Boot and requires a FIP, TF-A has it's own set of tools for > preparing that [1] [2] , why would we want to teach binman FIP > packaging? And if we do are you willing to keep it up to date with > everything they come up with? IOW packaging the firmware is not > U-Boot's responsibility, it's the vendors. Why should he not be able > to choose FIP? (ST already changed that in u-boot btw). Binman is a firmware packager. It seems to be the one that is used last, to produce the final image, although I am not sure as this seems quite complicated. My view on firmware is that we should build it step by step with individual projects but then package it all at the end and Binman is designed to do the packaging. https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#motivation So I am not sure what problem FIP solves, or why it was invented, Did we need another firmware format? But if FIP is important, then yes I think support for it should be added to Binman. It will make packaging a lot easier. > > > > > If you think about it, it doesn't matter what properties are in the DT > > that is put into the firmware image. TF-A, for example, is presumably > > reading a devicetree from flash, so what does it care if it has some > > U-Boot properties in it? > > It doesn't, but the point here is entirely different. Today there's a > number of U-Boot DTBs that are unable to boot a kernel. The direction > we would like to is have the firmware provide a DTB that's usable for > the kernel. Yes I know vendors mess things up and there's a > correlation of the DTB and the kernel version, but let's set that > aside for a moment. If we want to use a 'generic' DT then we have to > make sure that whoever packages it knows what to put in there. That's > why for me, it's very important to only allow *upstreamed only* DT > properties for whoever ends up being responsible for the packaging. > In that case you can demand TF-A to bundle U-Boot nodes in the DTB it > produces if the board is supposed to use U-Boot. If those are internal > only to U-Boot and not upstreamed this makes little sense to me and I > don't see why people will agree to that. Well I think all of this is taking too much energy...I have stated my position. U-Boot needs its nodes and properties. > > > > > As to syncing, we have solved this using u-boot.dtsi files in U-Boot, > > so I think this can be dealt with. > > > > > > > > > > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > > have binman definitions, etc. So we need a way to overlay those things > > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > > easy. Just require every board to have an in-tree DT. It helps with > > > > discoverability and documentation, anyway. That is this series. > > > > > > > > > > Again, the board might decide for it's own reason to provide it's own DT. > > > IMHO U-Boot must be able to cope with that and asking DTs to be included in > > > U-Boot source is not the right way to do that, not to mention cases were > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB from > > > it's flash). > > > > I think you are at step 2. See above for my response. > > > > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > > and worried about step 3) > > > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > > flow only, or boards that sometimes use a flow) which need the DT to > > > > come from a prior stage. How to handle that? IMO that is only going to > > > > grow as every man and his dog get into the write-a-bootloader > > > > business. > > > > > > And that's exactly why we have to come up with something that scales, without > > > having to add a bunch of unusable DTs in U-Boot. > > > > In what way does this not scale? How are the DTs unusable? If there is > > a standard binding, we should be fine. > > The keyword here is the definition of 'standard'. If standard means > upstreamed to DT spec, as I said before I don't see any problem. By > unusable I was referring to the QEMU DTs you are trying to push into > U-Boot or the RPI one. It doesn't scale because you have to maintain > and upstream all the DTs in the U-Boot tree. The story so far is > merge and forget for a big number of DTs, so I find it hard to believe > that everyone will start behaving and sync up their DTs. I'd much > rather prefer having a central repo and force people to use that. Well let's see how it goes. If we can get some validation in place, then the picture should get better. > > > > > > > > > > We need a way to provide the U-Boot nodes/properties in a > > > > form that the prior stage can consume and integrate with its build > > > > system. Is TF-A the only thing being discussed here? If so, let's just > > > > do it. We have the u-boot.dtsi and we can use binman to put the image > > > > together, for example. Or we can get clever and create some sort of > > > > overlay dtb. > > > > > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > > > then it will need to build it in and use two devicetrees, one internal > > > > and one from the prior stage....well that is not very efficient and it > > > > is going to be confusing for people to figure out what U-Boot is > > > > actually doing. But we actually already do that in a lot of cases > > > > where U-Boot passes a DT to the kernel which is different to the one > > > > it uses. So perhaps we have three devicetrees? OMG. > > > > > > No we don't. That's a moot point. If you separate the DTs U-Boot > > > provides the internal one and inherits one 'generic'. Linux will be able to use > > > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the > > > DT across kernel versions, In which case there's not much you can do to > > > begin with and that's already a case we have to deal with. > > > > Linux actually doesn't care if the U-Boot properties are in the tree, > > so long as we have proper bindings. My point here is we only need > > either: > > > > a. one devicetree, shared with Linux and U-Boot (and TF-A?) > > b. two devicetrees, one for use in firmware and one for passing to Linux > > > > We don't need to separate out the U-Boot properties into a second (or > > third) devicetree. There just isn't any point. > > Again if we are talking about bindings that are upstream in the spec, > then we agree. Depending on the SRAM limitation we can even do (a). > If the vendor messes up the DT backwards compatibility then we can do > (b). If you expect TF-A and FIP to go pick up the special bindings > U-Boot needs, then we disagree. I would certainly prefer to be talking about bindings that are upstreamed, if they can be upstreamed. I sent a patch with a start on that and then a PR to the repo here: https://github.com/devicetree-org/dt-schema/pull/62 So perhaps we should hold off on this and see how progress is in a month or so. > > > > > > > > > > b) Well then > > > > U-Boot can have its own small devicetree with its bits and then U-Boot > > > > can merge the two when it starts. Again that is not very efficient. It > > > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > > > its public key from there or to enable/disable the console), so > > > > unified firmware config is not possible. It will get very confusing, > > > > particularly for debugging U-Boot. c) Some other scheme to avoid > > > > accepting step 3...please stop! > > > > > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > > > whole cloth. What about that? Well, we are just going to have to deal > > > > with that. We can easily merge in the U-Boot nodes/properties and > > > > update the U-Boot CI scripts to do this, as needed, e.g. with > > > > qemu-riscv64_spl. It's only one use case, although Xen might do > > > > something similar. > > > > > > > > To my mind, that deals with both the build-time and run-time issues. > > > > We have a discoverable DT in U-Boot, which should be considered the > > > > source of truth for most boards. We can sync it with Linux > > > > automatically with the tooling that I hope Rob Herring will come up > > > > with. We can use an empty one where there really is no default, > > > > although I'd argue that is making perfect an enemy of the good. > > > > > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > > > and pick them up from somewhere else, we can do that with sufficient > > > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > > > > > We can start slowly migrating boards and see how that works out. > > > We could either use 2 device trees as you proposed, or have u-boot merge > > > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer > > > if linux gets handed a clean device tree without the u-boot internals in > > > it, so I think 2 discrete DTs is cleaner overall. > > > > I know you would prefer that, but does it really matter in practice? > > What is the objection, actually? > > > > As I mentioned on the call, I think the prior stage should do any > > merging or fixing up. Trying to do that sort of thing in 'early' code > > in U-Boot (or any other program, including Linux) is such a pain. With > > U-Boot, for example, we don't even have any RAM available to do it > > with half the time and it would dramatically increase the amount of > > memory needed prior to relocation. It just isn't a very good idea to > > try to do this in early code. It is also completely unnecessary, once > > you get past the philosophical objections. > > > > If TF-A wants to be in the picture, let it deal with the implications > > and responsibility thus incurred. TF-A has no right to tell U-Boot how > > to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter > > of the size of U-Boot. It duplicates loads of things in there. No one > > will even *notice* an FDT merge function, which is actually only 70 > > LOC: > > > > Again I am repeating myself so here's a tl;dr of how I view this: > 1. All DT bindings u-boot expect become part of the DT spec -- I am > fine with whatever, since at this point it makes sense to say "You are > booting u-boot go add whatever it expects, it's part of the spec". > The prior stage boot loader can then obviously merge the DT fragments > and everyone will be happy. > 2. For the bindings that are not upstreamed, I'd prefer having u-boot > do the fixup. Alternatively, we could provide fragments that are easy > for TF-A to merge? By easy I don't mean read U-Boot code, it's .dts > files, find the fragments you need and add them manually... OK, well then I don't think we have anything of concern here, so long as we can get the bindings agreed. Let's see how it goes. Regards, Simon > > [...] > > [1] https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_FW_CONFIG > [2] https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot-build.html > > Regards > > /Ilias ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-15 18:03 ` Simon Glass 2021-10-26 6:46 ` Ilias Apalodimas @ 2021-10-27 12:48 ` Tom Rini 2021-10-27 13:15 ` François Ozog 1 sibling, 1 reply; 73+ messages in thread From: Tom Rini @ 2021-10-27 12:48 UTC (permalink / raw) To: Simon Glass Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 18102 bytes --] On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > Hi all, > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > Hi François, > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > > > > > >> > > > > > >> Hi Tom, Bin,François, > > > > > >> > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > > > > > >> > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > >> > > Hi Simon, > > > > > >> > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > > >> > > > > > > > > >> > > > 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 at [1]. > > > > > >> > > > > > > > > >> > > > 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. > > > > > >> > > > > > > > >> > > Adding device trees that are never used sounds like a hack to me. > > > > > >> > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > > > > > >> > > command line parameters, and the device tree you put in this series > > > > > >> > > has various hardcoded <phandle> values which normally do not show up > > > > > >> > > in hand-written dts files. > > > > > >> > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > >> > > > > > > >> > I am also confused and do not like the idea of adding device trees for > > > > > >> > platforms that are capable of and can / do have a device tree to give us > > > > > >> > at run time. > > > > > >> > > > > > >> (I'll just reply to this one email, since the same points applies to > > > > > >> all replies I think) > > > > > >> > > > > > >> I have been thinking about this and discussing it with people for a > > > > > >> few months now. I've been signalling a change like this for over a > > > > > >> month now, on U-Boot contributor calls and in discussions with Linaro > > > > > >> people. I sent a patch (below) to try to explain things. I hope it is > > > > > >> not a surprise! > > > > > >> > > > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > > > > > >> Ilias' series and this one we can get ourselves on a stronger footing. > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > > > > > >> For more context: > > > > > >> > > > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > >> > > > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the > > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > > >> maintainer would prefer there was no special support even for booting > > > > > >> Linux directly!) > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > >> > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > >> think the path forward might be to run QEMU twice, once to get its > > > > > >> generated tree and once to give the 'merged' tree with the U-Boot > > > > > >> properties in it, if people want to use U-Boot features. > > > > > >> > > > > > >> I do strongly believe that OF_BOARD must be a run-time option, not a > > > > > >> build-time one. It creates all sorts of problems and obscurity which > > > > > >> have taken months to unpick. See the above patch for the rationale. > > > > > >> > > > > > >> To add to that rationale, OF_BOARD needs to be an option available to > > > > > >> any board. At some point in the future it may become a common way > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree > > > > > >> to it. It doesn't make any sense to have people decide whether or not > > > > > >> to set OF_BOARD at build time, thus affecting how the image is put > > > > > >> together. We'll end up with different U-Boot build targets like > > > > > >> capricorn, capricorn_of_board and the like. It should be obvious where > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used > > > > > >> option, perhaps enabled by most/all boards, so that this sort of build > > > > > >> explosion is not needed. > > > > > > > > > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. > > > > > >> > > > > > >> U-Boot needs to be flexible enough to > > > > > >> function correctly in whatever runtime environment in which it finds > > > > > >> itself. > > > > > >> > > > > > >> Also as binman is pressed into service more and more to build the > > > > > >> complex firmware images that are becoming fashionable, it needs a > > > > > >> definition (in the devicetree) that describes how to create the image. > > > > > >> We can't support that unless we are building a devicetree, nor can the > > > > > >> running program access the image layout without that information. > > > > > >> > > > > > >> François's point about 'don't use this with any kernel' is > > > > > >> germane...but of course I am not suggesting doing that, since OF_BOARD > > > > > >> is, still, enabled. We already use OF_BOARD for various boards that > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > > > > > >> (as I said in the cover letter "Most boards do provide one, but some > > > > > >> don't."). So this series is just completing the picture by enforcing > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > > > I think the key point that will get you closer to where I am on this > > > > > issue, is that OF_BOARD needs to be a run-time option. At present it > > > > > has build-time effects and this is quite wrong. If you go through all > > > > > the material I have written on this I think I have motivated that very > > > > > clearly. > > > > > > > > > > Another big issue is that I believe we need ONE devicetree for U-Boot, > > > > > not two that get merged by U-Boot. Again I have gone through that in a > > > > > lot of detail. > > > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > > here's the biggest sticking point. To be clear, you agree that U-Boot > > > > needs to support being passed a device tree to use, at run time, yes? > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > > > Not at runtime. > > > > OK. > > > > > > So is the sticking point here that we really have two classes of > > > > devices, one class where we will never ever be given the device tree at > > > > run time (think BeagleBone Black) and one where we will always be given > > > > one at run time (think Raspberry Pi) ? > > > > > > I'm not sure it will be that black and white. I suspect there will be > > > (many) boards which can boot happily with the U-Boot devicetree but > > > can also accept one at runtime, if provided. For example, you may want > > > to boot with or without TF-A or some other, earlier stage. > > > > I'm not sure I see the value in making this a gray area. There's very > > much a class of "never" boards. There's also the class of "can" today. > > Maybe as part of a developer iterative flow it would be nice to not have > > to re-flash the prior stage to change a DT, and just do it in U-Boot > > until things are happy, but I'm not sure what the use case is for > > overriding the previous stage. > > > > Especially since the pushback on this series I think has all been "why > > are we copying in a tree to build with? We don't want to use it at run > > time!". And then softer push back like "Well, U-Boot says we have to > > include the device tree file here, but we won't use it...". > > See below. > > > > > > I believe we have got unstuck because OF_BOARD (perhaps inadvertently) > > > provided a way to entirely omit a devicetree from U-Boot, thus making > > > things like binman and U-Boot /config impossible, for example. So I > > > want to claw that back, so there is always some sort of devicetree in > > > U-Boot, as we have for rpi_3, etc. > > > > I really want to see what the binary case looks like since we could then > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > then also do a rpi_arm32_defconfig too. > > > > I want to see less device trees in U-Boot sources, if they can come > > functionally correct from the hardware/our caller. > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > use the device tree from build time at run time, ignoring the device > > tree provided to us at run time by the caller. > > Firstly I should say that I find building firmware very messy and > confusing these days. Lots of things to build and it's hard to find > the instructions. It doesn't have to be that way, but if we carry on > as we are, it will continue to be messy and in five years you will > need a Ph.D and a lucky charm to boot on any modern board. My > objective here is to simplify things, bringing some consistency to the > different components. Binman was one effort there. I feel that putting > at least the U-Boot house in order, in my role as devicetree > maintainer (and as author of devicetree support in U-Boot back in > 2011), is the next step. Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts that know where to grab other known-good binaries of varying licenses that are needed to assemble something that boots. > If we set things up correctly and agree on the bindings, devicetree > can be the unifying configuration mechanism through the whole of > firmware (except for very early bits) and into the OS, this will set > us up very well to deal with the complexity that is coming. > > Anyway, here are the mental steps that I've gone through over the past > two months: > > Step 1: At present, some people think U-Boot is not even allowed to > have its own nodes/properties in the DT. It is an abuse of the > devicetree standard, like the /chosen node but with less history. We > should sacrifice efficiency, expedience and expandability on the altar > of 'devicetree is a hardware description'. How do we get over that > one? Wel, I just think we need to accept that U-Boot uses devicetree > for its own purposes, as well as for booting the OS. I am not saying Yes, we need to have properties present in the device tree, and just like how "linux," is a valid vendor prefix for the linux kernel (but not used I would expect by the BSD families) we have cases that need "u-boot," properties. > it always has to have those properties, but with existing features > like verified boot, SPL as well as complex firmware images where > U-Boot needs to be able to find things in the image, it is essential. > So let's just assume that we need this everywhere, since we certainly > need it in at least some places. No, we can't / shouldn't assume we need this everywhere. A lot of places? Yes. But some features are going to be optional. A valid must be supported use case is something like a Pi where the hardware gives us a device tree, the tree is correct and some features in U-Boot aren't needed (SPL) nor possibly supported immediately (verified boot). We can go off on a tangent about how useful it would be to have HW platforms that are both common and can demonstrate a number of features, but that's its own problem to solve. > (stop reading here if you disagree, because nothing below will make > any sense...you can still use U-Boot v2011.06 which doesn't have > OF_CONTROL :-) > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > there? Well, we have u-boot.dtsi files for that (the 2016 patch > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > have binman definitions, etc. So we need a way to overlay those things > into the DT. We already support this for in-tree DTs, so IMO this is > easy. Just require every board to have an in-tree DT. It helps with > discoverability and documentation, anyway. That is this series. > > (I think most of us are at the beginning of step 2, unsure about it > and worried about step 3) > > Step 3: Ah, but there are flows (i.e. boards that use a particular > flow only, or boards that sometimes use a flow) which need the DT to > come from a prior stage. How to handle that? IMO that is only going to > grow as every man and his dog get into the write-a-bootloader > business. We need a way to provide the U-Boot nodes/properties in a > form that the prior stage can consume and integrate with its build > system. Is TF-A the only thing being discussed here? If so, let's just > do it. We have the u-boot.dtsi and we can use binman to put the image > together, for example. Or we can get clever and create some sort of > overlay dtb. > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > then it will need to build it in and use two devicetrees, one internal > and one from the prior stage....well that is not very efficient and it > is going to be confusing for people to figure out what U-Boot is > actually doing. But we actually already do that in a lot of cases > where U-Boot passes a DT to the kernel which is different to the one > it uses. So perhaps we have three devicetrees? OMG. b) Well then > U-Boot can have its own small devicetree with its bits and then U-Boot > can merge the two when it starts. Again that is not very efficient. It > means that U-Boot cannot be controlled by the prior stage (e.g. to get > its public key from there or to enable/disable the console), so > unified firmware config is not possible. It will get very confusing, > particularly for debugging U-Boot. c) Some other scheme to avoid > accepting step 3...please stop! How the nodes should get there is how the rest of the nodes in a system get there. Bindings are submitted and reviewed. The authoritative source of the dtses in question then has them, like any other property. > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > whole cloth. What about that? Well, we are just going to have to deal > with that. We can easily merge in the U-Boot nodes/properties and > update the U-Boot CI scripts to do this, as needed, e.g. with > qemu-riscv64_spl. It's only one use case, although Xen might do > something similar. > > To my mind, that deals with both the build-time and run-time issues. > We have a discoverable DT in U-Boot, which should be considered the > source of truth for most boards. We can sync it with Linux > automatically with the tooling that I hope Rob Herring will come up > with. We can use an empty one where there really is no default, > although I'd argue that is making perfect an enemy of the good. > > Step 5: If we get clever and want to remove them from the U-Boot tree > and pick them up from somewhere else, we can do that with sufficient > tooling. Perhaps we should set a timeline for that? A year? Two? Six? These last two paragraphs condense what I think is honestly close to a decade of debate / discussion down to a fiat "U-Boot will have the DTS files". I don't want that. I don't think any of the other projects that want to leverage DTS files want that. > To repeat, if we set things up correctly and agree on the bindings, > devicetree can be the unifying configuration mechanism through the > whole of firmware (except for very early bits) and into the OS. I feel > this will set us up very well to deal with the complexity that is > coming. Sure, it could. But that doesn't mean that U-Boot is where the dts files live. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 12:48 ` Tom Rini @ 2021-10-27 13:15 ` François Ozog 2021-10-27 13:23 ` Heinrich Schuchardt ` (2 more replies) 0 siblings, 3 replies; 73+ messages in thread From: François Ozog @ 2021-10-27 13:15 UTC (permalink / raw) To: Tom Rini Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 20593 bytes --] Hi, On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > Hi all, > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > Hi François, > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> > a écrit : > > > > > > >> > > > > > > >> Hi Tom, Bin,François, > > > > > > >> > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> > wrote: > > > > > > >> > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > > >> > > Hi Simon, > > > > > > >> > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > > > >> > > > > > > > > > >> > > > 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 at [1]. > > > > > > >> > > > > > > > > > >> > > > 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. > > > > > > >> > > > > > > > > >> > > Adding device trees that are never used sounds like a > hack to me. > > > > > > >> > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > based on > > > > > > >> > > command line parameters, and the device tree you put in > this series > > > > > > >> > > has various hardcoded <phandle> values which normally do > not show up > > > > > > >> > > in hand-written dts files. > > > > > > >> > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > >> > > > > > > > >> > I am also confused and do not like the idea of adding > device trees for > > > > > > >> > platforms that are capable of and can / do have a device > tree to give us > > > > > > >> > at run time. > > > > > > >> > > > > > > >> (I'll just reply to this one email, since the same points > applies to > > > > > > >> all replies I think) > > > > > > >> > > > > > > >> I have been thinking about this and discussing it with people > for a > > > > > > >> few months now. I've been signalling a change like this for > over a > > > > > > >> month now, on U-Boot contributor calls and in discussions > with Linaro > > > > > > >> people. I sent a patch (below) to try to explain things. I > hope it is > > > > > > >> not a surprise! > > > > > > >> > > > > > > >> The issue here is that we need a devicetree in-tree in > U-Boot, to > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, > OF_BOARD, > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. > Between > > > > > > >> Ilias' series and this one we can get ourselves on a stronger > footing. > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF > use. > > > > > > >> For more context: > > > > > > >> > > > > > > >> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > >> > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of > adding the > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > > > >> maintainer would prefer there was no special support even for > booting > > > > > > >> Linux directly!) > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > >> > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > >> think the path forward might be to run QEMU twice, once to > get its > > > > > > >> generated tree and once to give the 'merged' tree with the > U-Boot > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > >> > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > option, not a > > > > > > >> build-time one. It creates all sorts of problems and > obscurity which > > > > > > >> have taken months to unpick. See the above patch for the > rationale. > > > > > > >> > > > > > > >> To add to that rationale, OF_BOARD needs to be an option > available to > > > > > > >> any board. At some point in the future it may become a common > way > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > devicetree > > > > > > >> to it. It doesn't make any sense to have people decide > whether or not > > > > > > >> to set OF_BOARD at build time, thus affecting how the image > is put > > > > > > >> together. We'll end up with different U-Boot build targets > like > > > > > > >> capricorn, capricorn_of_board and the like. It should be > obvious where > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly > used > > > > > > >> option, perhaps enabled by most/all boards, so that this sort > of build > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > If you mean that when boards are by construction providing a > DTB to U-Boot then I agree very much. But I don’t understand how the patch > set supports it as it puts dts files for those boards to be built. > > > > > > >> > > > > > > >> U-Boot needs to be flexible enough to > > > > > > >> function correctly in whatever runtime environment in which > it finds > > > > > > >> itself. > > > > > > >> > > > > > > >> Also as binman is pressed into service more and more to build > the > > > > > > >> complex firmware images that are becoming fashionable, it > needs a > > > > > > >> definition (in the devicetree) that describes how to create > the image. > > > > > > >> We can't support that unless we are building a devicetree, > nor can the > > > > > > >> running program access the image layout without that > information. > > > > > > >> > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > >> germane...but of course I am not suggesting doing that, since > OF_BOARD > > > > > > >> is, still, enabled. We already use OF_BOARD for various > boards that > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for > example > > > > > > >> (as I said in the cover letter "Most boards do provide one, > but some > > > > > > >> don't."). So this series is just completing the picture by > enforcing > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > > > > > I think the key point that will get you closer to where I am on > this > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > present it > > > > > > has build-time effects and this is quite wrong. If you go > through all > > > > > > the material I have written on this I think I have motivated > that very > > > > > > clearly. > > > > > > > > > > > > Another big issue is that I believe we need ONE devicetree for > U-Boot, > > > > > > not two that get merged by U-Boot. Again I have gone through > that in a > > > > > > lot of detail. > > > > > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > > > here's the biggest sticking point. To be clear, you agree that > U-Boot > > > > > needs to support being passed a device tree to use, at run time, > yes? > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > > > > > Not at runtime. > > > > > > OK. > > > > > > > > So is the sticking point here that we really have two classes of > > > > > devices, one class where we will never ever be given the device > tree at > > > > > run time (think BeagleBone Black) and one where we will always be > given > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > I'm not sure it will be that black and white. I suspect there will be > > > > (many) boards which can boot happily with the U-Boot devicetree but > > > > can also accept one at runtime, if provided. For example, you may > want > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > I'm not sure I see the value in making this a gray area. There's very > > > much a class of "never" boards. There's also the class of "can" today. > > > Maybe as part of a developer iterative flow it would be nice to not > have > > > to re-flash the prior stage to change a DT, and just do it in U-Boot > > > until things are happy, but I'm not sure what the use case is for > > > overriding the previous stage. > > > > > > Especially since the pushback on this series I think has all been "why > > > are we copying in a tree to build with? We don't want to use it at run > > > time!". And then softer push back like "Well, U-Boot says we have to > > > include the device tree file here, but we won't use it...". > > > > See below. > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > inadvertently) > > > > provided a way to entirely omit a devicetree from U-Boot, thus making > > > > things like binman and U-Boot /config impossible, for example. So I > > > > want to claw that back, so there is always some sort of devicetree in > > > > U-Boot, as we have for rpi_3, etc. > > > > > > I really want to see what the binary case looks like since we could > then > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > then also do a rpi_arm32_defconfig too. > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > functionally correct from the hardware/our caller. > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > use the device tree from build time at run time, ignoring the device > > > tree provided to us at run time by the caller. > > > > Firstly I should say that I find building firmware very messy and > > confusing these days. Lots of things to build and it's hard to find > > the instructions. It doesn't have to be that way, but if we carry on > > as we are, it will continue to be messy and in five years you will > > need a Ph.D and a lucky charm to boot on any modern board. My > > objective here is to simplify things, bringing some consistency to the > > different components. Binman was one effort there. I feel that putting > > at least the U-Boot house in order, in my role as devicetree > > maintainer (and as author of devicetree support in U-Boot back in > > 2011), is the next step. > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > that know where to grab other known-good binaries of varying licenses > that are needed to assemble something that boots. > > > If we set things up correctly and agree on the bindings, devicetree > > can be the unifying configuration mechanism through the whole of > > firmware (except for very early bits) and into the OS, this will set > > us up very well to deal with the complexity that is coming. > > > > Anyway, here are the mental steps that I've gone through over the past > > two months: > > > > Step 1: At present, some people think U-Boot is not even allowed to > > have its own nodes/properties in the DT. In my view U-Boot shall be able to leverage device tree format (source and binary) to store its own data. When you say "the" DT, I always think this is "the" DT that is passed to OS and in "that" DT, there should be no U-Boot entries. As stated in another mail thread, I also refer to a place in a FIP where that dynamic config DT is meant to be stored: NT_FW_CONFIG. But there can be U-Boot defined bindings in "a" control/dynamic config DT; Trusted Firmware does that. > It is an abuse of the > > devicetree standard, like the /chosen node but with less history. We > > should sacrifice efficiency, expedience and expandability on the altar > > of 'devicetree is a hardware description'. How do we get over that > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > for its own purposes, as well as for booting the OS. I am not saying > > Yes, we need to have properties present in the device tree, and just > like how "linux," is a valid vendor prefix for the linux kernel (but not > used I would expect by the BSD families) we have cases that need > "u-boot," properties. > > > it always has to have those properties, but with existing features > > like verified boot, SPL as well as complex firmware images where > > U-Boot needs to be able to find things in the image, it is essential. > > So let's just assume that we need this everywhere, since we certainly > > need it in at least some places. > > No, we can't / shouldn't assume we need this everywhere. A lot of > places? Yes. But some features are going to be optional. A valid must > be supported use case is something like a Pi where the hardware gives us > a device tree, the tree is correct and some features in U-Boot aren't > needed (SPL) nor possibly supported immediately (verified boot). We can > go off on a tangent about how useful it would be to have HW platforms > that are both common and can demonstrate a number of features, but > that's its own problem to solve. > > > (stop reading here if you disagree, because nothing below will make > > any sense...you can still use U-Boot v2011.06 which doesn't have > > OF_CONTROL :-) > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > have binman definitions, etc. So we need a way to overlay those things > > into the DT. We already support this for in-tree DTs, so IMO this is > > easy. Just require every board to have an in-tree DT. It helps with > > discoverability and documentation, anyway. That is this series. > > > > (I think most of us are at the beginning of step 2, unsure about it > > and worried about step 3) > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > flow only, or boards that sometimes use a flow) which need the DT to > > come from a prior stage. How to handle that? IMO that is only going to > > grow as every man and his dog get into the write-a-bootloader > > business. We need a way to provide the U-Boot nodes/properties in a > > form that the prior stage can consume and integrate with its build > > system. Is TF-A the only thing being discussed here? If so, let's just > > do it. We have the u-boot.dtsi and we can use binman to put the image > > together, for example. Or we can get clever and create some sort of > > overlay dtb. > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > then it will need to build it in and use two devicetrees, one internal > > and one from the prior stage....well that is not very efficient and it > > is going to be confusing for people to figure out what U-Boot is > > actually doing. But we actually already do that in a lot of cases > > where U-Boot passes a DT to the kernel which is different to the one > > it uses. So perhaps we have three devicetrees? OMG. b) Well then > > U-Boot can have its own small devicetree with its bits and then U-Boot > > can merge the two when it starts. Again that is not very efficient. Does not need to merge the two. hence it does not have any influence on efficiency. For properties access, trusted firmware has defined an abstract way to get them: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html . The properties are currently implemented as DT but TF.ORG could decide to move to CBOR. The API will remain so that a change in backend will not influence existing code. I think you are too focused on "THE" device tree. "THE" device tree that is passed to the OS shall be hardware description and not a hacky place to fit any piece of metadata. I would argue that /chosen shall not even be there as most if not all information can be passed as OS command line. And actually for the UEFI contract, /chosen should go empty. > It > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > its public key from there or to enable/disable the console), so > > unified firmware config is not possible. It will get very confusing, > > particularly for debugging U-Boot. c) Some other scheme to avoid > > accepting step 3...please stop! > > How the nodes should get there is how the rest of the nodes in a system > get there. Bindings are submitted and reviewed. The authoritative > source of the dtses in question then has them, like any other property. > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > whole cloth. What about that? Well, we are just going to have to deal > > with that. We can easily merge in the U-Boot nodes/properties and > > update the U-Boot CI scripts to do this, as needed, e.g. with > > qemu-riscv64_spl. It's only one use case, although Xen might do > > something similar. > > > > To my mind, that deals with both the build-time and run-time issues. > > We have a discoverable DT in U-Boot, which should be considered the > > source of truth for most boards. We can sync it with Linux > > automatically with the tooling that I hope Rob Herring will come up > > with. We can use an empty one where there really is no default, > > although I'd argue that is making perfect an enemy of the good. > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > and pick them up from somewhere else, we can do that with sufficient > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > For SystemReady compliant boards, this has to come much faster. Do you think distros will keep providing DTs for ever? I bet not. > These last two paragraphs condense what I think is honestly close to a > decade of debate / discussion down to a fiat "U-Boot will have the DTS > files". I don't want that. I don't think any of the other projects > that want to leverage DTS files want that. > > > To repeat, if we set things up correctly and agree on the bindings, > > devicetree can be the unifying configuration mechanism through the > > whole of firmware (except for very early bits) and into the OS. I feel > > this will set us up very well to deal with the complexity that is > > coming. > > Sure, it could. But that doesn't mean that U-Boot is where the dts > files live. > > -- > Tom > -- 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: 28207 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 13:15 ` François Ozog @ 2021-10-27 13:23 ` Heinrich Schuchardt 2021-10-27 14:55 ` Tom Rini 2021-10-27 14:54 ` Tom Rini 2021-10-27 15:10 ` Mark Kettenis 2 siblings, 1 reply; 73+ messages in thread From: Heinrich Schuchardt @ 2021-10-27 13:23 UTC (permalink / raw) To: François Ozog, Tom Rini Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari On 10/27/21 15:15, François Ozog wrote: > Hi, > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com > <mailto:trini@konsulko.com>> wrote: > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > Hi all, > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com > <mailto:trini@konsulko.com>> wrote: > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com > <mailto:trini@konsulko.com>> wrote: > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > Hi François, > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog > <francois.ozog@linaro.org <mailto:francois.ozog@linaro.org>> wrote: > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass > <sjg@chromium.org <mailto:sjg@chromium.org>> a écrit : > > > > > > >> > > > > > > >> Hi Tom, Bin,François, > > > > > > >> > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini > <trini@konsulko.com <mailto:trini@konsulko.com>> wrote: > > > > > > >> > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > wrote: > > > > > > >> > > Hi Simon, > > > > > > >> > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass > <sjg@chromium.org <mailto: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 > > > > > > >> > > > > > > > > > >> > > > 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 > at [1]. > > > > > > >> > > > > > > > > > >> > > > 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. > > > > > > >> > > > > > > > > >> > > Adding device trees that are never used sounds > like a hack to me. > > > > > > >> > > > > > > > > >> > > For QEMU, device tree is dynamically generated on > the fly based on > > > > > > >> > > command line parameters, and the device tree you > put in this series > > > > > > >> > > has various hardcoded <phandle> values which > normally do not show up > > > > > > >> > > in hand-written dts files. > > > > > > >> > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > >> > > > > > > > >> > I am also confused and do not like the idea of > adding device trees for > > > > > > >> > platforms that are capable of and can / do have a > device tree to give us > > > > > > >> > at run time. > > > > > > >> > > > > > > >> (I'll just reply to this one email, since the same > points applies to > > > > > > >> all replies I think) > > > > > > >> > > > > > > >> I have been thinking about this and discussing it with > people for a > > > > > > >> few months now. I've been signalling a change like > this for over a > > > > > > >> month now, on U-Boot contributor calls and in > discussions with Linaro > > > > > > >> people. I sent a patch (below) to try to explain > things. I hope it is > > > > > > >> not a surprise! > > > > > > >> > > > > > > >> The issue here is that we need a devicetree in-tree in > U-Boot, to > > > > > > >> avoid the mess that has been created by > OF_PRIOR_STAGE, OF_BOARD, > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, > OF_HOSTFILE. Between > > > > > > >> Ilias' series and this one we can get ourselves on a > stronger footing. > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for > debugging/ELF use. > > > > > > >> For more context: > > > > > > >> > > > > > > >> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > <http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/> > > > > > > >> > > > > > > >> BTW I did suggest to QEMU ARM that they support a way > of adding the > > > > > > >> u-boot.dtsi but there was not much interest there (in > fact the > > > > > > >> maintainer would prefer there was no special support > even for booting > > > > > > >> Linux directly!) > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > >> > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > >> think the path forward might be to run QEMU twice, > once to get its > > > > > > >> generated tree and once to give the 'merged' tree with > the U-Boot > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > >> > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > option, not a > > > > > > >> build-time one. It creates all sorts of problems and > obscurity which > > > > > > >> have taken months to unpick. See the above patch for > the rationale. > > > > > > >> > > > > > > >> To add to that rationale, OF_BOARD needs to be an > option available to > > > > > > >> any board. At some point in the future it may become a > common way > > > > > > >> things are done, e.g. TF-A calling U-Boot and > providing a devicetree > > > > > > >> to it. It doesn't make any sense to have people decide > whether or not > > > > > > >> to set OF_BOARD at build time, thus affecting how the > image is put > > > > > > >> together. We'll end up with different U-Boot build > targets like > > > > > > >> capricorn, capricorn_of_board and the like. It should > be obvious where > > > > > > >> that will lead. Instead, OF_BOARD needs to become a > commonly used > > > > > > >> option, perhaps enabled by most/all boards, so that > this sort of build > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > If you mean that when boards are by construction > providing a DTB to U-Boot then I agree very much. But I don’t > understand how the patch set supports it as it puts dts files for > those boards to be built. > > > > > > >> > > > > > > >> U-Boot needs to be flexible enough to > > > > > > >> function correctly in whatever runtime environment in > which it finds > > > > > > >> itself. > > > > > > >> > > > > > > >> Also as binman is pressed into service more and more > to build the > > > > > > >> complex firmware images that are becoming fashionable, > it needs a > > > > > > >> definition (in the devicetree) that describes how to > create the image. > > > > > > >> We can't support that unless we are building a > devicetree, nor can the > > > > > > >> running program access the image layout without that > information. > > > > > > >> > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > >> germane...but of course I am not suggesting doing > that, since OF_BOARD > > > > > > >> is, still, enabled. We already use OF_BOARD for > various boards that > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and > 3, for example > > > > > > >> (as I said in the cover letter "Most boards do provide > one, but some > > > > > > >> don't."). So this series is just completing the > picture by enforcing > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the > default. > > > > > > > > > > > > I think the key point that will get you closer to where I > am on this > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > present it > > > > > > has build-time effects and this is quite wrong. If you go > through all > > > > > > the material I have written on this I think I have > motivated that very > > > > > > clearly. > > > > > > > > > > > > Another big issue is that I believe we need ONE > devicetree for U-Boot, > > > > > > not two that get merged by U-Boot. Again I have gone > through that in a > > > > > > lot of detail. > > > > > > > > > > I have a long long reply to your first reply here saved, > but, maybe > > > > > here's the biggest sticking point. To be clear, you agree > that U-Boot > > > > > needs to support being passed a device tree to use, at run > time, yes? > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we > built in? > > > > > > > > Not at runtime. > > > > > > OK. > > > > > > > > So is the sticking point here that we really have two > classes of > > > > > devices, one class where we will never ever be given the > device tree at > > > > > run time (think BeagleBone Black) and one where we will > always be given > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > I'm not sure it will be that black and white. I suspect there > will be > > > > (many) boards which can boot happily with the U-Boot > devicetree but > > > > can also accept one at runtime, if provided. For example, you > may want > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > I'm not sure I see the value in making this a gray area. > There's very > > > much a class of "never" boards. There's also the class of > "can" today. > > > Maybe as part of a developer iterative flow it would be nice to > not have > > > to re-flash the prior stage to change a DT, and just do it in > U-Boot > > > until things are happy, but I'm not sure what the use case is for > > > overriding the previous stage. > > > > > > Especially since the pushback on this series I think has all > been "why > > > are we copying in a tree to build with? We don't want to use > it at run > > > time!". And then softer push back like "Well, U-Boot says we > have to > > > include the device tree file here, but we won't use it...". > > > > See below. > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > inadvertently) > > > > provided a way to entirely omit a devicetree from U-Boot, > thus making > > > > things like binman and U-Boot /config impossible, for > example. So I > > > > want to claw that back, so there is always some sort of > devicetree in > > > > U-Boot, as we have for rpi_3, etc. > > > > > > I really want to see what the binary case looks like since we > could then > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > could > > > then also do a rpi_arm32_defconfig too. > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > functionally correct from the hardware/our caller. > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we > also don't > > > use the device tree from build time at run time, ignoring the > device > > > tree provided to us at run time by the caller. > > > > Firstly I should say that I find building firmware very messy and > > confusing these days. Lots of things to build and it's hard to find > > the instructions. It doesn't have to be that way, but if we carry on > > as we are, it will continue to be messy and in five years you will > > need a Ph.D and a lucky charm to boot on any modern board. My > > objective here is to simplify things, bringing some consistency > to the > > different components. Binman was one effort there. I feel that > putting > > at least the U-Boot house in order, in my role as devicetree > > maintainer (and as author of devicetree support in U-Boot back in > > 2011), is the next step. > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > that know where to grab other known-good binaries of varying licenses > that are needed to assemble something that boots. > > > If we set things up correctly and agree on the bindings, devicetree > > can be the unifying configuration mechanism through the whole of > > firmware (except for very early bits) and into the OS, this will set > > us up very well to deal with the complexity that is coming. > > > > Anyway, here are the mental steps that I've gone through over the > past > > two months: > > > > Step 1: At present, some people think U-Boot is not even allowed to > > have its own nodes/properties in the DT. > > In my view U-Boot shall be able to leverage device tree format (source > and binary) to store its own data. > When you say "the" DT, I always think this is "the" DT that is passed to > OS and in "that" DT, there should be no U-Boot entries. As stated in > another mail thread, I also refer to a place in a FIP where that dynamic > config DT is meant to be stored: NT_FW_CONFIG. > But there can be U-Boot defined bindings in "a" control/dynamic config > DT; Trusted Firmware does that. It ends up in that we need two separate devicetrees. One passed to U-Boot for fixups and further passed to the OS. This devicetree may originate from a prior boot stage, from a file loaded by U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command. This devicetree will not contain any U-Boot specific information. A second devicetree to hold everything that U-Boot needs for its internal purposes. Best regards Heinrich > > It is an abuse of the > > devicetree standard, like the /chosen node but with less history. We > > should sacrifice efficiency, expedience and expandability on the > altar > > of 'devicetree is a hardware description'. How do we get over that > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > for its own purposes, as well as for booting the OS. I am not saying > > Yes, we need to have properties present in the device tree, and just > like how "linux," is a valid vendor prefix for the linux kernel (but not > used I would expect by the BSD families) we have cases that need > "u-boot," properties. > > > it always has to have those properties, but with existing features > > like verified boot, SPL as well as complex firmware images where > > U-Boot needs to be able to find things in the image, it is essential. > > So let's just assume that we need this everywhere, since we certainly > > need it in at least some places. > > No, we can't / shouldn't assume we need this everywhere. A lot of > places? Yes. But some features are going to be optional. A valid must > be supported use case is something like a Pi where the hardware gives us > a device tree, the tree is correct and some features in U-Boot aren't > needed (SPL) nor possibly supported immediately (verified boot). We can > go off on a tangent about how useful it would be to have HW platforms > that are both common and can demonstrate a number of features, but > that's its own problem to solve. > > > (stop reading here if you disagree, because nothing below will make > > any sense...you can still use U-Boot v2011.06 which doesn't have > > OF_CONTROL :-) > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > have binman definitions, etc. So we need a way to overlay those > things > > into the DT. We already support this for in-tree DTs, so IMO this is > > easy. Just require every board to have an in-tree DT. It helps with > > discoverability and documentation, anyway. That is this series. > > > > (I think most of us are at the beginning of step 2, unsure about it > > and worried about step 3) > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > flow only, or boards that sometimes use a flow) which need the DT to > > come from a prior stage. How to handle that? IMO that is only > going to > > grow as every man and his dog get into the write-a-bootloader > > business. We need a way to provide the U-Boot nodes/properties in a > > form that the prior stage can consume and integrate with its build > > system. Is TF-A the only thing being discussed here? If so, let's > just > > do it. We have the u-boot.dtsi and we can use binman to put the image > > together, for example. Or we can get clever and create some sort of > > overlay dtb. > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > then it will need to build it in and use two devicetrees, one > internal > > and one from the prior stage....well that is not very efficient > and it > > is going to be confusing for people to figure out what U-Boot is > > actually doing. But we actually already do that in a lot of cases > > where U-Boot passes a DT to the kernel which is different to the one > > it uses. So perhaps we have three devicetrees? OMG. b) Well then > > U-Boot can have its own small devicetree with its bits and then > U-Boot > > can merge the two when it starts. Again that is not very efficient. > > Does not need to merge the two. hence it does not have any influence on > efficiency. > For properties access, trusted firmware has defined an abstract way to > get them: > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html > <https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html>. > > The properties are currently implemented as DT but TF.ORG > <http://TF.ORG> could decide to move to CBOR. > The API will remain so that a change in backend will not influence > existing code. > I think you are too focused on "THE" device tree. "THE" device tree that > is passed to the OS > shall be hardware description and not a hacky place to fit any piece of > metadata. > I would argue that /chosen shall not even be there as most if not all > information can be passed as OS command line. And actually for the UEFI > contract, /chosen should go empty. > > It > > means that U-Boot cannot be controlled by the prior stage (e.g. > to get > > its public key from there or to enable/disable the console), so > > unified firmware config is not possible. It will get very confusing, > > particularly for debugging U-Boot. c) Some other scheme to avoid > > accepting step 3...please stop! > > How the nodes should get there is how the rest of the nodes in a system > get there. Bindings are submitted and reviewed. The authoritative > source of the dtses in question then has them, like any other property. > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > whole cloth. What about that? Well, we are just going to have to deal > > with that. We can easily merge in the U-Boot nodes/properties and > > update the U-Boot CI scripts to do this, as needed, e.g. with > > qemu-riscv64_spl. It's only one use case, although Xen might do > > something similar. > > > > To my mind, that deals with both the build-time and run-time issues. > > We have a discoverable DT in U-Boot, which should be considered the > > source of truth for most boards. We can sync it with Linux > > automatically with the tooling that I hope Rob Herring will come up > > with. We can use an empty one where there really is no default, > > although I'd argue that is making perfect an enemy of the good. > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > and pick them up from somewhere else, we can do that with sufficient > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > For SystemReady compliant boards, this has to come much faster. > Do you think distros will keep providing DTs for ever? I bet not. > > These last two paragraphs condense what I think is honestly close to a > decade of debate / discussion down to a fiat "U-Boot will have the DTS > files". I don't want that. I don't think any of the other projects > that want to leverage DTS files want that. > > > To repeat, if we set things up correctly and agree on the bindings, > > devicetree can be the unifying configuration mechanism through the > > whole of firmware (except for very early bits) and into the OS. I > feel > > this will set us up very well to deal with the complexity that is > > coming. > > Sure, it could. But that doesn't mean that U-Boot is where the dts > files live. > > -- > Tom > > > > -- > > François-Frédéric Ozog | /Director Business Development/ > T: +33.67221.6485 > francois.ozog@linaro.org <mailto:francois.ozog@linaro.org> | Skype: ffozog > > ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 13:23 ` Heinrich Schuchardt @ 2021-10-27 14:55 ` Tom Rini 2021-10-27 15:02 ` Heinrich Schuchardt 0 siblings, 1 reply; 73+ messages in thread From: Tom Rini @ 2021-10-27 14:55 UTC (permalink / raw) To: Heinrich Schuchardt Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 588 bytes --] On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote: [snip] > One passed to U-Boot for fixups and further passed to the OS. This > devicetree may originate from a prior boot stage, from a file loaded by > U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command. I assume systemd-boot is implementing the same logic that extlinux.conf has used for forever, yes? > This devicetree will not contain any U-Boot specific information. To repeat, it must only have official bindings, yes, regardless of what project they come from. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 14:55 ` Tom Rini @ 2021-10-27 15:02 ` Heinrich Schuchardt 2021-10-27 18:04 ` Tom Rini 0 siblings, 1 reply; 73+ messages in thread From: Heinrich Schuchardt @ 2021-10-27 15:02 UTC (permalink / raw) To: Tom Rini Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari On 10/27/21 16:55, Tom Rini wrote: > On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote: > > [snip] >> One passed to U-Boot for fixups and further passed to the OS. This >> devicetree may originate from a prior boot stage, from a file loaded by >> U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command. > > I assume systemd-boot is implementing the same logic that extlinux.conf > has used for forever, yes? It is loading the file and then calls U-Boot's implementation of the EFI Device Tree Fixup Protocol for fixups before passing the device-tree to the OS. > >> This devicetree will not contain any U-Boot specific information. > > To repeat, it must only have official bindings, yes, regardless of what > project they come from. > Don't expect prior firmware stages to provide any U-Boot specific stuff whatever official or non-official U-Boot specific bindings exist. Best regards Heinrich ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 15:02 ` Heinrich Schuchardt @ 2021-10-27 18:04 ` Tom Rini 0 siblings, 0 replies; 73+ messages in thread From: Tom Rini @ 2021-10-27 18:04 UTC (permalink / raw) To: Heinrich Schuchardt Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 1238 bytes --] On Wed, Oct 27, 2021 at 05:02:39PM +0200, Heinrich Schuchardt wrote: > On 10/27/21 16:55, Tom Rini wrote: > > On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote: > > > > [snip] > > > One passed to U-Boot for fixups and further passed to the OS. This > > > devicetree may originate from a prior boot stage, from a file loaded by > > > U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command. > > > > I assume systemd-boot is implementing the same logic that extlinux.conf > > has used for forever, yes? > > It is loading the file and then calls U-Boot's implementation of the EFI > Device Tree Fixup Protocol for fixups before passing the device-tree to the > OS. So it's using https://systemd.io/BOOT_LOADER_SPECIFICATION/ OK. > > > This devicetree will not contain any U-Boot specific information. > > > > To repeat, it must only have official bindings, yes, regardless of what > > project they come from. > > > > Don't expect prior firmware stages to provide any U-Boot specific stuff > whatever official or non-official U-Boot specific bindings exist. Failure to implement official bindings may result in failure to boot, which would be pretty silly. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 13:15 ` François Ozog 2021-10-27 13:23 ` Heinrich Schuchardt @ 2021-10-27 14:54 ` Tom Rini 2021-10-27 15:10 ` Mark Kettenis 2 siblings, 0 replies; 73+ messages in thread From: Tom Rini @ 2021-10-27 14:54 UTC (permalink / raw) To: François Ozog Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 22581 bytes --] On Wed, Oct 27, 2021 at 03:15:01PM +0200, François Ozog wrote: > Hi, > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > Hi all, > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > Hi François, > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> > > a écrit : > > > > > > > >> > > > > > > > >> Hi Tom, Bin,François, > > > > > > > >> > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> > > wrote: > > > > > > > >> > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > > > >> > > Hi Simon, > > > > > > > >> > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > > > > >> > > > > > > > > > > >> > > > 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 at [1]. > > > > > > > >> > > > > > > > > > > >> > > > 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. > > > > > > > >> > > > > > > > > > >> > > Adding device trees that are never used sounds like a > > hack to me. > > > > > > > >> > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > > based on > > > > > > > >> > > command line parameters, and the device tree you put in > > this series > > > > > > > >> > > has various hardcoded <phandle> values which normally do > > not show up > > > > > > > >> > > in hand-written dts files. > > > > > > > >> > > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > > >> > > > > > > > > >> > I am also confused and do not like the idea of adding > > device trees for > > > > > > > >> > platforms that are capable of and can / do have a device > > tree to give us > > > > > > > >> > at run time. > > > > > > > >> > > > > > > > >> (I'll just reply to this one email, since the same points > > applies to > > > > > > > >> all replies I think) > > > > > > > >> > > > > > > > >> I have been thinking about this and discussing it with people > > for a > > > > > > > >> few months now. I've been signalling a change like this for > > over a > > > > > > > >> month now, on U-Boot contributor calls and in discussions > > with Linaro > > > > > > > >> people. I sent a patch (below) to try to explain things. I > > hope it is > > > > > > > >> not a surprise! > > > > > > > >> > > > > > > > >> The issue here is that we need a devicetree in-tree in > > U-Boot, to > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, > > OF_BOARD, > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. > > Between > > > > > > > >> Ilias' series and this one we can get ourselves on a stronger > > footing. > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF > > use. > > > > > > > >> For more context: > > > > > > > >> > > > > > > > >> > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > >> > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of > > adding the > > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > > > > >> maintainer would prefer there was no special support even for > > booting > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > >> > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > >> think the path forward might be to run QEMU twice, once to > > get its > > > > > > > >> generated tree and once to give the 'merged' tree with the > > U-Boot > > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > > >> > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > option, not a > > > > > > > >> build-time one. It creates all sorts of problems and > > obscurity which > > > > > > > >> have taken months to unpick. See the above patch for the > > rationale. > > > > > > > >> > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option > > available to > > > > > > > >> any board. At some point in the future it may become a common > > way > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > > devicetree > > > > > > > >> to it. It doesn't make any sense to have people decide > > whether or not > > > > > > > >> to set OF_BOARD at build time, thus affecting how the image > > is put > > > > > > > >> together. We'll end up with different U-Boot build targets > > like > > > > > > > >> capricorn, capricorn_of_board and the like. It should be > > obvious where > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly > > used > > > > > > > >> option, perhaps enabled by most/all boards, so that this sort > > of build > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > If you mean that when boards are by construction providing a > > DTB to U-Boot then I agree very much. But I don’t understand how the patch > > set supports it as it puts dts files for those boards to be built. > > > > > > > >> > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > >> function correctly in whatever runtime environment in which > > it finds > > > > > > > >> itself. > > > > > > > >> > > > > > > > >> Also as binman is pressed into service more and more to build > > the > > > > > > > >> complex firmware images that are becoming fashionable, it > > needs a > > > > > > > >> definition (in the devicetree) that describes how to create > > the image. > > > > > > > >> We can't support that unless we are building a devicetree, > > nor can the > > > > > > > >> running program access the image layout without that > > information. > > > > > > > >> > > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > > >> germane...but of course I am not suggesting doing that, since > > OF_BOARD > > > > > > > >> is, still, enabled. We already use OF_BOARD for various > > boards that > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for > > example > > > > > > > >> (as I said in the cover letter "Most boards do provide one, > > but some > > > > > > > >> don't."). So this series is just completing the picture by > > enforcing > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > > > > > > > I think the key point that will get you closer to where I am on > > this > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > present it > > > > > > > has build-time effects and this is quite wrong. If you go > > through all > > > > > > > the material I have written on this I think I have motivated > > that very > > > > > > > clearly. > > > > > > > > > > > > > > Another big issue is that I believe we need ONE devicetree for > > U-Boot, > > > > > > > not two that get merged by U-Boot. Again I have gone through > > that in a > > > > > > > lot of detail. > > > > > > > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > > > > here's the biggest sticking point. To be clear, you agree that > > U-Boot > > > > > > needs to support being passed a device tree to use, at run time, > > yes? > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > > > > > > > Not at runtime. > > > > > > > > OK. > > > > > > > > > > So is the sticking point here that we really have two classes of > > > > > > devices, one class where we will never ever be given the device > > tree at > > > > > > run time (think BeagleBone Black) and one where we will always be > > given > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > I'm not sure it will be that black and white. I suspect there will be > > > > > (many) boards which can boot happily with the U-Boot devicetree but > > > > > can also accept one at runtime, if provided. For example, you may > > want > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > I'm not sure I see the value in making this a gray area. There's very > > > > much a class of "never" boards. There's also the class of "can" today. > > > > Maybe as part of a developer iterative flow it would be nice to not > > have > > > > to re-flash the prior stage to change a DT, and just do it in U-Boot > > > > until things are happy, but I'm not sure what the use case is for > > > > overriding the previous stage. > > > > > > > > Especially since the pushback on this series I think has all been "why > > > > are we copying in a tree to build with? We don't want to use it at run > > > > time!". And then softer push back like "Well, U-Boot says we have to > > > > include the device tree file here, but we won't use it...". > > > > > > See below. > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > inadvertently) > > > > > provided a way to entirely omit a devicetree from U-Boot, thus making > > > > > things like binman and U-Boot /config impossible, for example. So I > > > > > want to claw that back, so there is always some sort of devicetree in > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > I really want to see what the binary case looks like since we could > > then > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > functionally correct from the hardware/our caller. > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > > use the device tree from build time at run time, ignoring the device > > > > tree provided to us at run time by the caller. > > > > > > Firstly I should say that I find building firmware very messy and > > > confusing these days. Lots of things to build and it's hard to find > > > the instructions. It doesn't have to be that way, but if we carry on > > > as we are, it will continue to be messy and in five years you will > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > objective here is to simplify things, bringing some consistency to the > > > different components. Binman was one effort there. I feel that putting > > > at least the U-Boot house in order, in my role as devicetree > > > maintainer (and as author of devicetree support in U-Boot back in > > > 2011), is the next step. > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > > that know where to grab other known-good binaries of varying licenses > > that are needed to assemble something that boots. > > > > > If we set things up correctly and agree on the bindings, devicetree > > > can be the unifying configuration mechanism through the whole of > > > firmware (except for very early bits) and into the OS, this will set > > > us up very well to deal with the complexity that is coming. > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > two months: > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > have its own nodes/properties in the DT. > > In my view U-Boot shall be able to leverage device tree format (source and > binary) to store its own data. > When you say "the" DT, I always think this is "the" DT that is passed to OS > and in "that" DT, there should be no U-Boot entries. As stated in another I would (and I know I'm repeating myself and emails have crossed, etc, but for future clarity) say it's that no un-official nodes/properties should be passed from one piece of software to another. I mean hell, "u-boot,bootcount" MUST get passed to the OS, so has some idea how many times the system has booted. It's just a long standing item to get that bootcount driver / binding unblocked and merged finally. But that's a different tangent to get lost on. > mail thread, I also refer to a place in a FIP where that dynamic config DT > is meant to be stored: NT_FW_CONFIG. > But there can be U-Boot defined bindings in "a" control/dynamic config DT; > Trusted Firmware does that. Maybe I just need to come out and say if "everyone" has decided how U-Boot needs to work, but also myself (head custodian) and Simon (head DM custodian, device tree in U-Boot custodian) aren't 100% on board with everything, maybe some step back and re-evaluation needs to be taken? And I'm not saying we're the final word only here either, there has been and needs to continue to be good faith discussions. It should also be clear at this point that he and I aren't on the same page on everything, for example :) > > It is an abuse of the > > > devicetree standard, like the /chosen node but with less history. We > > > should sacrifice efficiency, expedience and expandability on the altar > > > of 'devicetree is a hardware description'. How do we get over that > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > for its own purposes, as well as for booting the OS. I am not saying > > > > Yes, we need to have properties present in the device tree, and just > > like how "linux," is a valid vendor prefix for the linux kernel (but not > > used I would expect by the BSD families) we have cases that need > > "u-boot," properties. > > > > > it always has to have those properties, but with existing features > > > like verified boot, SPL as well as complex firmware images where > > > U-Boot needs to be able to find things in the image, it is essential. > > > So let's just assume that we need this everywhere, since we certainly > > > need it in at least some places. > > > > No, we can't / shouldn't assume we need this everywhere. A lot of > > places? Yes. But some features are going to be optional. A valid must > > be supported use case is something like a Pi where the hardware gives us > > a device tree, the tree is correct and some features in U-Boot aren't > > needed (SPL) nor possibly supported immediately (verified boot). We can > > go off on a tangent about how useful it would be to have HW platforms > > that are both common and can demonstrate a number of features, but > > that's its own problem to solve. > > > > > (stop reading here if you disagree, because nothing below will make > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > OF_CONTROL :-) > > > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > have binman definitions, etc. So we need a way to overlay those things > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > easy. Just require every board to have an in-tree DT. It helps with > > > discoverability and documentation, anyway. That is this series. > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > and worried about step 3) > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > flow only, or boards that sometimes use a flow) which need the DT to > > > come from a prior stage. How to handle that? IMO that is only going to > > > grow as every man and his dog get into the write-a-bootloader > > > business. We need a way to provide the U-Boot nodes/properties in a > > > form that the prior stage can consume and integrate with its build > > > system. Is TF-A the only thing being discussed here? If so, let's just > > > do it. We have the u-boot.dtsi and we can use binman to put the image > > > together, for example. Or we can get clever and create some sort of > > > overlay dtb. > > > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > > then it will need to build it in and use two devicetrees, one internal > > > and one from the prior stage....well that is not very efficient and it > > > is going to be confusing for people to figure out what U-Boot is > > > actually doing. But we actually already do that in a lot of cases > > > where U-Boot passes a DT to the kernel which is different to the one > > > it uses. So perhaps we have three devicetrees? OMG. b) Well then > > > U-Boot can have its own small devicetree with its bits and then U-Boot > > > can merge the two when it starts. Again that is not very efficient. > > Does not need to merge the two. hence it does not have any influence on > efficiency. > For properties access, trusted firmware has defined an abstract way to get > them: > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html That's interesting, but I also think fconf_load_config(), etc are the efficiency and additional overhead Simon is talking about being worried about. > The properties are currently implemented as DT but TF.ORG could decide to > move to CBOR. > The API will remain so that a change in backend will not influence existing > code. > I think you are too focused on "THE" device tree. "THE" device tree that is > passed to the OS > shall be hardware description and not a hacky place to fit any piece of > metadata. No, but it is the place to put well defined metadata. > I would argue that /chosen shall not even be there as most if not all > information can be passed as OS command line. And actually for the UEFI > contract, /chosen should go empty. Shoving a bunch of stuff to the kernel command line sounds pretty hacky to me. But I'll just assume it's already been given the official Not Hacky stamp of approval since after all, there's not a long standing cleaner path to do anything like that on x86, and we must all mirror the x86 world. > > It > > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > > its public key from there or to enable/disable the console), so > > > unified firmware config is not possible. It will get very confusing, > > > particularly for debugging U-Boot. c) Some other scheme to avoid > > > accepting step 3...please stop! > > > > How the nodes should get there is how the rest of the nodes in a system > > get there. Bindings are submitted and reviewed. The authoritative > > source of the dtses in question then has them, like any other property. > > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > > whole cloth. What about that? Well, we are just going to have to deal > > > with that. We can easily merge in the U-Boot nodes/properties and > > > update the U-Boot CI scripts to do this, as needed, e.g. with > > > qemu-riscv64_spl. It's only one use case, although Xen might do > > > something similar. > > > > > > To my mind, that deals with both the build-time and run-time issues. > > > We have a discoverable DT in U-Boot, which should be considered the > > > source of truth for most boards. We can sync it with Linux > > > automatically with the tooling that I hope Rob Herring will come up > > > with. We can use an empty one where there really is no default, > > > although I'd argue that is making perfect an enemy of the good. > > > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > > and pick them up from somewhere else, we can do that with sufficient > > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > > > For SystemReady compliant boards, this has to come much faster. > Do you think distros will keep providing DTs for ever? I bet not. Since it seems like it'll be a long time before people stop producing SBCs that lack on-board flash storage for the world firmware, yeah, I don't know when distributions will stop shipping DTBs. Maybe a year or two after the last popular SBC comes out and distros are comfortable shoving people that have that hardware off to some other community to support? -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 13:15 ` François Ozog 2021-10-27 13:23 ` Heinrich Schuchardt 2021-10-27 14:54 ` Tom Rini @ 2021-10-27 15:10 ` Mark Kettenis 2021-10-27 15:24 ` Simon Glass 2021-10-27 16:02 ` François Ozog 2 siblings, 2 replies; 73+ messages in thread From: Mark Kettenis @ 2021-10-27 15:10 UTC (permalink / raw) To: François Ozog Cc: liviu.dudau, narmstrong, vladimir.oltean, linus.walleij, bin.meng, kever.yang, seanga2, atish.patra, zong.li, sr, festevam, rainer.boschung, trini, swarren, oleksandr_andrushchenko, xypron.glpk, lusus, michal.simek, marek.behun, vanbaren, rfried.dev, jagan, valentin.longchamp, hs, pbrobinson, sinan, fitzsim, wd, swarren, qemu-devel, andre.przywara, tharvey, ashok.reddy.soma, rick, agraf, green.wan, t.karthik.reddy, anastasiia_lukianenko, albert.u.boot, monstr, mbrugger, ycliang, kristo, u-boot, david.abdurachmanov, priyanka.jain, sjg, ilias.apalodimas, christianshewitt, awilliams, tuomas.tynkkynen, heinrich.schuchardt, tianrui-wei, bmeng.cn, pali, dimitri.ledkov, padmarao.begari > From: François Ozog <francois.ozog@linaro.org> > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > Hi, > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > Hi all, > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > Hi François, > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> > > a écrit : > > > > > > > >> > > > > > > > >> Hi Tom, Bin,François, > > > > > > > >> > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> > > wrote: > > > > > > > >> > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > > > >> > > Hi Simon, > > > > > > > >> > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > > > > >> > > > > > > > > > > >> > > > 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 at [1]. > > > > > > > >> > > > > > > > > > > >> > > > 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. > > > > > > > >> > > > > > > > > > >> > > Adding device trees that are never used sounds like a > > hack to me. > > > > > > > >> > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > > based on > > > > > > > >> > > command line parameters, and the device tree you put in > > this series > > > > > > > >> > > has various hardcoded <phandle> values which normally do > > not show up > > > > > > > >> > > in hand-written dts files. > > > > > > > >> > > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > > >> > > > > > > > > >> > I am also confused and do not like the idea of adding > > device trees for > > > > > > > >> > platforms that are capable of and can / do have a device > > tree to give us > > > > > > > >> > at run time. > > > > > > > >> > > > > > > > >> (I'll just reply to this one email, since the same points > > applies to > > > > > > > >> all replies I think) > > > > > > > >> > > > > > > > >> I have been thinking about this and discussing it with people > > for a > > > > > > > >> few months now. I've been signalling a change like this for > > over a > > > > > > > >> month now, on U-Boot contributor calls and in discussions > > with Linaro > > > > > > > >> people. I sent a patch (below) to try to explain things. I > > hope it is > > > > > > > >> not a surprise! > > > > > > > >> > > > > > > > >> The issue here is that we need a devicetree in-tree in > > U-Boot, to > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, > > OF_BOARD, > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. > > Between > > > > > > > >> Ilias' series and this one we can get ourselves on a stronger > > footing. > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF > > use. > > > > > > > >> For more context: > > > > > > > >> > > > > > > > >> > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > >> > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of > > adding the > > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > > > > >> maintainer would prefer there was no special support even for > > booting > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > >> > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > >> think the path forward might be to run QEMU twice, once to > > get its > > > > > > > >> generated tree and once to give the 'merged' tree with the > > U-Boot > > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > > >> > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > option, not a > > > > > > > >> build-time one. It creates all sorts of problems and > > obscurity which > > > > > > > >> have taken months to unpick. See the above patch for the > > rationale. > > > > > > > >> > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option > > available to > > > > > > > >> any board. At some point in the future it may become a common > > way > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > > devicetree > > > > > > > >> to it. It doesn't make any sense to have people decide > > whether or not > > > > > > > >> to set OF_BOARD at build time, thus affecting how the image > > is put > > > > > > > >> together. We'll end up with different U-Boot build targets > > like > > > > > > > >> capricorn, capricorn_of_board and the like. It should be > > obvious where > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly > > used > > > > > > > >> option, perhaps enabled by most/all boards, so that this sort > > of build > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > If you mean that when boards are by construction providing a > > DTB to U-Boot then I agree very much. But I don’t understand how the patch > > set supports it as it puts dts files for those boards to be built. > > > > > > > >> > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > >> function correctly in whatever runtime environment in which > > it finds > > > > > > > >> itself. > > > > > > > >> > > > > > > > >> Also as binman is pressed into service more and more to build > > the > > > > > > > >> complex firmware images that are becoming fashionable, it > > needs a > > > > > > > >> definition (in the devicetree) that describes how to create > > the image. > > > > > > > >> We can't support that unless we are building a devicetree, > > nor can the > > > > > > > >> running program access the image layout without that > > information. > > > > > > > >> > > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > > >> germane...but of course I am not suggesting doing that, since > > OF_BOARD > > > > > > > >> is, still, enabled. We already use OF_BOARD for various > > boards that > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for > > example > > > > > > > >> (as I said in the cover letter "Most boards do provide one, > > but some > > > > > > > >> don't."). So this series is just completing the picture by > > enforcing > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > > > > > > > I think the key point that will get you closer to where I am on > > this > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > present it > > > > > > > has build-time effects and this is quite wrong. If you go > > through all > > > > > > > the material I have written on this I think I have motivated > > that very > > > > > > > clearly. > > > > > > > > > > > > > > Another big issue is that I believe we need ONE devicetree for > > U-Boot, > > > > > > > not two that get merged by U-Boot. Again I have gone through > > that in a > > > > > > > lot of detail. > > > > > > > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > > > > here's the biggest sticking point. To be clear, you agree that > > U-Boot > > > > > > needs to support being passed a device tree to use, at run time, > > yes? > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > > > > > > > Not at runtime. > > > > > > > > OK. > > > > > > > > > > So is the sticking point here that we really have two classes of > > > > > > devices, one class where we will never ever be given the device > > tree at > > > > > > run time (think BeagleBone Black) and one where we will always be > > given > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > I'm not sure it will be that black and white. I suspect there will be > > > > > (many) boards which can boot happily with the U-Boot devicetree but > > > > > can also accept one at runtime, if provided. For example, you may > > want > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > I'm not sure I see the value in making this a gray area. There's very > > > > much a class of "never" boards. There's also the class of "can" today. > > > > Maybe as part of a developer iterative flow it would be nice to not > > have > > > > to re-flash the prior stage to change a DT, and just do it in U-Boot > > > > until things are happy, but I'm not sure what the use case is for > > > > overriding the previous stage. > > > > > > > > Especially since the pushback on this series I think has all been "why > > > > are we copying in a tree to build with? We don't want to use it at run > > > > time!". And then softer push back like "Well, U-Boot says we have to > > > > include the device tree file here, but we won't use it...". > > > > > > See below. > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > inadvertently) > > > > > provided a way to entirely omit a devicetree from U-Boot, thus making > > > > > things like binman and U-Boot /config impossible, for example. So I > > > > > want to claw that back, so there is always some sort of devicetree in > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > I really want to see what the binary case looks like since we could > > then > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > functionally correct from the hardware/our caller. > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > > use the device tree from build time at run time, ignoring the device > > > > tree provided to us at run time by the caller. > > > > > > Firstly I should say that I find building firmware very messy and > > > confusing these days. Lots of things to build and it's hard to find > > > the instructions. It doesn't have to be that way, but if we carry on > > > as we are, it will continue to be messy and in five years you will > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > objective here is to simplify things, bringing some consistency to the > > > different components. Binman was one effort there. I feel that putting > > > at least the U-Boot house in order, in my role as devicetree > > > maintainer (and as author of devicetree support in U-Boot back in > > > 2011), is the next step. > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > > that know where to grab other known-good binaries of varying licenses > > that are needed to assemble something that boots. > > > > > If we set things up correctly and agree on the bindings, devicetree > > > can be the unifying configuration mechanism through the whole of > > > firmware (except for very early bits) and into the OS, this will set > > > us up very well to deal with the complexity that is coming. > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > two months: > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > have its own nodes/properties in the DT. > > In my view U-Boot shall be able to leverage device tree format (source and > binary) to store its own data. > When you say "the" DT, I always think this is "the" DT that is passed to OS > and in "that" DT, there should be no U-Boot entries. Why not? As long as the device tree validates, it is perfectly fine to have additional nodes and properties present. The propertiesand nodes will be simply ignored by the OS. OpenBSD will print: "binman" not configured for the binman node that some of the U-Boot board targets now have, but it doesn't really make a difference. If there is a proper binding for that node, I could simply filter it out. Or we have U-Boot filter it out before the DT gets passed along like Tom suggests. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 15:10 ` Mark Kettenis @ 2021-10-27 15:24 ` Simon Glass 2021-10-27 18:06 ` Tom Rini 2021-10-27 21:52 ` Mark Kettenis 2021-10-27 16:02 ` François Ozog 1 sibling, 2 replies; 73+ messages in thread From: Simon Glass @ 2021-10-27 15:24 UTC (permalink / raw) To: Mark Kettenis Cc: liviu.dudau, narmstrong, vladimir.oltean, linus.walleij, Bin Meng, kever.yang, seanga2, Atish Patra, zong.li, swarren, sr, Fabio Estevam, rainer.boschung, François Ozog, swarren, oleksandr_andrushchenko, Heinrich Schuchardt, lusus, michal.simek, marek.behun, vanbaren, rfried.dev, Jagan Teki, valentin.longchamp, Heiko Schocher, pbrobinson, sinan, fitzsim, wd, Tom Rini, qemu-devel, Andre Przywara, tharvey, Ashok Reddy Soma, rick, Alex Graf, Green Wan, t.karthik.reddy, Anastasiia Lukianenko, Albert ARIBAUD, monstr, mbrugger, ycliang, kristo, u-boot, David Abdurachmanov, priyanka.jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, tuomas.tynkkynen, Heinrich Schuchardt, tianrui-wei, Bin Meng, pali, Dimitri John Ledkov, padmarao.begari Hi Mark, On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > From: François Ozog <francois.ozog@linaro.org> > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > Hi, > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > Hi all, > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > > Hi François, > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> > > > a écrit : > > > > > > > > >> > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > >> > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> > > > wrote: > > > > > > > > >> > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > > > > >> > > Hi Simon, > > > > > > > > >> > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > > > > > >> > > > > > > > > > > > >> > > > 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 at [1]. > > > > > > > > >> > > > > > > > > > > > >> > > > 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. > > > > > > > > >> > > > > > > > > > > >> > > Adding device trees that are never used sounds like a > > > hack to me. > > > > > > > > >> > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > > > based on > > > > > > > > >> > > command line parameters, and the device tree you put in > > > this series > > > > > > > > >> > > has various hardcoded <phandle> values which normally do > > > not show up > > > > > > > > >> > > in hand-written dts files. > > > > > > > > >> > > > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > > > >> > > > > > > > > > >> > I am also confused and do not like the idea of adding > > > device trees for > > > > > > > > >> > platforms that are capable of and can / do have a device > > > tree to give us > > > > > > > > >> > at run time. > > > > > > > > >> > > > > > > > > >> (I'll just reply to this one email, since the same points > > > applies to > > > > > > > > >> all replies I think) > > > > > > > > >> > > > > > > > > >> I have been thinking about this and discussing it with people > > > for a > > > > > > > > >> few months now. I've been signalling a change like this for > > > over a > > > > > > > > >> month now, on U-Boot contributor calls and in discussions > > > with Linaro > > > > > > > > >> people. I sent a patch (below) to try to explain things. I > > > hope it is > > > > > > > > >> not a surprise! > > > > > > > > >> > > > > > > > > >> The issue here is that we need a devicetree in-tree in > > > U-Boot, to > > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, > > > OF_BOARD, > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. > > > Between > > > > > > > > >> Ilias' series and this one we can get ourselves on a stronger > > > footing. > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF > > > use. > > > > > > > > >> For more context: > > > > > > > > >> > > > > > > > > >> > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > >> > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of > > > adding the > > > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > > > > > >> maintainer would prefer there was no special support even for > > > booting > > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > > >> > > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > > >> think the path forward might be to run QEMU twice, once to > > > get its > > > > > > > > >> generated tree and once to give the 'merged' tree with the > > > U-Boot > > > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > > > >> > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > > option, not a > > > > > > > > >> build-time one. It creates all sorts of problems and > > > obscurity which > > > > > > > > >> have taken months to unpick. See the above patch for the > > > rationale. > > > > > > > > >> > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option > > > available to > > > > > > > > >> any board. At some point in the future it may become a common > > > way > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > > > devicetree > > > > > > > > >> to it. It doesn't make any sense to have people decide > > > whether or not > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the image > > > is put > > > > > > > > >> together. We'll end up with different U-Boot build targets > > > like > > > > > > > > >> capricorn, capricorn_of_board and the like. It should be > > > obvious where > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly > > > used > > > > > > > > >> option, perhaps enabled by most/all boards, so that this sort > > > of build > > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > > > If you mean that when boards are by construction providing a > > > DTB to U-Boot then I agree very much. But I don’t understand how the patch > > > set supports it as it puts dts files for those boards to be built. > > > > > > > > >> > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > >> function correctly in whatever runtime environment in which > > > it finds > > > > > > > > >> itself. > > > > > > > > >> > > > > > > > > >> Also as binman is pressed into service more and more to build > > > the > > > > > > > > >> complex firmware images that are becoming fashionable, it > > > needs a > > > > > > > > >> definition (in the devicetree) that describes how to create > > > the image. > > > > > > > > >> We can't support that unless we are building a devicetree, > > > nor can the > > > > > > > > >> running program access the image layout without that > > > information. > > > > > > > > >> > > > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > > > >> germane...but of course I am not suggesting doing that, since > > > OF_BOARD > > > > > > > > >> is, still, enabled. We already use OF_BOARD for various > > > boards that > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for > > > example > > > > > > > > >> (as I said in the cover letter "Most boards do provide one, > > > but some > > > > > > > > >> don't."). So this series is just completing the picture by > > > enforcing > > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > > > > > > > > > I think the key point that will get you closer to where I am on > > > this > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > > present it > > > > > > > > has build-time effects and this is quite wrong. If you go > > > through all > > > > > > > > the material I have written on this I think I have motivated > > > that very > > > > > > > > clearly. > > > > > > > > > > > > > > > > Another big issue is that I believe we need ONE devicetree for > > > U-Boot, > > > > > > > > not two that get merged by U-Boot. Again I have gone through > > > that in a > > > > > > > > lot of detail. > > > > > > > > > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > > > > > here's the biggest sticking point. To be clear, you agree that > > > U-Boot > > > > > > > needs to support being passed a device tree to use, at run time, > > > yes? > > > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > > > > > > > > > Not at runtime. > > > > > > > > > > OK. > > > > > > > > > > > > So is the sticking point here that we really have two classes of > > > > > > > devices, one class where we will never ever be given the device > > > tree at > > > > > > > run time (think BeagleBone Black) and one where we will always be > > > given > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect there will be > > > > > > (many) boards which can boot happily with the U-Boot devicetree but > > > > > > can also accept one at runtime, if provided. For example, you may > > > want > > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > > > I'm not sure I see the value in making this a gray area. There's very > > > > > much a class of "never" boards. There's also the class of "can" today. > > > > > Maybe as part of a developer iterative flow it would be nice to not > > > have > > > > > to re-flash the prior stage to change a DT, and just do it in U-Boot > > > > > until things are happy, but I'm not sure what the use case is for > > > > > overriding the previous stage. > > > > > > > > > > Especially since the pushback on this series I think has all been "why > > > > > are we copying in a tree to build with? We don't want to use it at run > > > > > time!". And then softer push back like "Well, U-Boot says we have to > > > > > include the device tree file here, but we won't use it...". > > > > > > > > See below. > > > > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > > inadvertently) > > > > > > provided a way to entirely omit a devicetree from U-Boot, thus making > > > > > > things like binman and U-Boot /config impossible, for example. So I > > > > > > want to claw that back, so there is always some sort of devicetree in > > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > > > I really want to see what the binary case looks like since we could > > > then > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > > > use the device tree from build time at run time, ignoring the device > > > > > tree provided to us at run time by the caller. > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > confusing these days. Lots of things to build and it's hard to find > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > as we are, it will continue to be messy and in five years you will > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > objective here is to simplify things, bringing some consistency to the > > > > different components. Binman was one effort there. I feel that putting > > > > at least the U-Boot house in order, in my role as devicetree > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > 2011), is the next step. > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > > > that know where to grab other known-good binaries of varying licenses > > > that are needed to assemble something that boots. > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > can be the unifying configuration mechanism through the whole of > > > > firmware (except for very early bits) and into the OS, this will set > > > > us up very well to deal with the complexity that is coming. > > > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > > two months: > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > have its own nodes/properties in the DT. > > > > In my view U-Boot shall be able to leverage device tree format (source and > > binary) to store its own data. > > When you say "the" DT, I always think this is "the" DT that is passed to OS > > and in "that" DT, there should be no U-Boot entries. > > Why not? As long as the device tree validates, it is perfectly fine > to have additional nodes and properties present. The propertiesand > nodes will be simply ignored by the OS. > > OpenBSD will print: > > "binman" not configured > > for the binman node that some of the U-Boot board targets now have, > but it doesn't really make a difference. If there is a proper binding > for that node, I could simply filter it out. Or we have U-Boot filter > it out before the DT gets passed along like Tom suggests. Just on that point, I believe the binman falls into the same bucket that Tom is talking about here, in that it should be a standard binding. Ideally I would like this to become a standard format so that anything in firmware can use it to find stuff. I believe it is a good and extensible way to describe the structure of firmware across all projects. Does "not configured" mean that it did not find the compatible string? We could add one of those, for now, perhaps. Regards, Simon ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 15:24 ` Simon Glass @ 2021-10-27 18:06 ` Tom Rini 2021-10-27 18:11 ` François Ozog 2021-10-27 21:52 ` Mark Kettenis 1 sibling, 1 reply; 73+ messages in thread From: Tom Rini @ 2021-10-27 18:06 UTC (permalink / raw) To: Simon Glass Cc: liviu.dudau, narmstrong, vladimir.oltean, linus.walleij, Bin Meng, kever.yang, seanga2, Atish Patra, zong.li, sr, Fabio Estevam, rainer.boschung, Mark Kettenis, François Ozog, swarren, oleksandr_andrushchenko, Heinrich Schuchardt, lusus, michal.simek, marek.behun, vanbaren, rfried.dev, Jagan Teki, valentin.longchamp, Heiko Schocher, pbrobinson, sinan, fitzsim, wd, swarren, qemu-devel, Andre Przywara, tharvey, Ashok Reddy Soma, rick, Alex Graf, Green Wan, t.karthik.reddy, Anastasiia Lukianenko, Albert ARIBAUD, monstr, mbrugger, ycliang, kristo, u-boot, David Abdurachmanov, priyanka.jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, tuomas.tynkkynen, Heinrich Schuchardt, tianrui-wei, Bin Meng, pali, Dimitri John Ledkov, padmarao.begari [-- Attachment #1: Type: text/plain, Size: 16848 bytes --] On Wed, Oct 27, 2021 at 09:24:25AM -0600, Simon Glass wrote: > Hi Mark, > > On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > From: François Ozog <francois.ozog@linaro.org> > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > Hi, > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > Hi all, > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> > > > > a écrit : > > > > > > > > > >> > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > >> > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> > > > > wrote: > > > > > > > > > >> > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > > > > > >> > > Hi Simon, > > > > > > > > > >> > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > > > > > > >> > > > > > > > > > > > > >> > > > 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 at [1]. > > > > > > > > > >> > > > > > > > > > > > > >> > > > 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. > > > > > > > > > >> > > > > > > > > > > > >> > > Adding device trees that are never used sounds like a > > > > hack to me. > > > > > > > > > >> > > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > > > > based on > > > > > > > > > >> > > command line parameters, and the device tree you put in > > > > this series > > > > > > > > > >> > > has various hardcoded <phandle> values which normally do > > > > not show up > > > > > > > > > >> > > in hand-written dts files. > > > > > > > > > >> > > > > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > > > > >> > > > > > > > > > > >> > I am also confused and do not like the idea of adding > > > > device trees for > > > > > > > > > >> > platforms that are capable of and can / do have a device > > > > tree to give us > > > > > > > > > >> > at run time. > > > > > > > > > >> > > > > > > > > > >> (I'll just reply to this one email, since the same points > > > > applies to > > > > > > > > > >> all replies I think) > > > > > > > > > >> > > > > > > > > > >> I have been thinking about this and discussing it with people > > > > for a > > > > > > > > > >> few months now. I've been signalling a change like this for > > > > over a > > > > > > > > > >> month now, on U-Boot contributor calls and in discussions > > > > with Linaro > > > > > > > > > >> people. I sent a patch (below) to try to explain things. I > > > > hope it is > > > > > > > > > >> not a surprise! > > > > > > > > > >> > > > > > > > > > >> The issue here is that we need a devicetree in-tree in > > > > U-Boot, to > > > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, > > > > OF_BOARD, > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. > > > > Between > > > > > > > > > >> Ilias' series and this one we can get ourselves on a stronger > > > > footing. > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF > > > > use. > > > > > > > > > >> For more context: > > > > > > > > > >> > > > > > > > > > >> > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > >> > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of > > > > adding the > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > > > > > > >> maintainer would prefer there was no special support even for > > > > booting > > > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > > > >> > > > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > > > >> think the path forward might be to run QEMU twice, once to > > > > get its > > > > > > > > > >> generated tree and once to give the 'merged' tree with the > > > > U-Boot > > > > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > > > > >> > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > > > option, not a > > > > > > > > > >> build-time one. It creates all sorts of problems and > > > > obscurity which > > > > > > > > > >> have taken months to unpick. See the above patch for the > > > > rationale. > > > > > > > > > >> > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option > > > > available to > > > > > > > > > >> any board. At some point in the future it may become a common > > > > way > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > > > > devicetree > > > > > > > > > >> to it. It doesn't make any sense to have people decide > > > > whether or not > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the image > > > > is put > > > > > > > > > >> together. We'll end up with different U-Boot build targets > > > > like > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should be > > > > obvious where > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly > > > > used > > > > > > > > > >> option, perhaps enabled by most/all boards, so that this sort > > > > of build > > > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > > > > > If you mean that when boards are by construction providing a > > > > DTB to U-Boot then I agree very much. But I don’t understand how the patch > > > > set supports it as it puts dts files for those boards to be built. > > > > > > > > > >> > > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > > >> function correctly in whatever runtime environment in which > > > > it finds > > > > > > > > > >> itself. > > > > > > > > > >> > > > > > > > > > >> Also as binman is pressed into service more and more to build > > > > the > > > > > > > > > >> complex firmware images that are becoming fashionable, it > > > > needs a > > > > > > > > > >> definition (in the devicetree) that describes how to create > > > > the image. > > > > > > > > > >> We can't support that unless we are building a devicetree, > > > > nor can the > > > > > > > > > >> running program access the image layout without that > > > > information. > > > > > > > > > >> > > > > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > > > > >> germane...but of course I am not suggesting doing that, since > > > > OF_BOARD > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for various > > > > boards that > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for > > > > example > > > > > > > > > >> (as I said in the cover letter "Most boards do provide one, > > > > but some > > > > > > > > > >> don't."). So this series is just completing the picture by > > > > enforcing > > > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > > > > > > > > > > > I think the key point that will get you closer to where I am on > > > > this > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > > > present it > > > > > > > > > has build-time effects and this is quite wrong. If you go > > > > through all > > > > > > > > > the material I have written on this I think I have motivated > > > > that very > > > > > > > > > clearly. > > > > > > > > > > > > > > > > > > Another big issue is that I believe we need ONE devicetree for > > > > U-Boot, > > > > > > > > > not two that get merged by U-Boot. Again I have gone through > > > > that in a > > > > > > > > > lot of detail. > > > > > > > > > > > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > > > > > > here's the biggest sticking point. To be clear, you agree that > > > > U-Boot > > > > > > > > needs to support being passed a device tree to use, at run time, > > > > yes? > > > > > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > > > > > > > > > > > Not at runtime. > > > > > > > > > > > > OK. > > > > > > > > > > > > > > So is the sticking point here that we really have two classes of > > > > > > > > devices, one class where we will never ever be given the device > > > > tree at > > > > > > > > run time (think BeagleBone Black) and one where we will always be > > > > given > > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect there will be > > > > > > > (many) boards which can boot happily with the U-Boot devicetree but > > > > > > > can also accept one at runtime, if provided. For example, you may > > > > want > > > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > > > > > I'm not sure I see the value in making this a gray area. There's very > > > > > > much a class of "never" boards. There's also the class of "can" today. > > > > > > Maybe as part of a developer iterative flow it would be nice to not > > > > have > > > > > > to re-flash the prior stage to change a DT, and just do it in U-Boot > > > > > > until things are happy, but I'm not sure what the use case is for > > > > > > overriding the previous stage. > > > > > > > > > > > > Especially since the pushback on this series I think has all been "why > > > > > > are we copying in a tree to build with? We don't want to use it at run > > > > > > time!". And then softer push back like "Well, U-Boot says we have to > > > > > > include the device tree file here, but we won't use it...". > > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > > > inadvertently) > > > > > > > provided a way to entirely omit a devicetree from U-Boot, thus making > > > > > > > things like binman and U-Boot /config impossible, for example. So I > > > > > > > want to claw that back, so there is always some sort of devicetree in > > > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > > > > > I really want to see what the binary case looks like since we could > > > > then > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > > > > use the device tree from build time at run time, ignoring the device > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > confusing these days. Lots of things to build and it's hard to find > > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > > as we are, it will continue to be messy and in five years you will > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > objective here is to simplify things, bringing some consistency to the > > > > > different components. Binman was one effort there. I feel that putting > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > 2011), is the next step. > > > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > > > > that know where to grab other known-good binaries of varying licenses > > > > that are needed to assemble something that boots. > > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > > can be the unifying configuration mechanism through the whole of > > > > > firmware (except for very early bits) and into the OS, this will set > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > > > two months: > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > > have its own nodes/properties in the DT. > > > > > > In my view U-Boot shall be able to leverage device tree format (source and > > > binary) to store its own data. > > > When you say "the" DT, I always think this is "the" DT that is passed to OS > > > and in "that" DT, there should be no U-Boot entries. > > > > Why not? As long as the device tree validates, it is perfectly fine > > to have additional nodes and properties present. The propertiesand > > nodes will be simply ignored by the OS. > > > > OpenBSD will print: > > > > "binman" not configured > > > > for the binman node that some of the U-Boot board targets now have, > > but it doesn't really make a difference. If there is a proper binding > > for that node, I could simply filter it out. Or we have U-Boot filter > > it out before the DT gets passed along like Tom suggests. > > Just on that point, I believe the binman falls into the same bucket > that Tom is talking about here, in that it should be a standard > binding. Ideally I would like this to become a standard format so that > anything in firmware can use it to find stuff. I believe it is a good > and extensible way to describe the structure of firmware across all > projects. And at the risk of getting lost on specific details, if we look at: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html it says "In the future, it may be provided as part of a device blob, along with the rest of the information about images to load." which is one of the things the binman node solves, so we should probably solve this problem once, for everyone rather than per-project. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 18:06 ` Tom Rini @ 2021-10-27 18:11 ` François Ozog 0 siblings, 0 replies; 73+ messages in thread From: François Ozog @ 2021-10-27 18:11 UTC (permalink / raw) To: Tom Rini Cc: liviu.dudau, narmstrong, rick, vladimir.oltean, linus.walleij, Bin Meng, kever.yang, seanga2, Atish Patra, zong.li, sr, Fabio Estevam, rainer.boschung, Mark Kettenis, swarren, oleksandr_andrushchenko, Heinrich Schuchardt, lusus, michal.simek, marek.behun, vanbaren, rfried.dev, Jagan Teki, valentin.longchamp, Heiko Schocher, pbrobinson, sinan, fitzsim, wd, swarren, Andre Przywara, tharvey, Ashok Reddy Soma, qemu-devel, Alex Graf, Green Wan, t.karthik.reddy, Anastasiia Lukianenko, Albert ARIBAUD, monstr, mbrugger, ycliang, kristo, u-boot, David Abdurachmanov, priyanka.jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, tuomas.tynkkynen, Heinrich Schuchardt, tianrui-wei, Bin Meng, pali, Dimitri John Ledkov, padmarao.begari [-- Attachment #1: Type: text/plain, Size: 18141 bytes --] Hi Tom Le mer. 27 oct. 2021 à 20:06, Tom Rini <trini@konsulko.com> a écrit : > On Wed, Oct 27, 2021 at 09:24:25AM -0600, Simon Glass wrote: > > Hi Mark, > > > > On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl> > wrote: > > > > > > > From: François Ozog <francois.ozog@linaro.org> > > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > > > Hi, > > > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > > Hi all, > > > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> > wrote: > > > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> > wrote: > > > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass > wrote: > > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > sjg@chromium.org> > > > > > a écrit : > > > > > > > > > > >> > > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > > >> > > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > trini@konsulko.com> > > > > > wrote: > > > > > > > > > > >> > > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > wrote: > > > > > > > > > > >> > > Hi Simon, > > > > > > > > > > >> > > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > 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 > at [1]. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > 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. > > > > > > > > > > >> > > > > > > > > > > > > >> > > Adding device trees that are never used sounds > like a > > > > > hack to me. > > > > > > > > > > >> > > > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on > the fly > > > > > based on > > > > > > > > > > >> > > command line parameters, and the device tree you > put in > > > > > this series > > > > > > > > > > >> > > has various hardcoded <phandle> values which > normally do > > > > > not show up > > > > > > > > > > >> > > in hand-written dts files. > > > > > > > > > > >> > > > > > > > > > > > > >> > > I am not sure I understand the whole point of > this. > > > > > > > > > > >> > > > > > > > > > > > >> > I am also confused and do not like the idea of > adding > > > > > device trees for > > > > > > > > > > >> > platforms that are capable of and can / do have a > device > > > > > tree to give us > > > > > > > > > > >> > at run time. > > > > > > > > > > >> > > > > > > > > > > >> (I'll just reply to this one email, since the same > points > > > > > applies to > > > > > > > > > > >> all replies I think) > > > > > > > > > > >> > > > > > > > > > > >> I have been thinking about this and discussing it > with people > > > > > for a > > > > > > > > > > >> few months now. I've been signalling a change like > this for > > > > > over a > > > > > > > > > > >> month now, on U-Boot contributor calls and in > discussions > > > > > with Linaro > > > > > > > > > > >> people. I sent a patch (below) to try to explain > things. I > > > > > hope it is > > > > > > > > > > >> not a surprise! > > > > > > > > > > >> > > > > > > > > > > >> The issue here is that we need a devicetree in-tree in > > > > > U-Boot, to > > > > > > > > > > >> avoid the mess that has been created by > OF_PRIOR_STAGE, > > > > > OF_BOARD, > > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, > OF_HOSTFILE. > > > > > Between > > > > > > > > > > >> Ilias' series and this one we can get ourselves on a > stronger > > > > > footing. > > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for > debugging/ELF > > > > > use. > > > > > > > > > > >> For more context: > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > >> > > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way > of > > > > > adding the > > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in > fact the > > > > > > > > > > >> maintainer would prefer there was no special support > even for > > > > > booting > > > > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > > > > >> > > > > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > > > > >> think the path forward might be to run QEMU twice, > once to > > > > > get its > > > > > > > > > > >> generated tree and once to give the 'merged' tree > with the > > > > > U-Boot > > > > > > > > > > >> properties in it, if people want to use U-Boot > features. > > > > > > > > > > >> > > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > > > > option, not a > > > > > > > > > > >> build-time one. It creates all sorts of problems and > > > > > obscurity which > > > > > > > > > > >> have taken months to unpick. See the above patch for > the > > > > > rationale. > > > > > > > > > > >> > > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an > option > > > > > available to > > > > > > > > > > >> any board. At some point in the future it may become > a common > > > > > way > > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and > providing a > > > > > devicetree > > > > > > > > > > >> to it. It doesn't make any sense to have people decide > > > > > whether or not > > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the > image > > > > > is put > > > > > > > > > > >> together. We'll end up with different U-Boot build > targets > > > > > like > > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should > be > > > > > obvious where > > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a > commonly > > > > > used > > > > > > > > > > >> option, perhaps enabled by most/all boards, so that > this sort > > > > > of build > > > > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > > > > > > > If you mean that when boards are by construction > providing a > > > > > DTB to U-Boot then I agree very much. But I don’t understand how > the patch > > > > > set supports it as it puts dts files for those boards to be built. > > > > > > > > > > >> > > > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > > > >> function correctly in whatever runtime environment in > which > > > > > it finds > > > > > > > > > > >> itself. > > > > > > > > > > >> > > > > > > > > > > >> Also as binman is pressed into service more and more > to build > > > > > the > > > > > > > > > > >> complex firmware images that are becoming > fashionable, it > > > > > needs a > > > > > > > > > > >> definition (in the devicetree) that describes how to > create > > > > > the image. > > > > > > > > > > >> We can't support that unless we are building a > devicetree, > > > > > nor can the > > > > > > > > > > >> running program access the image layout without that > > > > > information. > > > > > > > > > > >> > > > > > > > > > > >> François's point about 'don't use this with any > kernel' is > > > > > > > > > > >> germane...but of course I am not suggesting doing > that, since > > > > > OF_BOARD > > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for > various > > > > > boards that > > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and > 3, for > > > > > example > > > > > > > > > > >> (as I said in the cover letter "Most boards do > provide one, > > > > > but some > > > > > > > > > > >> don't."). So this series is just completing the > picture by > > > > > enforcing > > > > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the > default. > > > > > > > > > > > > > > > > > > > > I think the key point that will get you closer to where > I am on > > > > > this > > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > > > > present it > > > > > > > > > > has build-time effects and this is quite wrong. If you go > > > > > through all > > > > > > > > > > the material I have written on this I think I have > motivated > > > > > that very > > > > > > > > > > clearly. > > > > > > > > > > > > > > > > > > > > Another big issue is that I believe we need ONE > devicetree for > > > > > U-Boot, > > > > > > > > > > not two that get merged by U-Boot. Again I have gone > through > > > > > that in a > > > > > > > > > > lot of detail. > > > > > > > > > > > > > > > > > > I have a long long reply to your first reply here saved, > but, maybe > > > > > > > > > here's the biggest sticking point. To be clear, you agree > that > > > > > U-Boot > > > > > > > > > needs to support being passed a device tree to use, at run > time, > > > > > yes? > > > > > > > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we > built in? > > > > > > > > > > > > > > > > Not at runtime. > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > So is the sticking point here that we really have two > classes of > > > > > > > > > devices, one class where we will never ever be given the > device > > > > > tree at > > > > > > > > > run time (think BeagleBone Black) and one where we will > always be > > > > > given > > > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect > there will be > > > > > > > > (many) boards which can boot happily with the U-Boot > devicetree but > > > > > > > > can also accept one at runtime, if provided. For example, > you may > > > > > want > > > > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > > > > > > > I'm not sure I see the value in making this a gray area. > There's very > > > > > > > much a class of "never" boards. There's also the class of > "can" today. > > > > > > > Maybe as part of a developer iterative flow it would be nice > to not > > > > > have > > > > > > > to re-flash the prior stage to change a DT, and just do it in > U-Boot > > > > > > > until things are happy, but I'm not sure what the use case is > for > > > > > > > overriding the previous stage. > > > > > > > > > > > > > > Especially since the pushback on this series I think has all > been "why > > > > > > > are we copying in a tree to build with? We don't want to use > it at run > > > > > > > time!". And then softer push back like "Well, U-Boot says we > have to > > > > > > > include the device tree file here, but we won't use it...". > > > > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > > > > inadvertently) > > > > > > > > provided a way to entirely omit a devicetree from U-Boot, > thus making > > > > > > > > things like binman and U-Boot /config impossible, for > example. So I > > > > > > > > want to claw that back, so there is always some sort of > devicetree in > > > > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > > > > > > > I really want to see what the binary case looks like since we > could > > > > > then > > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > could > > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can > come > > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we > also don't > > > > > > > use the device tree from build time at run time, ignoring the > device > > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > > confusing these days. Lots of things to build and it's hard to > find > > > > > > the instructions. It doesn't have to be that way, but if we > carry on > > > > > > as we are, it will continue to be messy and in five years you > will > > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > > objective here is to simplify things, bringing some consistency > to the > > > > > > different components. Binman was one effort there. I feel that > putting > > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > > 2011), is the next step. > > > > > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh > scripts > > > > > that know where to grab other known-good binaries of varying > licenses > > > > > that are needed to assemble something that boots. > > > > > > > > > > > If we set things up correctly and agree on the bindings, > devicetree > > > > > > can be the unifying configuration mechanism through the whole of > > > > > > firmware (except for very early bits) and into the OS, this will > set > > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > > > Anyway, here are the mental steps that I've gone through over > the past > > > > > > two months: > > > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed > to > > > > > > have its own nodes/properties in the DT. > > > > > > > > In my view U-Boot shall be able to leverage device tree format > (source and > > > > binary) to store its own data. > > > > When you say "the" DT, I always think this is "the" DT that is > passed to OS > > > > and in "that" DT, there should be no U-Boot entries. > > > > > > Why not? As long as the device tree validates, it is perfectly fine > > > to have additional nodes and properties present. The propertiesand > > > nodes will be simply ignored by the OS. > > > > > > OpenBSD will print: > > > > > > "binman" not configured > > > > > > for the binman node that some of the U-Boot board targets now have, > > > but it doesn't really make a difference. If there is a proper binding > > > for that node, I could simply filter it out. Or we have U-Boot filter > > > it out before the DT gets passed along like Tom suggests. > > > > Just on that point, I believe the binman falls into the same bucket > > that Tom is talking about here, in that it should be a standard > > binding. Ideally I would like this to become a standard format so that > > anything in firmware can use it to find stuff. I believe it is a good > > and extensible way to describe the structure of firmware across all > > projects. > > And at the risk of getting lost on specific details, if we look at: > > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html > it says "In the future, it may be provided as part of a device blob, > along with the rest of the information about images to load." which is > one of the things the binman node solves, so we should probably solve > this problem once, for everyone rather than per-project. > i wish we could. We need RISC-V input here. > > -- > Tom > -- 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: 28824 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 15:24 ` Simon Glass 2021-10-27 18:06 ` Tom Rini @ 2021-10-27 21:52 ` Mark Kettenis 1 sibling, 0 replies; 73+ messages in thread From: Mark Kettenis @ 2021-10-27 21:52 UTC (permalink / raw) To: Simon Glass Cc: liviu.dudau, narmstrong, vladimir.oltean, linus.walleij, bin.meng, kever.yang, seanga2, atish.patra, zong.li, swarren, sr, festevam, rainer.boschung, francois.ozog, swarren, oleksandr_andrushchenko, xypron.glpk, lusus, michal.simek, marek.behun, vanbaren, rfried.dev, jagan, valentin.longchamp, hs, pbrobinson, sinan, fitzsim, wd, trini, qemu-devel, andre.przywara, tharvey, ashok.reddy.soma, rick, agraf, green.wan, t.karthik.reddy, anastasiia_lukianenko, albert.u.boot, monstr, mbrugger, ycliang, kristo, u-boot, david.abdurachmanov, priyanka.jain, ilias.apalodimas, christianshewitt, awilliams, tuomas.tynkkynen, heinrich.schuchardt, tianrui-wei, bmeng.cn, pali, dimitri.ledkov, padmarao.begari > From: Simon Glass <sjg@chromium.org> > Date: Wed, 27 Oct 2021 09:24:25 -0600 > > Hi Mark, > > On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > From: François Ozog <francois.ozog@linaro.org> > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > In my view U-Boot shall be able to leverage device tree format > > > (source and binary) to store its own data. When you say "the" > > > DT, I always think this is "the" DT that is passed to OS and in > > > "that" DT, there should be no U-Boot entries. > > > > Why not? As long as the device tree validates, it is perfectly fine > > to have additional nodes and properties present. The propertiesand > > nodes will be simply ignored by the OS. > > > > OpenBSD will print: > > > > "binman" not configured > > > > for the binman node that some of the U-Boot board targets now have, > > but it doesn't really make a difference. If there is a proper binding > > for that node, I could simply filter it out. Or we have U-Boot filter > > it out before the DT gets passed along like Tom suggests. > > Just on that point, I believe the binman falls into the same bucket > that Tom is talking about here, in that it should be a standard > binding. Ideally I would like this to become a standard format so that > anything in firmware can use it to find stuff. I believe it is a good > and extensible way to describe the structure of firmware across all > projects. Oh, I agree that it is a reasonable thing to have a description of the structure of the firmware in the device tree. > Does "not configured" mean that it did not find the compatible string? > We could add one of those, for now, perhaps. "not configured" just means that no device driver attached to the node. Usually that is because we don't have a device driver for the device corresponding to the node yet. But in the case of the "binman" node it doesn't really make sense for a device driver to attach. In such a case we tend to filter out the node such that the "not configured" line isn't printed. That can be done either by name or by compatible string. So an "official" binding would help here and it should either use a standardized name (that shouldn't be used for other purposes then) or it should use defined a compatible string. Anyway, this is not really critical. I just brought it up to illustrate that such nodes are mostly harmless. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 15:10 ` Mark Kettenis 2021-10-27 15:24 ` Simon Glass @ 2021-10-27 16:02 ` François Ozog 2021-10-27 19:06 ` Tom Rini 1 sibling, 1 reply; 73+ messages in thread From: François Ozog @ 2021-10-27 16:02 UTC (permalink / raw) To: Mark Kettenis Cc: liviu.dudau, narmstrong, vladimir.oltean, linus.walleij, bin.meng, kever.yang, seanga2, atish.patra, zong.li, sr, festevam, rainer.boschung, trini, swarren, oleksandr_andrushchenko, xypron.glpk, lusus, michal.simek, marek.behun, vanbaren, rfried.dev, jagan, valentin.longchamp, hs, pbrobinson, sinan, fitzsim, wd, swarren, qemu-devel, andre.przywara, tharvey, ashok.reddy.soma, rick, agraf, green.wan, t.karthik.reddy, anastasiia_lukianenko, albert.u.boot, monstr, mbrugger, ycliang, kristo, u-boot, david.abdurachmanov, priyanka.jain, sjg, ilias.apalodimas, christianshewitt, awilliams, tuomas.tynkkynen, heinrich.schuchardt, tianrui-wei, bmeng.cn, pali, dimitri.ledkov, padmarao.begari [-- Attachment #1: Type: text/plain, Size: 16248 bytes --] Hi Mark, On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > From: François Ozog <francois.ozog@linaro.org> > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > Hi, > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > Hi all, > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> > wrote: > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > > Hi François, > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > sjg@chromium.org> > > > a écrit : > > > > > > > > >> > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > >> > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > trini@konsulko.com> > > > wrote: > > > > > > > > >> > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > wrote: > > > > > > > > >> > > Hi Simon, > > > > > > > > >> > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > > > > > >> > > > > > > > > > > > >> > > > 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 at > [1]. > > > > > > > > >> > > > > > > > > > > > >> > > > 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. > > > > > > > > >> > > > > > > > > > > >> > > Adding device trees that are never used sounds like a > > > hack to me. > > > > > > > > >> > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the > fly > > > based on > > > > > > > > >> > > command line parameters, and the device tree you put > in > > > this series > > > > > > > > >> > > has various hardcoded <phandle> values which normally > do > > > not show up > > > > > > > > >> > > in hand-written dts files. > > > > > > > > >> > > > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > > > >> > > > > > > > > > >> > I am also confused and do not like the idea of adding > > > device trees for > > > > > > > > >> > platforms that are capable of and can / do have a device > > > tree to give us > > > > > > > > >> > at run time. > > > > > > > > >> > > > > > > > > >> (I'll just reply to this one email, since the same points > > > applies to > > > > > > > > >> all replies I think) > > > > > > > > >> > > > > > > > > >> I have been thinking about this and discussing it with > people > > > for a > > > > > > > > >> few months now. I've been signalling a change like this > for > > > over a > > > > > > > > >> month now, on U-Boot contributor calls and in discussions > > > with Linaro > > > > > > > > >> people. I sent a patch (below) to try to explain things. I > > > hope it is > > > > > > > > >> not a surprise! > > > > > > > > >> > > > > > > > > >> The issue here is that we need a devicetree in-tree in > > > U-Boot, to > > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, > > > OF_BOARD, > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. > > > Between > > > > > > > > >> Ilias' series and this one we can get ourselves on a > stronger > > > footing. > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF > > > use. > > > > > > > > >> For more context: > > > > > > > > >> > > > > > > > > >> > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > >> > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of > > > adding the > > > > > > > > >> u-boot.dtsi but there was not much interest there (in > fact the > > > > > > > > >> maintainer would prefer there was no special support even > for > > > booting > > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > > >> > > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > > >> think the path forward might be to run QEMU twice, once to > > > get its > > > > > > > > >> generated tree and once to give the 'merged' tree with the > > > U-Boot > > > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > > > >> > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > > option, not a > > > > > > > > >> build-time one. It creates all sorts of problems and > > > obscurity which > > > > > > > > >> have taken months to unpick. See the above patch for the > > > rationale. > > > > > > > > >> > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option > > > available to > > > > > > > > >> any board. At some point in the future it may become a > common > > > way > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > > > devicetree > > > > > > > > >> to it. It doesn't make any sense to have people decide > > > whether or not > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the > image > > > is put > > > > > > > > >> together. We'll end up with different U-Boot build targets > > > like > > > > > > > > >> capricorn, capricorn_of_board and the like. It should be > > > obvious where > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a > commonly > > > used > > > > > > > > >> option, perhaps enabled by most/all boards, so that this > sort > > > of build > > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > > > If you mean that when boards are by construction providing > a > > > DTB to U-Boot then I agree very much. But I don’t understand how the > patch > > > set supports it as it puts dts files for those boards to be built. > > > > > > > > >> > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > >> function correctly in whatever runtime environment in > which > > > it finds > > > > > > > > >> itself. > > > > > > > > >> > > > > > > > > >> Also as binman is pressed into service more and more to > build > > > the > > > > > > > > >> complex firmware images that are becoming fashionable, it > > > needs a > > > > > > > > >> definition (in the devicetree) that describes how to > create > > > the image. > > > > > > > > >> We can't support that unless we are building a devicetree, > > > nor can the > > > > > > > > >> running program access the image layout without that > > > information. > > > > > > > > >> > > > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > > > >> germane...but of course I am not suggesting doing that, > since > > > OF_BOARD > > > > > > > > >> is, still, enabled. We already use OF_BOARD for various > > > boards that > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, > for > > > example > > > > > > > > >> (as I said in the cover letter "Most boards do provide > one, > > > but some > > > > > > > > >> don't."). So this series is just completing the picture by > > > enforcing > > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the > default. > > > > > > > > > > > > > > > > I think the key point that will get you closer to where I am > on > > > this > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > > present it > > > > > > > > has build-time effects and this is quite wrong. If you go > > > through all > > > > > > > > the material I have written on this I think I have motivated > > > that very > > > > > > > > clearly. > > > > > > > > > > > > > > > > Another big issue is that I believe we need ONE devicetree > for > > > U-Boot, > > > > > > > > not two that get merged by U-Boot. Again I have gone through > > > that in a > > > > > > > > lot of detail. > > > > > > > > > > > > > > I have a long long reply to your first reply here saved, but, > maybe > > > > > > > here's the biggest sticking point. To be clear, you agree that > > > U-Boot > > > > > > > needs to support being passed a device tree to use, at run > time, > > > yes? > > > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we built > in? > > > > > > > > > > > > Not at runtime. > > > > > > > > > > OK. > > > > > > > > > > > > So is the sticking point here that we really have two classes > of > > > > > > > devices, one class where we will never ever be given the device > > > tree at > > > > > > > run time (think BeagleBone Black) and one where we will always > be > > > given > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect there > will be > > > > > > (many) boards which can boot happily with the U-Boot devicetree > but > > > > > > can also accept one at runtime, if provided. For example, you may > > > want > > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > > > I'm not sure I see the value in making this a gray area. There's > very > > > > > much a class of "never" boards. There's also the class of "can" > today. > > > > > Maybe as part of a developer iterative flow it would be nice to not > > > have > > > > > to re-flash the prior stage to change a DT, and just do it in > U-Boot > > > > > until things are happy, but I'm not sure what the use case is for > > > > > overriding the previous stage. > > > > > > > > > > Especially since the pushback on this series I think has all been > "why > > > > > are we copying in a tree to build with? We don't want to use it > at run > > > > > time!". And then softer push back like "Well, U-Boot says we have > to > > > > > include the device tree file here, but we won't use it...". > > > > > > > > See below. > > > > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > > inadvertently) > > > > > > provided a way to entirely omit a devicetree from U-Boot, thus > making > > > > > > things like binman and U-Boot /config impossible, for example. > So I > > > > > > want to claw that back, so there is always some sort of > devicetree in > > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > > > I really want to see what the binary case looks like since we could > > > then > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > could > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > don't > > > > > use the device tree from build time at run time, ignoring the > device > > > > > tree provided to us at run time by the caller. > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > confusing these days. Lots of things to build and it's hard to find > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > as we are, it will continue to be messy and in five years you will > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > objective here is to simplify things, bringing some consistency to > the > > > > different components. Binman was one effort there. I feel that > putting > > > > at least the U-Boot house in order, in my role as devicetree > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > 2011), is the next step. > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > > > that know where to grab other known-good binaries of varying licenses > > > that are needed to assemble something that boots. > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > can be the unifying configuration mechanism through the whole of > > > > firmware (except for very early bits) and into the OS, this will set > > > > us up very well to deal with the complexity that is coming. > > > > > > > > Anyway, here are the mental steps that I've gone through over the > past > > > > two months: > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > have its own nodes/properties in the DT. > > > > In my view U-Boot shall be able to leverage device tree format (source > and > > binary) to store its own data. > > When you say "the" DT, I always think this is "the" DT that is passed to > OS > > and in "that" DT, there should be no U-Boot entries. > > Why not? As long as the device tree validates, it is perfectly fine > to have additional nodes and properties present. The propertiesand > nodes will be simply ignored by the OS. > > Because of the way we want to organize the firmware supply chain: when the board is built, it is "attached" a device tree. At that moment, we don't know what "non trusted firmware" will be used. It could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2 (yes it works with DT). And we aim at keeping device tree as close to the original intent: hardware description only. It's not because we can stuff anything in the DT and that it is simple to do that we should. Driver parameters shall be in the OS facility built for that purpose. Using device tree has been an ugly habit. > OpenBSD will print: > > "binman" not configured > > for the binman node that some of the U-Boot board targets now have, > but it doesn't really make a difference. If there is a proper binding > for that node, I could simply filter it out. Or we have U-Boot filter > it out before the DT gets passed along like Tom suggests. > -- 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: 25049 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 16:02 ` François Ozog @ 2021-10-27 19:06 ` Tom Rini 2021-10-27 22:00 ` François Ozog 0 siblings, 1 reply; 73+ messages in thread From: Tom Rini @ 2021-10-27 19:06 UTC (permalink / raw) To: François Ozog Cc: liviu.dudau, narmstrong, vladimir.oltean, linus.walleij, bin.meng, kever.yang, seanga2, atish.patra, zong.li, sr, festevam, rainer.boschung, Mark Kettenis, swarren, oleksandr_andrushchenko, xypron.glpk, lusus, michal.simek, marek.behun, vanbaren, rfried.dev, jagan, valentin.longchamp, hs, pbrobinson, sinan, fitzsim, wd, swarren, qemu-devel, andre.przywara, tharvey, ashok.reddy.soma, rick, agraf, green.wan, t.karthik.reddy, anastasiia_lukianenko, albert.u.boot, monstr, mbrugger, ycliang, kristo, u-boot, david.abdurachmanov, priyanka.jain, sjg, ilias.apalodimas, christianshewitt, awilliams, tuomas.tynkkynen, heinrich.schuchardt, tianrui-wei, bmeng.cn, pali, dimitri.ledkov, padmarao.begari [-- Attachment #1: Type: text/plain, Size: 17811 bytes --] On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote: > Hi Mark, > > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > From: François Ozog <francois.ozog@linaro.org> > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > Hi, > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > Hi all, > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> > > wrote: > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > > sjg@chromium.org> > > > > a écrit : > > > > > > > > > >> > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > >> > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > > trini@konsulko.com> > > > > wrote: > > > > > > > > > >> > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > > wrote: > > > > > > > > > >> > > Hi Simon, > > > > > > > > > >> > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > > > > > > >> > > > > > > > > > > > > >> > > > 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 at > > [1]. > > > > > > > > > >> > > > > > > > > > > > > >> > > > 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. > > > > > > > > > >> > > > > > > > > > > > >> > > Adding device trees that are never used sounds like a > > > > hack to me. > > > > > > > > > >> > > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the > > fly > > > > based on > > > > > > > > > >> > > command line parameters, and the device tree you put > > in > > > > this series > > > > > > > > > >> > > has various hardcoded <phandle> values which normally > > do > > > > not show up > > > > > > > > > >> > > in hand-written dts files. > > > > > > > > > >> > > > > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > > > > >> > > > > > > > > > > >> > I am also confused and do not like the idea of adding > > > > device trees for > > > > > > > > > >> > platforms that are capable of and can / do have a device > > > > tree to give us > > > > > > > > > >> > at run time. > > > > > > > > > >> > > > > > > > > > >> (I'll just reply to this one email, since the same points > > > > applies to > > > > > > > > > >> all replies I think) > > > > > > > > > >> > > > > > > > > > >> I have been thinking about this and discussing it with > > people > > > > for a > > > > > > > > > >> few months now. I've been signalling a change like this > > for > > > > over a > > > > > > > > > >> month now, on U-Boot contributor calls and in discussions > > > > with Linaro > > > > > > > > > >> people. I sent a patch (below) to try to explain things. I > > > > hope it is > > > > > > > > > >> not a surprise! > > > > > > > > > >> > > > > > > > > > >> The issue here is that we need a devicetree in-tree in > > > > U-Boot, to > > > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, > > > > OF_BOARD, > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. > > > > Between > > > > > > > > > >> Ilias' series and this one we can get ourselves on a > > stronger > > > > footing. > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF > > > > use. > > > > > > > > > >> For more context: > > > > > > > > > >> > > > > > > > > > >> > > > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > >> > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of > > > > adding the > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in > > fact the > > > > > > > > > >> maintainer would prefer there was no special support even > > for > > > > booting > > > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > > > >> > > > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > > > >> think the path forward might be to run QEMU twice, once to > > > > get its > > > > > > > > > >> generated tree and once to give the 'merged' tree with the > > > > U-Boot > > > > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > > > > >> > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > > > option, not a > > > > > > > > > >> build-time one. It creates all sorts of problems and > > > > obscurity which > > > > > > > > > >> have taken months to unpick. See the above patch for the > > > > rationale. > > > > > > > > > >> > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option > > > > available to > > > > > > > > > >> any board. At some point in the future it may become a > > common > > > > way > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > > > > devicetree > > > > > > > > > >> to it. It doesn't make any sense to have people decide > > > > whether or not > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the > > image > > > > is put > > > > > > > > > >> together. We'll end up with different U-Boot build targets > > > > like > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should be > > > > obvious where > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a > > commonly > > > > used > > > > > > > > > >> option, perhaps enabled by most/all boards, so that this > > sort > > > > of build > > > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > > > > > If you mean that when boards are by construction providing > > a > > > > DTB to U-Boot then I agree very much. But I don’t understand how the > > patch > > > > set supports it as it puts dts files for those boards to be built. > > > > > > > > > >> > > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > > >> function correctly in whatever runtime environment in > > which > > > > it finds > > > > > > > > > >> itself. > > > > > > > > > >> > > > > > > > > > >> Also as binman is pressed into service more and more to > > build > > > > the > > > > > > > > > >> complex firmware images that are becoming fashionable, it > > > > needs a > > > > > > > > > >> definition (in the devicetree) that describes how to > > create > > > > the image. > > > > > > > > > >> We can't support that unless we are building a devicetree, > > > > nor can the > > > > > > > > > >> running program access the image layout without that > > > > information. > > > > > > > > > >> > > > > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > > > > >> germane...but of course I am not suggesting doing that, > > since > > > > OF_BOARD > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for various > > > > boards that > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, > > for > > > > example > > > > > > > > > >> (as I said in the cover letter "Most boards do provide > > one, > > > > but some > > > > > > > > > >> don't."). So this series is just completing the picture by > > > > enforcing > > > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the > > default. > > > > > > > > > > > > > > > > > > I think the key point that will get you closer to where I am > > on > > > > this > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > > > present it > > > > > > > > > has build-time effects and this is quite wrong. If you go > > > > through all > > > > > > > > > the material I have written on this I think I have motivated > > > > that very > > > > > > > > > clearly. > > > > > > > > > > > > > > > > > > Another big issue is that I believe we need ONE devicetree > > for > > > > U-Boot, > > > > > > > > > not two that get merged by U-Boot. Again I have gone through > > > > that in a > > > > > > > > > lot of detail. > > > > > > > > > > > > > > > > I have a long long reply to your first reply here saved, but, > > maybe > > > > > > > > here's the biggest sticking point. To be clear, you agree that > > > > U-Boot > > > > > > > > needs to support being passed a device tree to use, at run > > time, > > > > yes? > > > > > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we built > > in? > > > > > > > > > > > > > > Not at runtime. > > > > > > > > > > > > OK. > > > > > > > > > > > > > > So is the sticking point here that we really have two classes > > of > > > > > > > > devices, one class where we will never ever be given the device > > > > tree at > > > > > > > > run time (think BeagleBone Black) and one where we will always > > be > > > > given > > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect there > > will be > > > > > > > (many) boards which can boot happily with the U-Boot devicetree > > but > > > > > > > can also accept one at runtime, if provided. For example, you may > > > > want > > > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > > > > > I'm not sure I see the value in making this a gray area. There's > > very > > > > > > much a class of "never" boards. There's also the class of "can" > > today. > > > > > > Maybe as part of a developer iterative flow it would be nice to not > > > > have > > > > > > to re-flash the prior stage to change a DT, and just do it in > > U-Boot > > > > > > until things are happy, but I'm not sure what the use case is for > > > > > > overriding the previous stage. > > > > > > > > > > > > Especially since the pushback on this series I think has all been > > "why > > > > > > are we copying in a tree to build with? We don't want to use it > > at run > > > > > > time!". And then softer push back like "Well, U-Boot says we have > > to > > > > > > include the device tree file here, but we won't use it...". > > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > > > inadvertently) > > > > > > > provided a way to entirely omit a devicetree from U-Boot, thus > > making > > > > > > > things like binman and U-Boot /config impossible, for example. > > So I > > > > > > > want to claw that back, so there is always some sort of > > devicetree in > > > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > > > > > I really want to see what the binary case looks like since we could > > > > then > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > > could > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > > don't > > > > > > use the device tree from build time at run time, ignoring the > > device > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > confusing these days. Lots of things to build and it's hard to find > > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > > as we are, it will continue to be messy and in five years you will > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > objective here is to simplify things, bringing some consistency to > > the > > > > > different components. Binman was one effort there. I feel that > > putting > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > 2011), is the next step. > > > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > > > > that know where to grab other known-good binaries of varying licenses > > > > that are needed to assemble something that boots. > > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > > can be the unifying configuration mechanism through the whole of > > > > > firmware (except for very early bits) and into the OS, this will set > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the > > past > > > > > two months: > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > > have its own nodes/properties in the DT. > > > > > > In my view U-Boot shall be able to leverage device tree format (source > > and > > > binary) to store its own data. > > > When you say "the" DT, I always think this is "the" DT that is passed to > > OS > > > and in "that" DT, there should be no U-Boot entries. > > > > Why not? As long as the device tree validates, it is perfectly fine > > to have additional nodes and properties present. The propertiesand > > nodes will be simply ignored by the OS. > > Because of the way we want to organize the firmware supply chain: when the > board is built, it is "attached" a device tree. > At that moment, we don't know what "non trusted firmware" will be used. It > could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2 (yes > it works with DT). > And we aim at keeping device tree as close to the original intent: hardware > description only. It's not because we can stuff anything in the DT and that > it is simple to do that we should. > Driver parameters shall be in the OS facility built for that purpose. Using > device tree has been an ugly habit. So we're going to continue to re-litigate what does and doesn't live in the device tree for forever, aren't we? To continue to be clear, I'm not saying that non-upstream bindings should be present. But for example, Simon is working on the "U-Boot config node" binding, which is going to get re-spun next as /options/ as I read the thread right. Populate it and anyone can read it, and probably be getting information that's useful to U-Boot or LinuxBoot or EDK2 or anyone else. That's why I keep repeating that projects need to push bindings upstream. I'll repeat my comment about https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html and the binman node both noting a common problem to solve. In so far as there's objections to "U-Boot" nodes, it seems to me like it comes down to "shouldn't need U-Boot internals expressed in DT nor added to the DTB by someone else". And I've not objected to that either. But I think we do have a subset of "how do we express ..." issues that have come down to "well, we buried the bodies over at ... before". And it's time to dig them up and give them a proper burial perhaps now :) -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 19:06 ` Tom Rini @ 2021-10-27 22:00 ` François Ozog 2021-10-28 14:41 ` Tom Rini 0 siblings, 1 reply; 73+ messages in thread From: François Ozog @ 2021-10-27 22:00 UTC (permalink / raw) To: Tom Rini Cc: liviu.dudau, narmstrong, rick, vladimir.oltean, linus.walleij, fitzsim, kever.yang, seanga2, atish.patra, zong.li, sr, festevam, rainer.boschung, Mark Kettenis, swarren, oleksandr_andrushchenko, xypron.glpk, lusus, michal.simek, marek.behun, vanbaren, rfried.dev, jagan, valentin.longchamp, hs, pbrobinson, sinan, bin.meng, wd, swarren, andre.przywara, tharvey, ashok.reddy.soma, qemu-devel, agraf, green.wan, t.karthik.reddy, anastasiia_lukianenko, albert.u.boot, monstr, mbrugger, ycliang, kristo, u-boot, david.abdurachmanov, priyanka.jain, sjg, ilias.apalodimas, christianshewitt, awilliams, tuomas.tynkkynen, heinrich.schuchardt, tianrui-wei, bmeng.cn, pali, dimitri.ledkov, padmarao.begari [-- Attachment #1: Type: text/plain, Size: 19713 bytes --] Hi Tom Le mer. 27 oct. 2021 à 21:06, Tom Rini <trini@konsulko.com> a écrit : > On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote: > > Hi Mark, > > > > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl> > wrote: > > > > > > From: François Ozog <francois.ozog@linaro.org> > > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > > > Hi, > > > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > > Hi all, > > > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> > wrote: > > > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> > > > wrote: > > > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass > wrote: > > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > > > sjg@chromium.org> > > > > > a écrit : > > > > > > > > > > >> > > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > > >> > > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > > > trini@konsulko.com> > > > > > wrote: > > > > > > > > > > >> > > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > > > wrote: > > > > > > > > > > >> > > Hi Simon, > > > > > > > > > > >> > > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > 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 > at > > > [1]. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > 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. > > > > > > > > > > >> > > > > > > > > > > > > >> > > Adding device trees that are never used sounds > like a > > > > > hack to me. > > > > > > > > > > >> > > > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on > the > > > fly > > > > > based on > > > > > > > > > > >> > > command line parameters, and the device tree you > put > > > in > > > > > this series > > > > > > > > > > >> > > has various hardcoded <phandle> values which > normally > > > do > > > > > not show up > > > > > > > > > > >> > > in hand-written dts files. > > > > > > > > > > >> > > > > > > > > > > > > >> > > I am not sure I understand the whole point of > this. > > > > > > > > > > >> > > > > > > > > > > > >> > I am also confused and do not like the idea of > adding > > > > > device trees for > > > > > > > > > > >> > platforms that are capable of and can / do have a > device > > > > > tree to give us > > > > > > > > > > >> > at run time. > > > > > > > > > > >> > > > > > > > > > > >> (I'll just reply to this one email, since the same > points > > > > > applies to > > > > > > > > > > >> all replies I think) > > > > > > > > > > >> > > > > > > > > > > >> I have been thinking about this and discussing it with > > > people > > > > > for a > > > > > > > > > > >> few months now. I've been signalling a change like > this > > > for > > > > > over a > > > > > > > > > > >> month now, on U-Boot contributor calls and in > discussions > > > > > with Linaro > > > > > > > > > > >> people. I sent a patch (below) to try to explain > things. I > > > > > hope it is > > > > > > > > > > >> not a surprise! > > > > > > > > > > >> > > > > > > > > > > >> The issue here is that we need a devicetree in-tree in > > > > > U-Boot, to > > > > > > > > > > >> avoid the mess that has been created by > OF_PRIOR_STAGE, > > > > > OF_BOARD, > > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, > OF_HOSTFILE. > > > > > Between > > > > > > > > > > >> Ilias' series and this one we can get ourselves on a > > > stronger > > > > > footing. > > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for > debugging/ELF > > > > > use. > > > > > > > > > > >> For more context: > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > >> > > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way > of > > > > > adding the > > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in > > > fact the > > > > > > > > > > >> maintainer would prefer there was no special support > even > > > for > > > > > booting > > > > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > > > > >> > > > > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > > > > >> think the path forward might be to run QEMU twice, > once to > > > > > get its > > > > > > > > > > >> generated tree and once to give the 'merged' tree > with the > > > > > U-Boot > > > > > > > > > > >> properties in it, if people want to use U-Boot > features. > > > > > > > > > > >> > > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > > > > option, not a > > > > > > > > > > >> build-time one. It creates all sorts of problems and > > > > > obscurity which > > > > > > > > > > >> have taken months to unpick. See the above patch for > the > > > > > rationale. > > > > > > > > > > >> > > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an > option > > > > > available to > > > > > > > > > > >> any board. At some point in the future it may become a > > > common > > > > > way > > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and > providing a > > > > > devicetree > > > > > > > > > > >> to it. It doesn't make any sense to have people decide > > > > > whether or not > > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the > > > image > > > > > is put > > > > > > > > > > >> together. We'll end up with different U-Boot build > targets > > > > > like > > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should > be > > > > > obvious where > > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a > > > commonly > > > > > used > > > > > > > > > > >> option, perhaps enabled by most/all boards, so that > this > > > sort > > > > > of build > > > > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > > > > > > > If you mean that when boards are by construction > providing > > > a > > > > > DTB to U-Boot then I agree very much. But I don’t understand how > the > > > patch > > > > > set supports it as it puts dts files for those boards to be built. > > > > > > > > > > >> > > > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > > > >> function correctly in whatever runtime environment in > > > which > > > > > it finds > > > > > > > > > > >> itself. > > > > > > > > > > >> > > > > > > > > > > >> Also as binman is pressed into service more and more > to > > > build > > > > > the > > > > > > > > > > >> complex firmware images that are becoming > fashionable, it > > > > > needs a > > > > > > > > > > >> definition (in the devicetree) that describes how to > > > create > > > > > the image. > > > > > > > > > > >> We can't support that unless we are building a > devicetree, > > > > > nor can the > > > > > > > > > > >> running program access the image layout without that > > > > > information. > > > > > > > > > > >> > > > > > > > > > > >> François's point about 'don't use this with any > kernel' is > > > > > > > > > > >> germane...but of course I am not suggesting doing > that, > > > since > > > > > OF_BOARD > > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for > various > > > > > boards that > > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and > 3, > > > for > > > > > example > > > > > > > > > > >> (as I said in the cover letter "Most boards do provide > > > one, > > > > > but some > > > > > > > > > > >> don't."). So this series is just completing the > picture by > > > > > enforcing > > > > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the > > > default. > > > > > > > > > > > > > > > > > > > > I think the key point that will get you closer to where > I am > > > on > > > > > this > > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > > > > present it > > > > > > > > > > has build-time effects and this is quite wrong. If you go > > > > > through all > > > > > > > > > > the material I have written on this I think I have > motivated > > > > > that very > > > > > > > > > > clearly. > > > > > > > > > > > > > > > > > > > > Another big issue is that I believe we need ONE > devicetree > > > for > > > > > U-Boot, > > > > > > > > > > not two that get merged by U-Boot. Again I have gone > through > > > > > that in a > > > > > > > > > > lot of detail. > > > > > > > > > > > > > > > > > > I have a long long reply to your first reply here saved, > but, > > > maybe > > > > > > > > > here's the biggest sticking point. To be clear, you agree > that > > > > > U-Boot > > > > > > > > > needs to support being passed a device tree to use, at run > > > time, > > > > > yes? > > > > > > > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we > built > > > in? > > > > > > > > > > > > > > > > Not at runtime. > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > So is the sticking point here that we really have two > classes > > > of > > > > > > > > > devices, one class where we will never ever be given the > device > > > > > tree at > > > > > > > > > run time (think BeagleBone Black) and one where we will > always > > > be > > > > > given > > > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect there > > > will be > > > > > > > > (many) boards which can boot happily with the U-Boot > devicetree > > > but > > > > > > > > can also accept one at runtime, if provided. For example, > you may > > > > > want > > > > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > > > > > > > I'm not sure I see the value in making this a gray area. > There's > > > very > > > > > > > much a class of "never" boards. There's also the class of > "can" > > > today. > > > > > > > Maybe as part of a developer iterative flow it would be nice > to not > > > > > have > > > > > > > to re-flash the prior stage to change a DT, and just do it in > > > U-Boot > > > > > > > until things are happy, but I'm not sure what the use case is > for > > > > > > > overriding the previous stage. > > > > > > > > > > > > > > Especially since the pushback on this series I think has all > been > > > "why > > > > > > > are we copying in a tree to build with? We don't want to use > it > > > at run > > > > > > > time!". And then softer push back like "Well, U-Boot says we > have > > > to > > > > > > > include the device tree file here, but we won't use it...". > > > > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > > > > inadvertently) > > > > > > > > provided a way to entirely omit a devicetree from U-Boot, > thus > > > making > > > > > > > > things like binman and U-Boot /config impossible, for > example. > > > So I > > > > > > > > want to claw that back, so there is always some sort of > > > devicetree in > > > > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > > > > > > > I really want to see what the binary case looks like since we > could > > > > > then > > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > > > could > > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can > come > > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we > also > > > don't > > > > > > > use the device tree from build time at run time, ignoring the > > > device > > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > > confusing these days. Lots of things to build and it's hard to > find > > > > > > the instructions. It doesn't have to be that way, but if we > carry on > > > > > > as we are, it will continue to be messy and in five years you > will > > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > > objective here is to simplify things, bringing some consistency > to > > > the > > > > > > different components. Binman was one effort there. I feel that > > > putting > > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > > 2011), is the next step. > > > > > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh > scripts > > > > > that know where to grab other known-good binaries of varying > licenses > > > > > that are needed to assemble something that boots. > > > > > > > > > > > If we set things up correctly and agree on the bindings, > devicetree > > > > > > can be the unifying configuration mechanism through the whole of > > > > > > firmware (except for very early bits) and into the OS, this will > set > > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the > > > past > > > > > > two months: > > > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed > to > > > > > > have its own nodes/properties in the DT. > > > > > > > > In my view U-Boot shall be able to leverage device tree format > (source > > > and > > > > binary) to store its own data. > > > > When you say "the" DT, I always think this is "the" DT that is > passed to > > > OS > > > > and in "that" DT, there should be no U-Boot entries. > > > > > > Why not? As long as the device tree validates, it is perfectly fine > > > to have additional nodes and properties present. The propertiesand > > > nodes will be simply ignored by the OS. > > > > Because of the way we want to organize the firmware supply chain: when > the > > board is built, it is "attached" a device tree. > > At that moment, we don't know what "non trusted firmware" will be used. > It > > could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2 > (yes > > it works with DT). > > And we aim at keeping device tree as close to the original intent: > hardware > > description only. It's not because we can stuff anything in the DT and > that > > it is simple to do that we should. > > Driver parameters shall be in the OS facility built for that purpose. > Using > > device tree has been an ugly habit. > > So we're going to continue to re-litigate what does and doesn't live in > the device tree for forever, aren't we? To continue to be clear, I'm > not saying that non-upstream bindings should be present. But for > example, Simon is working on the "U-Boot config node" binding, which is > going to get re-spun next as /options/ as I read the thread right. > Populate it and anyone can read it, and probably be getting information > that's useful to U-Boot or LinuxBoot or EDK2 or anyone else. That's why > I keep repeating that projects need to push bindings upstream. I'll > repeat my comment about > > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html > and the binman node both noting a common problem to solve. i think you are right. Now tfa is comfortable being its own upstream for the binding specifications. Could U-Boot community be comfortable doing so? Now I also recognize that DT specification state is far from clean. If you want full story on PCI ECAM you need Linux/documentation and IEEE text (kind of hosted on DT.org but not easily browasable to). In the long run it may be much better to have all bindings (including U-Boot ones) in DT.org. We should also have information from Qemu about the DT it generates for all its devices and how it is associated to command line . > > > In so far as there's objections to "U-Boot" nodes, it seems to me like > it comes down to "shouldn't need U-Boot internals expressed in DT nor > added to the DTB by someone else". And I've not objected to that > either. But I think we do have a subset of "how do we express ..." > issues that have come down to "well, we buried the bodies over at ... > before". And it's time to dig them up and give them a proper burial > perhaps now :) > > -- > Tom > -- 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: 31166 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-27 22:00 ` François Ozog @ 2021-10-28 14:41 ` Tom Rini 0 siblings, 0 replies; 73+ messages in thread From: Tom Rini @ 2021-10-28 14:41 UTC (permalink / raw) To: François Ozog Cc: liviu.dudau, narmstrong, rick, vladimir.oltean, linus.walleij, fitzsim, kever.yang, seanga2, atish.patra, zong.li, sr, festevam, rainer.boschung, Mark Kettenis, swarren, oleksandr_andrushchenko, xypron.glpk, lusus, michal.simek, marek.behun, vanbaren, rfried.dev, jagan, valentin.longchamp, hs, pbrobinson, sinan, bin.meng, wd, swarren, andre.przywara, tharvey, ashok.reddy.soma, qemu-devel, agraf, green.wan, t.karthik.reddy, anastasiia_lukianenko, albert.u.boot, monstr, mbrugger, ycliang, kristo, u-boot, david.abdurachmanov, priyanka.jain, sjg, ilias.apalodimas, christianshewitt, awilliams, tuomas.tynkkynen, heinrich.schuchardt, tianrui-wei, bmeng.cn, pali, dimitri.ledkov, padmarao.begari [-- Attachment #1: Type: text/plain, Size: 19928 bytes --] On Thu, Oct 28, 2021 at 12:00:44AM +0200, François Ozog wrote: > Hi Tom > > Le mer. 27 oct. 2021 à 21:06, Tom Rini <trini@konsulko.com> a écrit : > > > On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote: > > > Hi Mark, > > > > > > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl> > > wrote: > > > > > > > > From: François Ozog <francois.ozog@linaro.org> > > > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > > > > > Hi, > > > > > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> > > wrote: > > > > > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass > > wrote: > > > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > > > > sjg@chromium.org> > > > > > > a écrit : > > > > > > > > > > > >> > > > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > > > >> > > > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > > > > trini@konsulko.com> > > > > > > wrote: > > > > > > > > > > > >> > > > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > > > > wrote: > > > > > > > > > > > >> > > Hi Simon, > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > 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 > > at > > > > [1]. > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > 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. > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > Adding device trees that are never used sounds > > like a > > > > > > hack to me. > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on > > the > > > > fly > > > > > > based on > > > > > > > > > > > >> > > command line parameters, and the device tree you > > put > > > > in > > > > > > this series > > > > > > > > > > > >> > > has various hardcoded <phandle> values which > > normally > > > > do > > > > > > not show up > > > > > > > > > > > >> > > in hand-written dts files. > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > I am not sure I understand the whole point of > > this. > > > > > > > > > > > >> > > > > > > > > > > > > >> > I am also confused and do not like the idea of > > adding > > > > > > device trees for > > > > > > > > > > > >> > platforms that are capable of and can / do have a > > device > > > > > > tree to give us > > > > > > > > > > > >> > at run time. > > > > > > > > > > > >> > > > > > > > > > > > >> (I'll just reply to this one email, since the same > > points > > > > > > applies to > > > > > > > > > > > >> all replies I think) > > > > > > > > > > > >> > > > > > > > > > > > >> I have been thinking about this and discussing it with > > > > people > > > > > > for a > > > > > > > > > > > >> few months now. I've been signalling a change like > > this > > > > for > > > > > > over a > > > > > > > > > > > >> month now, on U-Boot contributor calls and in > > discussions > > > > > > with Linaro > > > > > > > > > > > >> people. I sent a patch (below) to try to explain > > things. I > > > > > > hope it is > > > > > > > > > > > >> not a surprise! > > > > > > > > > > > >> > > > > > > > > > > > >> The issue here is that we need a devicetree in-tree in > > > > > > U-Boot, to > > > > > > > > > > > >> avoid the mess that has been created by > > OF_PRIOR_STAGE, > > > > > > OF_BOARD, > > > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, > > OF_HOSTFILE. > > > > > > Between > > > > > > > > > > > >> Ilias' series and this one we can get ourselves on a > > > > stronger > > > > > > footing. > > > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for > > debugging/ELF > > > > > > use. > > > > > > > > > > > >> For more context: > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > >> > > > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way > > of > > > > > > adding the > > > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in > > > > fact the > > > > > > > > > > > >> maintainer would prefer there was no special support > > even > > > > for > > > > > > booting > > > > > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > > > > > >> > > > > > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > > > > > >> think the path forward might be to run QEMU twice, > > once to > > > > > > get its > > > > > > > > > > > >> generated tree and once to give the 'merged' tree > > with the > > > > > > U-Boot > > > > > > > > > > > >> properties in it, if people want to use U-Boot > > features. > > > > > > > > > > > >> > > > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > > > > > option, not a > > > > > > > > > > > >> build-time one. It creates all sorts of problems and > > > > > > obscurity which > > > > > > > > > > > >> have taken months to unpick. See the above patch for > > the > > > > > > rationale. > > > > > > > > > > > >> > > > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an > > option > > > > > > available to > > > > > > > > > > > >> any board. At some point in the future it may become a > > > > common > > > > > > way > > > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and > > providing a > > > > > > devicetree > > > > > > > > > > > >> to it. It doesn't make any sense to have people decide > > > > > > whether or not > > > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the > > > > image > > > > > > is put > > > > > > > > > > > >> together. We'll end up with different U-Boot build > > targets > > > > > > like > > > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should > > be > > > > > > obvious where > > > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a > > > > commonly > > > > > > used > > > > > > > > > > > >> option, perhaps enabled by most/all boards, so that > > this > > > > sort > > > > > > of build > > > > > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > > > > > > > > > If you mean that when boards are by construction > > providing > > > > a > > > > > > DTB to U-Boot then I agree very much. But I don’t understand how > > the > > > > patch > > > > > > set supports it as it puts dts files for those boards to be built. > > > > > > > > > > > >> > > > > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > > > > >> function correctly in whatever runtime environment in > > > > which > > > > > > it finds > > > > > > > > > > > >> itself. > > > > > > > > > > > >> > > > > > > > > > > > >> Also as binman is pressed into service more and more > > to > > > > build > > > > > > the > > > > > > > > > > > >> complex firmware images that are becoming > > fashionable, it > > > > > > needs a > > > > > > > > > > > >> definition (in the devicetree) that describes how to > > > > create > > > > > > the image. > > > > > > > > > > > >> We can't support that unless we are building a > > devicetree, > > > > > > nor can the > > > > > > > > > > > >> running program access the image layout without that > > > > > > information. > > > > > > > > > > > >> > > > > > > > > > > > >> François's point about 'don't use this with any > > kernel' is > > > > > > > > > > > >> germane...but of course I am not suggesting doing > > that, > > > > since > > > > > > OF_BOARD > > > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for > > various > > > > > > boards that > > > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and > > 3, > > > > for > > > > > > example > > > > > > > > > > > >> (as I said in the cover letter "Most boards do provide > > > > one, > > > > > > but some > > > > > > > > > > > >> don't."). So this series is just completing the > > picture by > > > > > > enforcing > > > > > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the > > > > default. > > > > > > > > > > > > > > > > > > > > > > I think the key point that will get you closer to where > > I am > > > > on > > > > > > this > > > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > > > > > present it > > > > > > > > > > > has build-time effects and this is quite wrong. If you go > > > > > > through all > > > > > > > > > > > the material I have written on this I think I have > > motivated > > > > > > that very > > > > > > > > > > > clearly. > > > > > > > > > > > > > > > > > > > > > > Another big issue is that I believe we need ONE > > devicetree > > > > for > > > > > > U-Boot, > > > > > > > > > > > not two that get merged by U-Boot. Again I have gone > > through > > > > > > that in a > > > > > > > > > > > lot of detail. > > > > > > > > > > > > > > > > > > > > I have a long long reply to your first reply here saved, > > but, > > > > maybe > > > > > > > > > > here's the biggest sticking point. To be clear, you agree > > that > > > > > > U-Boot > > > > > > > > > > needs to support being passed a device tree to use, at run > > > > time, > > > > > > yes? > > > > > > > > > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we > > built > > > > in? > > > > > > > > > > > > > > > > > > Not at runtime. > > > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > > > So is the sticking point here that we really have two > > classes > > > > of > > > > > > > > > > devices, one class where we will never ever be given the > > device > > > > > > tree at > > > > > > > > > > run time (think BeagleBone Black) and one where we will > > always > > > > be > > > > > > given > > > > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect there > > > > will be > > > > > > > > > (many) boards which can boot happily with the U-Boot > > devicetree > > > > but > > > > > > > > > can also accept one at runtime, if provided. For example, > > you may > > > > > > want > > > > > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > > > > > > > > > I'm not sure I see the value in making this a gray area. > > There's > > > > very > > > > > > > > much a class of "never" boards. There's also the class of > > "can" > > > > today. > > > > > > > > Maybe as part of a developer iterative flow it would be nice > > to not > > > > > > have > > > > > > > > to re-flash the prior stage to change a DT, and just do it in > > > > U-Boot > > > > > > > > until things are happy, but I'm not sure what the use case is > > for > > > > > > > > overriding the previous stage. > > > > > > > > > > > > > > > > Especially since the pushback on this series I think has all > > been > > > > "why > > > > > > > > are we copying in a tree to build with? We don't want to use > > it > > > > at run > > > > > > > > time!". And then softer push back like "Well, U-Boot says we > > have > > > > to > > > > > > > > include the device tree file here, but we won't use it...". > > > > > > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > > > > > inadvertently) > > > > > > > > > provided a way to entirely omit a devicetree from U-Boot, > > thus > > > > making > > > > > > > > > things like binman and U-Boot /config impossible, for > > example. > > > > So I > > > > > > > > > want to claw that back, so there is always some sort of > > > > devicetree in > > > > > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > > > > > > > > > I really want to see what the binary case looks like since we > > could > > > > > > then > > > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > > > > could > > > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can > > come > > > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we > > also > > > > don't > > > > > > > > use the device tree from build time at run time, ignoring the > > > > device > > > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > > > confusing these days. Lots of things to build and it's hard to > > find > > > > > > > the instructions. It doesn't have to be that way, but if we > > carry on > > > > > > > as we are, it will continue to be messy and in five years you > > will > > > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > > > objective here is to simplify things, bringing some consistency > > to > > > > the > > > > > > > different components. Binman was one effort there. I feel that > > > > putting > > > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > > > 2011), is the next step. > > > > > > > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh > > scripts > > > > > > that know where to grab other known-good binaries of varying > > licenses > > > > > > that are needed to assemble something that boots. > > > > > > > > > > > > > If we set things up correctly and agree on the bindings, > > devicetree > > > > > > > can be the unifying configuration mechanism through the whole of > > > > > > > firmware (except for very early bits) and into the OS, this will > > set > > > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the > > > > past > > > > > > > two months: > > > > > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed > > to > > > > > > > have its own nodes/properties in the DT. > > > > > > > > > > In my view U-Boot shall be able to leverage device tree format > > (source > > > > and > > > > > binary) to store its own data. > > > > > When you say "the" DT, I always think this is "the" DT that is > > passed to > > > > OS > > > > > and in "that" DT, there should be no U-Boot entries. > > > > > > > > Why not? As long as the device tree validates, it is perfectly fine > > > > to have additional nodes and properties present. The propertiesand > > > > nodes will be simply ignored by the OS. > > > > > > Because of the way we want to organize the firmware supply chain: when > > the > > > board is built, it is "attached" a device tree. > > > At that moment, we don't know what "non trusted firmware" will be used. > > It > > > could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2 > > (yes > > > it works with DT). > > > And we aim at keeping device tree as close to the original intent: > > hardware > > > description only. It's not because we can stuff anything in the DT and > > that > > > it is simple to do that we should. > > > Driver parameters shall be in the OS facility built for that purpose. > > Using > > > device tree has been an ugly habit. > > > > So we're going to continue to re-litigate what does and doesn't live in > > the device tree for forever, aren't we? To continue to be clear, I'm > > not saying that non-upstream bindings should be present. But for > > example, Simon is working on the "U-Boot config node" binding, which is > > going to get re-spun next as /options/ as I read the thread right. > > Populate it and anyone can read it, and probably be getting information > > that's useful to U-Boot or LinuxBoot or EDK2 or anyone else. That's why > > I keep repeating that projects need to push bindings upstream. I'll > > repeat my comment about > > > > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html > > and the binman node both noting a common problem to solve. > > i think you are right. Now tfa is comfortable being its own upstream for > the binding specifications. Could U-Boot community be comfortable doing so? Well, since we need to and are trying to solve the same problem, why should we duplicate efforts? This is something that should be common and upstream is my point. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-14 15:17 ` Simon Glass 2021-10-14 15:28 ` Tom Rini @ 2021-10-14 16:24 ` Andre Przywara 2021-10-14 17:48 ` François Ozog 1 sibling, 1 reply; 73+ messages in thread From: Andre Przywara @ 2021-10-14 16:24 UTC (permalink / raw) To: Simon Glass Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stephen Warren, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, François Ozog, qemu-devel@nongnu.org Developers, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari On Thu, 14 Oct 2021 09:17:52 -0600 Simon Glass <sjg@chromium.org> wrote: > Hi Tom, > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > Hi François, > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > Hi Simon > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > > > >> > > > >> Hi Tom, Bin,François, > > > >> > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > > > >> > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > >> > > Hi Simon, > > > >> > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > >> > > > > > > >> > > > 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 at [1]. > > > >> > > > > > > >> > > > 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. > > > >> > > > > > >> > > Adding device trees that are never used sounds like a hack to me. > > > >> > > > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > > > >> > > command line parameters, and the device tree you put in this series > > > >> > > has various hardcoded <phandle> values which normally do not show up > > > >> > > in hand-written dts files. > > > >> > > > > > >> > > I am not sure I understand the whole point of this. > > > >> > > > > >> > I am also confused and do not like the idea of adding device trees for > > > >> > platforms that are capable of and can / do have a device tree to give us > > > >> > at run time. > > > >> > > > >> (I'll just reply to this one email, since the same points applies to > > > >> all replies I think) > > > >> > > > >> I have been thinking about this and discussing it with people for a > > > >> few months now. I've been signalling a change like this for over a > > > >> month now, on U-Boot contributor calls and in discussions with Linaro > > > >> people. I sent a patch (below) to try to explain things. I hope it is > > > >> not a surprise! > > > >> > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > > > >> Ilias' series and this one we can get ourselves on a stronger footing. > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > > > >> For more context: > > > >> > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > >> > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > >> maintainer would prefer there was no special support even for booting > > > >> Linux directly!) > > > > > > > > i understand their point of view and agree with it. > > > >> > > > >> But in any case it doesn't really help U-Boot. I > > > >> think the path forward might be to run QEMU twice, once to get its > > > >> generated tree and once to give the 'merged' tree with the U-Boot > > > >> properties in it, if people want to use U-Boot features. > > > >> > > > >> I do strongly believe that OF_BOARD must be a run-time option, not a > > > >> build-time one. It creates all sorts of problems and obscurity which > > > >> have taken months to unpick. See the above patch for the rationale. > > > >> > > > >> To add to that rationale, OF_BOARD needs to be an option available to > > > >> any board. At some point in the future it may become a common way > > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree > > > >> to it. It doesn't make any sense to have people decide whether or not > > > >> to set OF_BOARD at build time, thus affecting how the image is put > > > >> together. We'll end up with different U-Boot build targets like > > > >> capricorn, capricorn_of_board and the like. It should be obvious where > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used > > > >> option, perhaps enabled by most/all boards, so that this sort of build > > > >> explosion is not needed. > > > > > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. > > > >> > > > >> U-Boot needs to be flexible enough to > > > >> function correctly in whatever runtime environment in which it finds > > > >> itself. > > > >> > > > >> Also as binman is pressed into service more and more to build the > > > >> complex firmware images that are becoming fashionable, it needs a > > > >> definition (in the devicetree) that describes how to create the image. > > > >> We can't support that unless we are building a devicetree, nor can the > > > >> running program access the image layout without that information. > > > >> > > > >> François's point about 'don't use this with any kernel' is > > > >> germane...but of course I am not suggesting doing that, since OF_BOARD > > > >> is, still, enabled. We already use OF_BOARD for various boards that > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > > > >> (as I said in the cover letter "Most boards do provide one, but some > > > >> don't."). So this series is just completing the picture by enforcing > > > >> that *some sort* of devicetree is always present. > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > I think the key point that will get you closer to where I am on this > > > issue, is that OF_BOARD needs to be a run-time option. At present it > > > has build-time effects and this is quite wrong. If you go through all > > > the material I have written on this I think I have motivated that very > > > clearly. > > > > > > Another big issue is that I believe we need ONE devicetree for U-Boot, > > > not two that get merged by U-Boot. Again I have gone through that in a > > > lot of detail. > > > > I have a long long reply to your first reply here saved, but, maybe > > here's the biggest sticking point. To be clear, you agree that U-Boot > > needs to support being passed a device tree to use, at run time, yes? > > Yes. The OF_BOARD feature provides this. > > > > > And in that case, would not be using the "fake" tree we built in? > > Not at runtime. > > > > > So is the sticking point here that we really have two classes of > > devices, one class where we will never ever be given the device tree at > > run time (think BeagleBone Black) and one where we will always be given > > one at run time (think Raspberry Pi) ? > > I'm not sure it will be that black and white. I suspect there will be > (many) boards which can boot happily with the U-Boot devicetree but > can also accept one at runtime, if provided. For example, you may want > to boot with or without TF-A or some other, earlier stage. I don't understand this: as Tom mentioned this is a platform decision: either it provides a DT somewhere (flash, EEPROM, prior firmware stage), or it doesn't. Sure, you can always hack your own DT in, somehow, for development or experimentation purposes, but that is a separate issue. Most of those platforms actually utilise some dynamic DTs, btw, where software amends the DT on the fly: - Highbank has a stub DT in SPI flash, and the management controller firmware detects the size and some extra DRAM (DIMMs!) parameters at boot time, and writes the /memory node accordingly. - RPi3/4 have DT overlay files on the SD card, and depending on what a user wrote in config.txt, they get applied to the DT (or not). - Even for the Allwinner H616 we amend the OF_SEPARATE provided DT copy in DRAM in TF-A, to carve out the DRAM region TF-A occupies. - QEMU is the obvious example, where the whole machine is highly dynamic, and there is no such thing as a fixed DT (how many cores?, how much memory?, how many virtio devices?, flash?, SCSI?) > I believe we have got unstuck because OF_BOARD (perhaps inadvertently) > provided a way to entirely omit a devicetree from U-Boot, thus making > things like binman and U-Boot /config impossible, for example. I have the feeling this is because we abuse DT for this. Conceptually the DT is not a configuration file, but a hardware description. I see that it is also a nice and flexible, hierarchical key/value storage, for which we have code in anyway, so it makes hardcoding data in the code easier to avoid. But as we see now, this has problems as well. So shall we separate those use cases? And attach just a tree with /binman and /config (in DTB format), but treat this separately from the hardware description? (Admittedly I have still to wrap my head around why we need /binman at U-Boot runtime in the first place.) Cheers, Andre > So I > want to claw that back, so there is always some sort of devicetree in > U-Boot, as we have for rpi_3, etc. > > Regards, > Simon ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-14 16:24 ` Andre Przywara @ 2021-10-14 17:48 ` François Ozog 0 siblings, 0 replies; 73+ messages in thread From: François Ozog @ 2021-10-14 17:48 UTC (permalink / raw) To: Andre Przywara Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 11468 bytes --] Le jeu. 14 oct. 2021 à 18:24, Andre Przywara <andre.przywara@arm.com> a écrit : > On Thu, 14 Oct 2021 09:17:52 -0600 > Simon Glass <sjg@chromium.org> wrote: > > > Hi Tom, > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > Hi François, > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > francois.ozog@linaro.org> wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a > écrit : > > > > >> > > > > >> Hi Tom, Bin,François, > > > > >> > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> > wrote: > > > > >> > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > >> > > Hi Simon, > > > > >> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > > > > >> > > > > > > > >> > > > 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 at [1]. > > > > >> > > > > > > > >> > > > 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. > > > > >> > > > > > > >> > > Adding device trees that are never used sounds like a hack to > me. > > > > >> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > based on > > > > >> > > command line parameters, and the device tree you put in this > series > > > > >> > > has various hardcoded <phandle> values which normally do not > show up > > > > >> > > in hand-written dts files. > > > > >> > > > > > > >> > > I am not sure I understand the whole point of this. > > > > >> > > > > > >> > I am also confused and do not like the idea of adding device > trees for > > > > >> > platforms that are capable of and can / do have a device tree > to give us > > > > >> > at run time. > > > > >> > > > > >> (I'll just reply to this one email, since the same points applies > to > > > > >> all replies I think) > > > > >> > > > > >> I have been thinking about this and discussing it with people for > a > > > > >> few months now. I've been signalling a change like this for over a > > > > >> month now, on U-Boot contributor calls and in discussions with > Linaro > > > > >> people. I sent a patch (below) to try to explain things. I hope > it is > > > > >> not a surprise! > > > > >> > > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > > > > >> Ilias' series and this one we can get ourselves on a stronger > footing. > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > > > > >> For more context: > > > > >> > > > > >> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > >> > > > > >> BTW I did suggest to QEMU ARM that they support a way of adding > the > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > >> maintainer would prefer there was no special support even for > booting > > > > >> Linux directly!) > > > > > > > > > > i understand their point of view and agree with it. > > > > >> > > > > >> But in any case it doesn't really help U-Boot. I > > > > >> think the path forward might be to run QEMU twice, once to get its > > > > >> generated tree and once to give the 'merged' tree with the U-Boot > > > > >> properties in it, if people want to use U-Boot features. > > > > >> > > > > >> I do strongly believe that OF_BOARD must be a run-time option, > not a > > > > >> build-time one. It creates all sorts of problems and obscurity > which > > > > >> have taken months to unpick. See the above patch for the > rationale. > > > > >> > > > > >> To add to that rationale, OF_BOARD needs to be an option > available to > > > > >> any board. At some point in the future it may become a common way > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > devicetree > > > > >> to it. It doesn't make any sense to have people decide whether or > not > > > > >> to set OF_BOARD at build time, thus affecting how the image is put > > > > >> together. We'll end up with different U-Boot build targets like > > > > >> capricorn, capricorn_of_board and the like. It should be obvious > where > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used > > > > >> option, perhaps enabled by most/all boards, so that this sort of > build > > > > >> explosion is not needed. > > > > > > > > > > If you mean that when boards are by construction providing a DTB > to U-Boot then I agree very much. But I don’t understand how the patch set > supports it as it puts dts files for those boards to be built. > > > > >> > > > > >> U-Boot needs to be flexible enough to > > > > >> function correctly in whatever runtime environment in which it > finds > > > > >> itself. > > > > >> > > > > >> Also as binman is pressed into service more and more to build the > > > > >> complex firmware images that are becoming fashionable, it needs a > > > > >> definition (in the devicetree) that describes how to create the > image. > > > > >> We can't support that unless we are building a devicetree, nor > can the > > > > >> running program access the image layout without that information. > > > > >> > > > > >> François's point about 'don't use this with any kernel' is > > > > >> germane...but of course I am not suggesting doing that, since > OF_BOARD > > > > >> is, still, enabled. We already use OF_BOARD for various boards > that > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for > example > > > > >> (as I said in the cover letter "Most boards do provide one, but > some > > > > >> don't."). So this series is just completing the picture by > enforcing > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > I think the key point that will get you closer to where I am on this > > > > issue, is that OF_BOARD needs to be a run-time option. At present it > > > > has build-time effects and this is quite wrong. If you go through all > > > > the material I have written on this I think I have motivated that > very > > > > clearly. > > > > > > > > Another big issue is that I believe we need ONE devicetree for > U-Boot, > > > > not two that get merged by U-Boot. Again I have gone through that in > a > > > > lot of detail. > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > here's the biggest sticking point. To be clear, you agree that U-Boot > > > needs to support being passed a device tree to use, at run time, yes? > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > Not at runtime. > > > > > > > > So is the sticking point here that we really have two classes of > > > devices, one class where we will never ever be given the device tree at > > > run time (think BeagleBone Black) and one where we will always be given > > > one at run time (think Raspberry Pi) ? > > > > I'm not sure it will be that black and white. I suspect there will be > > (many) boards which can boot happily with the U-Boot devicetree but > > can also accept one at runtime, if provided. For example, you may want > > to boot with or without TF-A or some other, earlier stage. > > I don't understand this: as Tom mentioned this is a platform decision: > either it provides a DT somewhere (flash, EEPROM, prior firmware stage), > or it doesn't. Sure, you can always hack your own DT in, somehow, for > development or experimentation purposes, but that is a separate issue. > > Most of those platforms actually utilise some dynamic DTs, btw, where > software amends the DT on the fly: > - Highbank has a stub DT in SPI flash, and the management controller > firmware detects the size and some extra DRAM (DIMMs!) parameters at boot > time, and writes the /memory node accordingly. > - RPi3/4 have DT overlay files on the SD card, and depending on what a > user wrote in config.txt, they get applied to the DT (or not). > - Even for the Allwinner H616 we amend the OF_SEPARATE provided DT copy in > DRAM in TF-A, to carve out the DRAM region TF-A occupies. > - QEMU is the obvious example, where the whole machine is highly dynamic, > and there is no such thing as a fixed DT (how many cores?, how much > memory?, how many virtio devices?, flash?, SCSI?) > > > I believe we have got unstuck because OF_BOARD (perhaps inadvertently) > > provided a way to entirely omit a devicetree from U-Boot, thus making > > things like binman and U-Boot /config impossible, for example. > > I have the feeling this is because we abuse DT for this. Conceptually the > DT is not a configuration file, but a hardware description. +42!!! > I see that it > is also a nice and flexible, hierarchical key/value storage, for which we > have code in anyway, so it makes hardcoding data in the code easier to > avoid. > But as we see now, this has problems as well. > > So shall we separate those use cases? And attach just a tree with /binman > and /config (in DTB format), but treat this separately from the hardware > description? (Admittedly I have still to wrap my head around why we need > /binman at U-Boot runtime in the first place.) +1 > > > Cheers, > Andre > > > So I > > want to claw that back, so there is always some sort of devicetree in > > U-Boot, as we have for rpi_3, etc. > > > > 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: 16742 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-13 18:06 ` Simon Glass 2021-10-14 14:56 ` Tom Rini @ 2021-10-14 18:12 ` François Ozog 2021-10-14 21:00 ` Simon Glass 1 sibling, 1 reply; 73+ messages in thread From: François Ozog @ 2021-10-14 18:12 UTC (permalink / raw) To: Simon Glass Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 10694 bytes --] Le mer. 13 oct. 2021 à 20:06, Simon Glass <sjg@chromium.org> a écrit : > Hi François, > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> > wrote: > > > > Hi Simon > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > >> > >> Hi Tom, Bin,François, > >> > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > >> > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > >> > > Hi Simon, > >> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 > >> > > > > >> > > > 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 at [1]. > >> > > > > >> > > > 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. > >> > > > >> > > Adding device trees that are never used sounds like a hack to me. > >> > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > >> > > command line parameters, and the device tree you put in this series > >> > > has various hardcoded <phandle> values which normally do not show up > >> > > in hand-written dts files. > >> > > > >> > > I am not sure I understand the whole point of this. > >> > > >> > I am also confused and do not like the idea of adding device trees for > >> > platforms that are capable of and can / do have a device tree to give > us > >> > at run time. > >> > >> (I'll just reply to this one email, since the same points applies to > >> all replies I think) > >> > >> I have been thinking about this and discussing it with people for a > >> few months now. I've been signalling a change like this for over a > >> month now, on U-Boot contributor calls and in discussions with Linaro > >> people. I sent a patch (below) to try to explain things. I hope it is > >> not a surprise! > >> > >> The issue here is that we need a devicetree in-tree in U-Boot, to > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > >> Ilias' series and this one we can get ourselves on a stronger footing. > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > >> For more context: > >> > >> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > >> > >> BTW I did suggest to QEMU ARM that they support a way of adding the > >> u-boot.dtsi but there was not much interest there (in fact the > >> maintainer would prefer there was no special support even for booting > >> Linux directly!) > > > > i understand their point of view and agree with it. > >> > >> But in any case it doesn't really help U-Boot. I > >> think the path forward might be to run QEMU twice, once to get its > >> generated tree and once to give the 'merged' tree with the U-Boot > >> properties in it, if people want to use U-Boot features. > >> > >> I do strongly believe that OF_BOARD must be a run-time option, not a > >> build-time one. It creates all sorts of problems and obscurity which > >> have taken months to unpick. See the above patch for the rationale. > >> > >> To add to that rationale, OF_BOARD needs to be an option available to > >> any board. At some point in the future it may become a common way > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree > >> to it. It doesn't make any sense to have people decide whether or not > >> to set OF_BOARD at build time, thus affecting how the image is put > >> together. We'll end up with different U-Boot build targets like > >> capricorn, capricorn_of_board and the like. It should be obvious where > >> that will lead. Instead, OF_BOARD needs to become a commonly used > >> option, perhaps enabled by most/all boards, so that this sort of build > >> explosion is not needed. > > > > If you mean that when boards are by construction providing a DTB to > U-Boot then I agree very much. But I don’t understand how the patch set > supports it as it puts dts files for those boards to be built. > >> > >> U-Boot needs to be flexible enough to > >> function correctly in whatever runtime environment in which it finds > >> itself. > >> > >> Also as binman is pressed into service more and more to build the > >> complex firmware images that are becoming fashionable, it needs a > >> definition (in the devicetree) that describes how to create the image. > >> We can't support that unless we are building a devicetree, nor can the > >> running program access the image layout without that information. > >> > >> François's point about 'don't use this with any kernel' is > >> germane...but of course I am not suggesting doing that, since OF_BOARD > >> is, still, enabled. We already use OF_BOARD for various boards that > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > >> (as I said in the cover letter "Most boards do provide one, but some > >> don't."). So this series is just completing the picture by enforcing > >> that *some sort* of devicetree is always present. > > > > That seems inconsistent with the OF_BOARD becomes the default. > > I think the key point that will get you closer to where I am on this > issue, is that OF_BOARD needs to be a run-time option. At present it > has build-time effects and this is quite wrong. Doesn’t that mean that the current build system is not fully supporting boards that do provide the DT and you try to hack your way in ? As I replied to Tom, I could accept temporarily a void.dts containing nothing to actually uallly pass any build problem until we properly fix the build system. (But no “close to real” fake dts in the dts section) > If you go through all > the material I have written on this I think I have motivated that very > clearly. > > Another big issue is that I believe we need ONE devicetree for U-Boot, > not two that get merged by U-Boot. Again I have gone through that in a > lot of detail. > i know but a number of people do not agree with your position. U-Boot can leverage many DTs coming from hats and capes to finalize the DT it passes to OS. It can also leverage a file, a FIP section (NT_FW_CONFIG in TFA) a FIT section formatted as FDT for its own configuration. > > >> > >> > >> I can't quite pinpoint the patch where U-Boot started allowing the > >> devicetree to be omitted, but if people are interested I could try a > >> little harder. It was certainly not my intention (putting on my > >> device-tree-maintainer hat) to go down that path and it slipped in > >> somehow in all the confusion. I'm not sure anyone could tell you that > >> rpi_3 has an in-tree devicetree but rpi_4 does not... > >> > >> Anyway this series is very modest. It just adds the requirement that > >> all in-tree boards have some sort of sample devicetree and preferably > >> some documentation as to where it might come from at runtime. > > > > That’s a very good goal. But adding files in dts make them not samples > but templates to be used and replace board provided DTB. > > If you push all your DTS files in documentation, you do what you say: > adding sample files. > >> > >> That > >> should not be a tough call IMO. Assuming we can get the validation in > >> place (mentioned by Rob Herring recently) it will be quite natural to > >> sync them between (presumably) Linux and U-Boot. > >> > >> I am also quite happy to discuss what should actually be in these > >> devicetree files and whether some of them should be essentially empty. > >> As you probably noticed, some of them are empty since I literally > >> could not figure out where they come from! But there needs to be at > >> least some skeleton for U-Boot to progress, since devicetree is > >> critical to its feature set. > > > > absolutely. And thank you for your efforts to make that center stage. > This is also Linaro Edge group mist challenging task on the next 6 moths. > Knowing that we have lived in a floating situation for over 10 years, I > just hope we get consensus across projects and distro providers about the > right end goal and migration strategy. > >> > > Thank you. > > >> > >> > >> It is high time we tidied all this up. I predict it will be much > >> harder, and much more confusing, in 6 months. > > Just to set a road map here in case you can help unblock anything, > here are the things I am aware of, excluding the things I have > forgotten: > > - Ilias OF_PRIOR_STAGE, OF_HOSTFILE series > - this series > - the devicetree docs patch > - devicetree bindings upstream for U-Boot (first patch under discussion) > - bloblist as a means of passing devicetree, ACPI, tiny config info as the “ABI” of U-Boot entry need more specification. Having something close to Linux helped to get U-Boot in the RPI4 and other boards I believe. So we could start from here. The blob list may be an extra arg (x0=DTB, x1=bloblist in Arm). > > C structs to U-Boot (needs to be written) > - VPL so we can handle verification (patches pending) > - bootflow / VBE v2 series (coming next week) > > 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: 14786 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-14 18:12 ` François Ozog @ 2021-10-14 21:00 ` Simon Glass 0 siblings, 0 replies; 73+ messages in thread From: Simon Glass @ 2021-10-14 21:00 UTC (permalink / raw) To: François Ozog Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari Hi François, On Thu, 14 Oct 2021 at 12:13, François Ozog <francois.ozog@linaro.org> wrote: > > > > Le mer. 13 oct. 2021 à 20:06, Simon Glass <sjg@chromium.org> a écrit : >> >> Hi François, >> >> On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: >> > >> > Hi Simon >> > >> > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : >> >> >> >> Hi Tom, Bin,François, >> >> >> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: >> >> > >> >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: >> >> > > Hi Simon, >> >> > > >> >> > > On Wed, Oct 13, 2021 at 9:01 AM 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 >> >> > > > >> >> > > > 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 at [1]. >> >> > > > >> >> > > > 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. >> >> > > >> >> > > Adding device trees that are never used sounds like a hack to me. >> >> > > >> >> > > For QEMU, device tree is dynamically generated on the fly based on >> >> > > command line parameters, and the device tree you put in this series >> >> > > has various hardcoded <phandle> values which normally do not show up >> >> > > in hand-written dts files. >> >> > > >> >> > > I am not sure I understand the whole point of this. >> >> > >> >> > I am also confused and do not like the idea of adding device trees for >> >> > platforms that are capable of and can / do have a device tree to give us >> >> > at run time. >> >> >> >> (I'll just reply to this one email, since the same points applies to >> >> all replies I think) >> >> >> >> I have been thinking about this and discussing it with people for a >> >> few months now. I've been signalling a change like this for over a >> >> month now, on U-Boot contributor calls and in discussions with Linaro >> >> people. I sent a patch (below) to try to explain things. I hope it is >> >> not a surprise! >> >> >> >> The issue here is that we need a devicetree in-tree in U-Boot, to >> >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, >> >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between >> >> Ilias' series and this one we can get ourselves on a stronger footing. >> >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. >> >> For more context: >> >> >> >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ >> >> >> >> BTW I did suggest to QEMU ARM that they support a way of adding the >> >> u-boot.dtsi but there was not much interest there (in fact the >> >> maintainer would prefer there was no special support even for booting >> >> Linux directly!) >> > >> > i understand their point of view and agree with it. >> >> >> >> But in any case it doesn't really help U-Boot. I >> >> think the path forward might be to run QEMU twice, once to get its >> >> generated tree and once to give the 'merged' tree with the U-Boot >> >> properties in it, if people want to use U-Boot features. >> >> >> >> I do strongly believe that OF_BOARD must be a run-time option, not a >> >> build-time one. It creates all sorts of problems and obscurity which >> >> have taken months to unpick. See the above patch for the rationale. >> >> >> >> To add to that rationale, OF_BOARD needs to be an option available to >> >> any board. At some point in the future it may become a common way >> >> things are done, e.g. TF-A calling U-Boot and providing a devicetree >> >> to it. It doesn't make any sense to have people decide whether or not >> >> to set OF_BOARD at build time, thus affecting how the image is put >> >> together. We'll end up with different U-Boot build targets like >> >> capricorn, capricorn_of_board and the like. It should be obvious where >> >> that will lead. Instead, OF_BOARD needs to become a commonly used >> >> option, perhaps enabled by most/all boards, so that this sort of build >> >> explosion is not needed. >> > >> > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. >> >> >> >> U-Boot needs to be flexible enough to >> >> function correctly in whatever runtime environment in which it finds >> >> itself. >> >> >> >> Also as binman is pressed into service more and more to build the >> >> complex firmware images that are becoming fashionable, it needs a >> >> definition (in the devicetree) that describes how to create the image. >> >> We can't support that unless we are building a devicetree, nor can the >> >> running program access the image layout without that information. >> >> >> >> François's point about 'don't use this with any kernel' is >> >> germane...but of course I am not suggesting doing that, since OF_BOARD >> >> is, still, enabled. We already use OF_BOARD for various boards that >> >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example >> >> (as I said in the cover letter "Most boards do provide one, but some >> >> don't."). So this series is just completing the picture by enforcing >> >> that *some sort* of devicetree is always present. >> > >> > That seems inconsistent with the OF_BOARD becomes the default. >> >> I think the key point that will get you closer to where I am on this >> issue, is that OF_BOARD needs to be a run-time option. At present it >> has build-time effects and this is quite wrong. > > Doesn’t that mean that the current build system is not fully supporting boards that do provide the DT and you try to hack your way in ? As I replied to Tom, I could accept temporarily a void.dts containing nothing to actually uallly pass any build problem until we properly fix the build system. > (But no “close to real” fake dts in the dts section) Can you rephrase that paragraph, particularly the first setence? I am not sure what you are getting at. >> >> If you go through all >> the material I have written on this I think I have motivated that very >> clearly. >> >> Another big issue is that I believe we need ONE devicetree for U-Boot, >> not two that get merged by U-Boot. Again I have gone through that in a >> lot of detail. > > i know but a number of people do not agree with your position. U-Boot can leverage many DTs coming from hats and capes to finalize the DT it passes to OS. It can also leverage a file, a FIP section (NT_FW_CONFIG in TFA) a FIT section formatted as FDT for its own configuration. Perhaps it wasn't clear from the context, but I was talking about the devicetree for U-Boot, i.e. the control DTB for U-Boot. It's fine to merge overlays, etc. to pass to Linux, of course. >> >> >> >> >> >> >> >> I can't quite pinpoint the patch where U-Boot started allowing the >> >> devicetree to be omitted, but if people are interested I could try a >> >> little harder. It was certainly not my intention (putting on my >> >> device-tree-maintainer hat) to go down that path and it slipped in >> >> somehow in all the confusion. I'm not sure anyone could tell you that >> >> rpi_3 has an in-tree devicetree but rpi_4 does not... >> >> >> >> Anyway this series is very modest. It just adds the requirement that >> >> all in-tree boards have some sort of sample devicetree and preferably >> >> some documentation as to where it might come from at runtime. >> > >> > That’s a very good goal. But adding files in dts make them not samples but templates to be used and replace board provided DTB. >> > If you push all your DTS files in documentation, you do what you say: adding sample files. >> >> >> >> That >> >> should not be a tough call IMO. Assuming we can get the validation in >> >> place (mentioned by Rob Herring recently) it will be quite natural to >> >> sync them between (presumably) Linux and U-Boot. >> >> >> >> I am also quite happy to discuss what should actually be in these >> >> devicetree files and whether some of them should be essentially empty. >> >> As you probably noticed, some of them are empty since I literally >> >> could not figure out where they come from! But there needs to be at >> >> least some skeleton for U-Boot to progress, since devicetree is >> >> critical to its feature set. >> > >> > absolutely. And thank you for your efforts to make that center stage. This is also Linaro Edge group mist challenging task on the next 6 moths. Knowing that we have lived in a floating situation for over 10 years, I just hope we get consensus across projects and distro providers about the right end goal and migration strategy. >> >> >> >> Thank you. >> >> >> >> >> >> >> It is high time we tidied all this up. I predict it will be much >> >> harder, and much more confusing, in 6 months. >> >> Just to set a road map here in case you can help unblock anything, >> here are the things I am aware of, excluding the things I have >> forgotten: >> >> - Ilias OF_PRIOR_STAGE, OF_HOSTFILE series >> - this series >> - the devicetree docs patch >> - devicetree bindings upstream for U-Boot (first patch under discussion) >> - bloblist as a means of passing devicetree, ACPI, tiny config info as > > the “ABI” of U-Boot entry need more specification. Having something close to Linux helped to get U-Boot in the RPI4 and other boards I believe. So we could start from here. The blob list may be an extra arg (x0=DTB, x1=bloblist in Arm). Yes that's my intent, hopefully in a few weeks. >> >> >> C structs to U-Boot (needs to be written) >> - VPL so we can handle verification (patches pending) >> - bootflow / VBE v2 series (coming next week) Regards, Simon ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-13 1:29 ` [PATCH 00/16] fdt: Make OF_BOARD a boolean option Bin Meng 2021-10-13 1:34 ` Tom Rini @ 2021-10-13 12:39 ` Philippe Mathieu-Daudé 2021-10-13 13:06 ` François Ozog 1 sibling, 1 reply; 73+ messages in thread From: Philippe Mathieu-Daudé @ 2021-10-13 12:39 UTC (permalink / raw) To: Bin Meng, Simon Glass, qemu-arm Cc: Liviu Dudau, Neil Armstrong, Rick Chen, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, U-Boot Mailing List, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Green Wan, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Heiko Schocher, Peter Robinson, Anastasiia Lukianenko, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, Andre Przywara, Tim Harvey, Ashok Reddy Soma, qemu-devel@nongnu.org Developers, Alexander Graf, Valentin Longchamp, T Karthik Reddy, Sinan Akman, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, Atish Patra, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Pali Rohár, Dimitri John Ledkov, Padmarao Begari Hi Simon, On 10/13/21 03:29, Bin Meng wrote: > On Wed, Oct 13, 2021 at 9:01 AM 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 >> >> 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 at [1]. >> >> 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. > > Adding device trees that are never used sounds like a hack to me. > > For QEMU, device tree is dynamically generated on the fly based on > command line parameters, and the device tree you put in this series > has various hardcoded <phandle> values which normally do not show up > in hand-written dts files. Besides, QEMU generates these dtb at runtime on purpose: it gives emulated machines the freedom to evolve by adding new devices, mapping/wiring peripherals differently. By adding static dtb this gives QEMU users false expectations the machine hardware is stable, or force QEMU to have this interface become a stable API. From QEMU perspective this seems counter-productive. Digging a bit I see this has already been discussed on qemu-devel@ mailing list recently: https://lore.kernel.org/qemu-devel/CAFEAcA_QNcAHtdxUPLpmyzMYgb9YzhcE0-zyh=N8rqm4vOcGZA@mail.gmail.com/ > I am not sure I understand the whole point of this. > >> >> It also provides a few qemu clean-ups discovered along the way. >> >> This series is based on Ilias' two series for OF_HOSTFILE and >> OF_PRIOR_STAGE removal. >> >> It is available at u-boot-dm/ofb-working >> >> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ >> > > Regards, > Bin > ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-13 12:39 ` Philippe Mathieu-Daudé @ 2021-10-13 13:06 ` François Ozog 0 siblings, 0 replies; 73+ messages in thread From: François Ozog @ 2021-10-13 13:06 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, qemu-arm, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 3143 bytes --] Le mer. 13 oct. 2021 à 14:42, Philippe Mathieu-Daudé <philmd@redhat.com> a écrit : > Hi Simon, > > On 10/13/21 03:29, Bin Meng wrote: > > On Wed, Oct 13, 2021 at 9:01 AM 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 > >> > >> 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 at [1]. > >> > >> 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. > > > > Adding device trees that are never used sounds like a hack to me. > > > > For QEMU, device tree is dynamically generated on the fly based on > > command line parameters, and the device tree you put in this series > > has various hardcoded <phandle> values which normally do not show up > > in hand-written dts files. > > Besides, QEMU generates these dtb at runtime on purpose: it gives > emulated machines the freedom to evolve by adding new devices, > mapping/wiring peripherals differently. > > By adding static dtb this gives QEMU users false expectations the > machine hardware is stable, or force QEMU to have this interface > become a stable API. > > From QEMU perspective this seems counter-productive. > +1 > > Digging a bit I see this has already been discussed on qemu-devel@ > mailing list recently: > > > https://lore.kernel.org/qemu-devel/CAFEAcA_QNcAHtdxUPLpmyzMYgb9YzhcE0-zyh=N8rqm4vOcGZA@mail.gmail.com/ > > > I am not sure I understand the whole point of this. > > > >> > >> It also provides a few qemu clean-ups discovered along the way. > >> > >> This series is based on Ilias' two series for OF_HOSTFILE and > >> OF_PRIOR_STAGE removal. > >> > >> It is available at u-boot-dm/ofb-working > >> > >> [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > >> > > > > Regards, > > Bin > > > > -- 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: 5718 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-13 1:01 [PATCH 00/16] fdt: Make OF_BOARD a boolean option Simon Glass ` (6 preceding siblings ...) 2021-10-13 1:29 ` [PATCH 00/16] fdt: Make OF_BOARD a boolean option Bin Meng @ 2021-10-13 4:26 ` Heinrich Schuchardt 2021-10-13 13:06 ` François Ozog 2021-10-13 9:50 ` Andre Przywara 8 siblings, 1 reply; 73+ messages in thread From: Heinrich Schuchardt @ 2021-10-13 4:26 UTC (permalink / raw) To: Simon Glass, U-Boot Mailing List Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari On 10/13/21 03:01, Simon Glass wrote: > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > there are only three ways to obtain a devicetree: > > - OF_SEPARATE - the normal way, where the devicetree is built and > appended to U-Boot > - OF_EMBED - for development purposes, the devicetree is embedded in > the ELF file (also used for EFI) > - OF_BOARD - the board figures it out on its own > > The last one is currently set up so that no devicetree is needed at all > in the U-Boot tree. Most boards do provide one, but some don't. Some > don't even provide instructions on how to boot on the board. > > The problems with this approach are documented at [1]. > > 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. Why should we add dummy files with irrelevant content (see patch 06/16) to make the build work? Why don't you fix the Makefile instead? Best regards Heinrich > > It also provides a few qemu clean-ups discovered along the way. > > This series is based on Ilias' two series for OF_HOSTFILE and > OF_PRIOR_STAGE removal. > > It is available at u-boot-dm/ofb-working > > [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > Simon Glass (16): > arm: qemu: Mention -nographic in the docs > arm: qemu: Explain how to extract the generate devicetree > riscv: qemu: Explain how to extract the generate devicetree > 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 > > Makefile | 3 +- > arch/arm/dts/Makefile | 20 +- > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++ > arch/arm/dts/bcm7xxx.dts | 15 + > arch/arm/dts/highbank.dts | 14 + > arch/arm/dts/juno-r2.dts | 1038 +++++++++++++ > arch/arm/dts/octeontx.dts | 14 + > arch/arm/dts/qemu-arm.dts | 402 +++++ > arch/arm/dts/qemu-arm64.dts | 381 +++++ > arch/arm/dts/xenguest-arm64.dts | 15 + > arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ > arch/powerpc/dts/Makefile | 1 + > arch/powerpc/dts/qemu-ppce500.dts | 264 ++++ > arch/riscv/dts/Makefile | 2 +- > arch/riscv/dts/qemu-virt.dts | 8 - > arch/riscv/dts/qemu-virt32.dts | 217 +++ > arch/riscv/dts/qemu-virt64.dts | 217 +++ > configs/bcm7260_defconfig | 1 + > configs/bcm7445_defconfig | 1 + > configs/highbank_defconfig | 2 +- > configs/octeontx2_95xx_defconfig | 1 + > configs/octeontx2_96xx_defconfig | 1 + > configs/octeontx_81xx_defconfig | 1 + > configs/octeontx_83xx_defconfig | 1 + > configs/qemu-ppce500_defconfig | 2 + > configs/qemu-riscv32_defconfig | 1 + > configs/qemu-riscv32_smode_defconfig | 1 + > configs/qemu-riscv32_spl_defconfig | 4 +- > configs/qemu-riscv64_defconfig | 1 + > configs/qemu-riscv64_smode_defconfig | 1 + > configs/qemu-riscv64_spl_defconfig | 3 +- > configs/qemu_arm64_defconfig | 1 + > configs/qemu_arm_defconfig | 1 + > configs/rpi_4_32b_defconfig | 1 + > configs/rpi_4_defconfig | 1 + > configs/rpi_arm64_defconfig | 1 + > configs/vexpress_aemv8a_juno_defconfig | 1 + > configs/xenguest_arm64_defconfig | 1 + > configs/xilinx_versal_virt_defconfig | 1 + > doc/board/emulation/qemu-arm.rst | 19 +- > doc/board/emulation/qemu-riscv.rst | 12 + > dts/Kconfig | 27 +- > tools/binman/binman.rst | 20 - > 43 files changed, 4922 insertions(+), 61 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 > ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-13 4:26 ` Heinrich Schuchardt @ 2021-10-13 13:06 ` François Ozog 0 siblings, 0 replies; 73+ messages in thread From: François Ozog @ 2021-10-13 13:06 UTC (permalink / raw) To: Heinrich Schuchardt Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel, Andre Przywara, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 6265 bytes --] Le mer. 13 oct. 2021 à 14:41, Heinrich Schuchardt < heinrich.schuchardt@canonical.com> a écrit : > > > On 10/13/21 03:01, Simon Glass wrote: > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > there are only three ways to obtain a devicetree: > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > appended to U-Boot > > - OF_EMBED - for development purposes, the devicetree is embedded in > > the ELF file (also used for EFI) > > - OF_BOARD - the board figures it out on its own > > > > The last one is currently set up so that no devicetree is needed at all > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > don't even provide instructions on how to boot on the board. > > > > The problems with this approach are documented at [1]. > > > > 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. > > Why should we add dummy files with irrelevant content (see patch 06/16) > to make the build work? Why don't you fix the Makefile instead? > +1 > > Best regards > > Heinrich > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > This series is based on Ilias' two series for OF_HOSTFILE and > > OF_PRIOR_STAGE removal. > > > > It is available at u-boot-dm/ofb-working > > > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > Simon Glass (16): > > arm: qemu: Mention -nographic in the docs > > arm: qemu: Explain how to extract the generate devicetree > > riscv: qemu: Explain how to extract the generate devicetree > > 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 > > > > Makefile | 3 +- > > arch/arm/dts/Makefile | 20 +- > > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++ > > arch/arm/dts/bcm7xxx.dts | 15 + > > arch/arm/dts/highbank.dts | 14 + > > arch/arm/dts/juno-r2.dts | 1038 +++++++++++++ > > arch/arm/dts/octeontx.dts | 14 + > > arch/arm/dts/qemu-arm.dts | 402 +++++ > > arch/arm/dts/qemu-arm64.dts | 381 +++++ > > arch/arm/dts/xenguest-arm64.dts | 15 + > > arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ > > arch/powerpc/dts/Makefile | 1 + > > arch/powerpc/dts/qemu-ppce500.dts | 264 ++++ > > arch/riscv/dts/Makefile | 2 +- > > arch/riscv/dts/qemu-virt.dts | 8 - > > arch/riscv/dts/qemu-virt32.dts | 217 +++ > > arch/riscv/dts/qemu-virt64.dts | 217 +++ > > configs/bcm7260_defconfig | 1 + > > configs/bcm7445_defconfig | 1 + > > configs/highbank_defconfig | 2 +- > > configs/octeontx2_95xx_defconfig | 1 + > > configs/octeontx2_96xx_defconfig | 1 + > > configs/octeontx_81xx_defconfig | 1 + > > configs/octeontx_83xx_defconfig | 1 + > > configs/qemu-ppce500_defconfig | 2 + > > configs/qemu-riscv32_defconfig | 1 + > > configs/qemu-riscv32_smode_defconfig | 1 + > > configs/qemu-riscv32_spl_defconfig | 4 +- > > configs/qemu-riscv64_defconfig | 1 + > > configs/qemu-riscv64_smode_defconfig | 1 + > > configs/qemu-riscv64_spl_defconfig | 3 +- > > configs/qemu_arm64_defconfig | 1 + > > configs/qemu_arm_defconfig | 1 + > > configs/rpi_4_32b_defconfig | 1 + > > configs/rpi_4_defconfig | 1 + > > configs/rpi_arm64_defconfig | 1 + > > configs/vexpress_aemv8a_juno_defconfig | 1 + > > configs/xenguest_arm64_defconfig | 1 + > > configs/xilinx_versal_virt_defconfig | 1 + > > doc/board/emulation/qemu-arm.rst | 19 +- > > doc/board/emulation/qemu-riscv.rst | 12 + > > dts/Kconfig | 27 +- > > tools/binman/binman.rst | 20 - > > 43 files changed, 4922 insertions(+), 61 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 > > > -- 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: 9300 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-13 1:01 [PATCH 00/16] fdt: Make OF_BOARD a boolean option Simon Glass ` (7 preceding siblings ...) 2021-10-13 4:26 ` Heinrich Schuchardt @ 2021-10-13 9:50 ` Andre Przywara 2021-10-13 13:05 ` François Ozog 8 siblings, 1 reply; 73+ messages in thread From: Andre Przywara @ 2021-10-13 9:50 UTC (permalink / raw) To: Simon Glass Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, U-Boot Mailing List, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Rob Herring, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, Atish Patra, David Abdurachmanov, Priyanka Jain, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari On Tue, 12 Oct 2021 19:01:04 -0600 Simon Glass <sjg@chromium.org> wrote: Hi, > 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 at [1]. > > 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. So I am possibly fine with that, but: > This series makes this change, adding various missing devicetree files > (and placeholders) to make the build work. If we just need it to make the build work, we not just have pure stub DTs, as you do for highbank, everywhere? Adding *some* DT files for those platforms that actually do the right thing seems like the wrong direction to me. Providing DTs in the source repositories of the actual consumers is more of a bad habit that dragged on since Linux started this around 10 years ago (for practical reasons). For *some* platforms U-Boot is the firmware component that is in the best situation to provide the DTB (because it's more than a mere bootloader), but for other it's just not. And this is not even looking at really dynamic platforms like QEMU, where providing some kind of fixed DT is just not working. I don't get the argument that people would need to see the DT in the tree to develop code. The DT spec and binding documentation (currently living in the Linux kernel source tree) provide the specification to code against, and the platform specific selection of drivers in Kconfig and _defconfig select the drivers for the devices that people are expected to see. Why does one need actual DT files in the tree? I totally agree on adding more documentation, possibly *pointing* to example DTs or giving commands on how to obtain the actual copy (-dumpdtb, /sys/firmware/devicetree), but don't think that adding some .dts files for platforms that don't need them is the right way. Cheers, Andre. > > It also provides a few qemu clean-ups discovered along the way. > > This series is based on Ilias' two series for OF_HOSTFILE and > OF_PRIOR_STAGE removal. > > It is available at u-boot-dm/ofb-working > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > Simon Glass (16): > arm: qemu: Mention -nographic in the docs > arm: qemu: Explain how to extract the generate devicetree > riscv: qemu: Explain how to extract the generate devicetree > 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 > > Makefile | 3 +- > arch/arm/dts/Makefile | 20 +- > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++ > arch/arm/dts/bcm7xxx.dts | 15 + > arch/arm/dts/highbank.dts | 14 + > arch/arm/dts/juno-r2.dts | 1038 +++++++++++++ > arch/arm/dts/octeontx.dts | 14 + > arch/arm/dts/qemu-arm.dts | 402 +++++ > arch/arm/dts/qemu-arm64.dts | 381 +++++ > arch/arm/dts/xenguest-arm64.dts | 15 + > arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ > arch/powerpc/dts/Makefile | 1 + > arch/powerpc/dts/qemu-ppce500.dts | 264 ++++ > arch/riscv/dts/Makefile | 2 +- > arch/riscv/dts/qemu-virt.dts | 8 - > arch/riscv/dts/qemu-virt32.dts | 217 +++ > arch/riscv/dts/qemu-virt64.dts | 217 +++ > configs/bcm7260_defconfig | 1 + > configs/bcm7445_defconfig | 1 + > configs/highbank_defconfig | 2 +- > configs/octeontx2_95xx_defconfig | 1 + > configs/octeontx2_96xx_defconfig | 1 + > configs/octeontx_81xx_defconfig | 1 + > configs/octeontx_83xx_defconfig | 1 + > configs/qemu-ppce500_defconfig | 2 + > configs/qemu-riscv32_defconfig | 1 + > configs/qemu-riscv32_smode_defconfig | 1 + > configs/qemu-riscv32_spl_defconfig | 4 +- > configs/qemu-riscv64_defconfig | 1 + > configs/qemu-riscv64_smode_defconfig | 1 + > configs/qemu-riscv64_spl_defconfig | 3 +- > configs/qemu_arm64_defconfig | 1 + > configs/qemu_arm_defconfig | 1 + > configs/rpi_4_32b_defconfig | 1 + > configs/rpi_4_defconfig | 1 + > configs/rpi_arm64_defconfig | 1 + > configs/vexpress_aemv8a_juno_defconfig | 1 + > configs/xenguest_arm64_defconfig | 1 + > configs/xilinx_versal_virt_defconfig | 1 + > doc/board/emulation/qemu-arm.rst | 19 +- > doc/board/emulation/qemu-riscv.rst | 12 + > dts/Kconfig | 27 +- > tools/binman/binman.rst | 20 - > 43 files changed, 4922 insertions(+), 61 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 > ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option 2021-10-13 9:50 ` Andre Przywara @ 2021-10-13 13:05 ` François Ozog 0 siblings, 0 replies; 73+ messages in thread From: François Ozog @ 2021-10-13 13:05 UTC (permalink / raw) To: Andre Przywara Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij, Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Rob Herring, Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren, qemu-devel, Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List, David Abdurachmanov, Priyanka Jain, Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár, Tom Rini, Dimitri John Ledkov, Padmarao Begari [-- Attachment #1: Type: text/plain, Size: 7566 bytes --] Le mer. 13 oct. 2021 à 14:41, Andre Przywara <andre.przywara@arm.com> a écrit : > On Tue, 12 Oct 2021 19:01:04 -0600 > Simon Glass <sjg@chromium.org> wrote: > > Hi, > > > 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 at [1]. > > > > 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. > > So I am possibly fine with that, but: > > > This series makes this change, adding various missing devicetree files > > (and placeholders) to make the build work. > > If we just need it to make the build work, we not just have pure stub DTs, > as you do for highbank, everywhere? > Adding *some* DT files for those platforms that actually do the right > thing seems like the wrong direction to me. > Providing DTs in the source repositories of the actual consumers is more > of a bad habit that dragged on since Linux started this around 10 years > ago (for practical reasons). For *some* platforms U-Boot is the firmware > component that is in the best situation to provide the DTB (because it's > more than a mere bootloader), but for other it's just not. And this is not > even looking at really dynamic platforms like QEMU, where providing some > kind of fixed DT is just not working. > > I don't get the argument that people would need to see the DT in the tree > to develop code. The DT spec and binding documentation (currently living > in the Linux kernel source tree) provide the specification to code > against, and the platform specific selection of drivers in Kconfig and > _defconfig select the drivers for the devices that people are expected to > see. Why does one need actual DT files in the tree? > > I totally agree on adding more documentation, possibly *pointing* to > example > DTs or giving commands on how to obtain the actual copy (-dumpdtb, > /sys/firmware/devicetree), but don't think that adding some .dts files for > platforms that don't need them is the right way. > > Cheers, > Andre. +1 > > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > This series is based on Ilias' two series for OF_HOSTFILE and > > OF_PRIOR_STAGE removal. > > > > It is available at u-boot-dm/ofb-working > > > > [1] > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > Simon Glass (16): > > arm: qemu: Mention -nographic in the docs > > arm: qemu: Explain how to extract the generate devicetree > > riscv: qemu: Explain how to extract the generate devicetree > > 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 > > > > Makefile | 3 +- > > arch/arm/dts/Makefile | 20 +- > > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++ > > arch/arm/dts/bcm7xxx.dts | 15 + > > arch/arm/dts/highbank.dts | 14 + > > arch/arm/dts/juno-r2.dts | 1038 +++++++++++++ > > arch/arm/dts/octeontx.dts | 14 + > > arch/arm/dts/qemu-arm.dts | 402 +++++ > > arch/arm/dts/qemu-arm64.dts | 381 +++++ > > arch/arm/dts/xenguest-arm64.dts | 15 + > > arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ > > arch/powerpc/dts/Makefile | 1 + > > arch/powerpc/dts/qemu-ppce500.dts | 264 ++++ > > arch/riscv/dts/Makefile | 2 +- > > arch/riscv/dts/qemu-virt.dts | 8 - > > arch/riscv/dts/qemu-virt32.dts | 217 +++ > > arch/riscv/dts/qemu-virt64.dts | 217 +++ > > configs/bcm7260_defconfig | 1 + > > configs/bcm7445_defconfig | 1 + > > configs/highbank_defconfig | 2 +- > > configs/octeontx2_95xx_defconfig | 1 + > > configs/octeontx2_96xx_defconfig | 1 + > > configs/octeontx_81xx_defconfig | 1 + > > configs/octeontx_83xx_defconfig | 1 + > > configs/qemu-ppce500_defconfig | 2 + > > configs/qemu-riscv32_defconfig | 1 + > > configs/qemu-riscv32_smode_defconfig | 1 + > > configs/qemu-riscv32_spl_defconfig | 4 +- > > configs/qemu-riscv64_defconfig | 1 + > > configs/qemu-riscv64_smode_defconfig | 1 + > > configs/qemu-riscv64_spl_defconfig | 3 +- > > configs/qemu_arm64_defconfig | 1 + > > configs/qemu_arm_defconfig | 1 + > > configs/rpi_4_32b_defconfig | 1 + > > configs/rpi_4_defconfig | 1 + > > configs/rpi_arm64_defconfig | 1 + > > configs/vexpress_aemv8a_juno_defconfig | 1 + > > configs/xenguest_arm64_defconfig | 1 + > > configs/xilinx_versal_virt_defconfig | 1 + > > doc/board/emulation/qemu-arm.rst | 19 +- > > doc/board/emulation/qemu-riscv.rst | 12 + > > dts/Kconfig | 27 +- > > tools/binman/binman.rst | 20 - > > 43 files changed, 4922 insertions(+), 61 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 > > > > -- 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: 10669 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
end of thread, other threads:[~2021-11-02 15:19 UTC | newest] Thread overview: 73+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-13 1:01 [PATCH 00/16] fdt: Make OF_BOARD a boolean option Simon Glass 2021-10-13 1:01 ` [PATCH 01/16] arm: qemu: Mention -nographic in the docs Simon Glass 2021-10-13 1:01 ` [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree Simon Glass 2021-10-13 1:19 ` François Ozog 2021-10-13 16:58 ` Simon Glass 2021-10-13 17:36 ` Tom Rini 2021-10-13 1:01 ` [PATCH 03/16] riscv: " Simon Glass 2021-10-13 1:01 ` [PATCH 04/16] arm: qemu: Add a devicetree file for qemu_arm Simon Glass 2021-10-13 1:01 ` [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64 Simon Glass 2021-10-13 1:15 ` François Ozog 2021-10-27 14:44 ` Alex Bennée 2021-10-27 14:56 ` Tom Rini 2021-10-27 18:34 ` Simon Glass 2021-10-27 18:39 ` Tom Rini 2021-10-27 19:45 ` Alex Bennée 2021-10-13 1:01 ` [PATCH 06/16] riscv: qemu: Add devicetree files for qemu_riscv32/64 Simon Glass 2021-10-13 4:21 ` Heinrich Schuchardt 2021-10-13 1:29 ` [PATCH 00/16] fdt: Make OF_BOARD a boolean option Bin Meng 2021-10-13 1:34 ` Tom Rini 2021-10-13 8:02 ` François Ozog 2021-10-13 14:47 ` Simon Glass 2021-10-13 17:34 ` François Ozog 2021-10-13 18:06 ` Simon Glass 2021-10-14 14:56 ` Tom Rini 2021-10-14 15:17 ` Simon Glass 2021-10-14 15:28 ` Tom Rini 2021-10-14 17:58 ` François Ozog 2021-10-15 18:03 ` Simon Glass 2021-10-26 6:46 ` Ilias Apalodimas 2021-10-27 12:59 ` Tom Rini 2021-10-27 13:30 ` François Ozog 2021-10-27 13:38 ` Tom Rini 2021-10-27 13:47 ` Ilias Apalodimas 2021-10-27 14:26 ` Tom Rini 2021-10-27 13:48 ` François Ozog 2021-10-27 14:30 ` Tom Rini 2021-10-28 2:50 ` Simon Glass 2021-10-28 8:21 ` François Ozog 2021-10-28 14:30 ` Simon Glass 2021-10-28 14:50 ` François Ozog 2021-10-28 15:44 ` Simon Glass 2021-10-28 16:25 ` François Ozog 2021-11-02 14:59 ` Simon Glass 2021-11-01 11:04 ` Ilias Apalodimas 2021-11-02 10:06 ` Michael Walle 2021-11-02 12:34 ` François Ozog 2021-11-02 14:59 ` Simon Glass 2021-10-27 12:48 ` Tom Rini 2021-10-27 13:15 ` François Ozog 2021-10-27 13:23 ` Heinrich Schuchardt 2021-10-27 14:55 ` Tom Rini 2021-10-27 15:02 ` Heinrich Schuchardt 2021-10-27 18:04 ` Tom Rini 2021-10-27 14:54 ` Tom Rini 2021-10-27 15:10 ` Mark Kettenis 2021-10-27 15:24 ` Simon Glass 2021-10-27 18:06 ` Tom Rini 2021-10-27 18:11 ` François Ozog 2021-10-27 21:52 ` Mark Kettenis 2021-10-27 16:02 ` François Ozog 2021-10-27 19:06 ` Tom Rini 2021-10-27 22:00 ` François Ozog 2021-10-28 14:41 ` Tom Rini 2021-10-14 16:24 ` Andre Przywara 2021-10-14 17:48 ` François Ozog 2021-10-14 18:12 ` François Ozog 2021-10-14 21:00 ` Simon Glass 2021-10-13 12:39 ` Philippe Mathieu-Daudé 2021-10-13 13:06 ` François Ozog 2021-10-13 4:26 ` Heinrich Schuchardt 2021-10-13 13:06 ` François Ozog 2021-10-13 9:50 ` Andre Przywara 2021-10-13 13:05 ` 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).