| Message ID | 20211202155919.2429190-1-sjg@chromium.org |
|---|---|
| Headers | show |
| Series | fdt: Make OF_BOARD a boolean option | expand |
Hi Simon Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > there are only three ways to obtain a devicetree: > > - OF_SEPARATE - the normal way, where the devicetree is built and > appended to U-Boot > - OF_EMBED - for development purposes, the devicetree is embedded in > the ELF file (also used for EFI) > - OF_BOARD - the board figures it out on its own > > The last one is currently set up so that no devicetree is needed at all > in the U-Boot tree. Most boards do provide one, but some don't. Some > don't even provide instructions on how to boot on the board. > > The problems with this approach are documented in another patch in this > series: "doc: Add documentation about devicetree usage" > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > can obtain its devicetree at runtime, even it is has a devicetree built > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > caller may have a better idea about the hardware available in the machine. > This is the case with a few QEMU boards, for example. > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > option, available with either OF_SEPARATE or OF_EMBED. > > This series makes this change, adding various missing devicetree files > (and placeholders) to make the build work. > > Note: If board maintainers are able to add their own patch to add the > files, some patches in this series can be dropped. > > It also provides a few qemu clean-ups discovered along the way. The > qemu-riscv64_spl problem is fixed. > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > Changes in v6: > - Fix description of OF_BOARD so it refers just to the current state > - Explain that the 'two devicetrees' refers to two *control* devicetrees > - Expand the commit message based on comments > - Expand the commit message based on comments You haven’t addressed any concerns expressed on the mailing list.so I am not in favor of this new version either. If you make a version without « fake DTs » as you name them, there are good advances in the documentation and other areas that would be better in mainline…. If I am the only one thinking this way and the patch can be accepted, I would love there is a warning in capital letters at the top of the DTS fake files that explains the intent of this fake DT, the possible outcomes of not using the one provided by the platform and the right way of dealing with DTs for the platform. > > Changes in v5: > - Bring into the OF_BOARD series > - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > - Refer to the 'control' DTB in the first paragraph > - Use QEMU instead of qemu > - Merge RISC-V and ARM patches since they are similar > - Add new patches to clean up fdtdec_setup() and surrounds > > Changes in v3: > - Clarify the 'bug' refered to at the top > - Reword 'This means that there' paragraph to explain U-Boot-specific > things > - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > > Changes in v2: > - Fix typos per Sean (thank you!) and a few others > - Add a 'Use of U-Boot /config node' section > - Drop mention of dm-verity since that actually uses the kernel cmdline > - Explain that OF_BOARD will still work after these changes (in > 'Once this bug is fixed...' paragraph) > - Expand a bit on the reason why the 'Current situation' is bad > - Clarify in a second place that Linux and U-Boot use the same devicetree > in 'To be clear, while U-Boot...' > - Expand on why we should have rules for other projects in > 'Devicetree in another project' > - Add a comment as to why devicetree in U-Boot is not 'bad design' > - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > - Rewrite 'Devicetree generated on-the-fly in another project' to cover > points raised on v1 > - Add 'Why does U-Boot have its nodes and properties?' > - Add 'Why not have two devicetrees?' > > Simon Glass (25): > doc: Add documentation about devicetree usage > arm: qemu: Mention -nographic in the docs > arm: riscv: qemu: Explain how to extract the generated dt > arm: qemu: Add a devicetree file for qemu_arm > arm: qemu: Add a devicetree file for qemu_arm64 > riscv: qemu: Add devicetree files for qemu_riscv32/64 > arm: rpi: Add a devicetree file for rpi_4 > arm: vexpress: Add a devicetree file for juno > arm: xenguest_arm64: Add a fake devicetree file > arm: octeontx: Add a fake devicetree file > arm: xilinx_versal_virt: Add a devicetree file > arm: bcm7xxx: Add a devicetree file > arm: qemu-ppce500: Add a devicetree file > arm: highbank: Add a fake devicetree file > fdt: Make OF_BOARD a bool option > Drop CONFIG_BINMAN_STANDALONE_FDT > doc: Update info on devicetree update > fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() > fdt: Drop #ifdefs with MULTI_DTB_FIT > fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() > fdt: Drop #ifdef around board_fdt_blob_setup() > fdt: Use if() for fdtcontroladdr check > fdt: Drop OF_CONTROL check in fdtdec_setup() > fdt: Drop remaining preprocessor macros in fdtdec_setup() > fdt: Don't call board_fdt_blob_setup() without OF_BOARD > > Makefile | 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 | 2 +- > configs/xilinx_versal_virt_defconfig | 1 + > doc/board/emulation/qemu-arm.rst | 10 +- > doc/board/emulation/qemu-riscv.rst | 3 + > doc/develop/devicetree/dt_qemu.rst | 48 + > doc/develop/devicetree/dt_update.rst | 497 ++++++ > doc/develop/devicetree/index.rst | 2 + > dts/Kconfig | 30 +- > include/asm-generic/global_data.h | 8 + > include/fdtdec.h | 21 +- > lib/fdtdec.c | 117 +- > tools/binman/binman.rst | 20 - > 49 files changed, 5538 insertions(+), 124 deletions(-) > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > create mode 100644 arch/arm/dts/bcm7xxx.dts > create mode 100644 arch/arm/dts/highbank.dts > create mode 100644 arch/arm/dts/juno-r2.dts > create mode 100644 arch/arm/dts/octeontx.dts > create mode 100644 arch/arm/dts/qemu-arm.dts > create mode 100644 arch/arm/dts/qemu-arm64.dts > create mode 100644 arch/arm/dts/xenguest-arm64.dts > create mode 100644 arch/arm/dts/xilinx-versal-virt.dts > create mode 100644 arch/powerpc/dts/qemu-ppce500.dts > delete mode 100644 arch/riscv/dts/qemu-virt.dts > create mode 100644 arch/riscv/dts/qemu-virt32.dts > create mode 100644 arch/riscv/dts/qemu-virt64.dts > create mode 100644 doc/develop/devicetree/dt_qemu.rst > create mode 100644 doc/develop/devicetree/dt_update.rst > > -- > 2.34.0.rc2.393.gf8c9666880-goog > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > Hi Simon > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > there are only three ways to obtain a devicetree: > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > appended to U-Boot > > - OF_EMBED - for development purposes, the devicetree is embedded in > > the ELF file (also used for EFI) > > - OF_BOARD - the board figures it out on its own > > > > The last one is currently set up so that no devicetree is needed at all > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > don't even provide instructions on how to boot on the board. > > > > The problems with this approach are documented in another patch in this > > series: "doc: Add documentation about devicetree usage" > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > can obtain its devicetree at runtime, even it is has a devicetree built > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > caller may have a better idea about the hardware available in the machine. > > This is the case with a few QEMU boards, for example. > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > option, available with either OF_SEPARATE or OF_EMBED. > > > > This series makes this change, adding various missing devicetree files > > (and placeholders) to make the build work. > > > > Note: If board maintainers are able to add their own patch to add the > > files, some patches in this series can be dropped. > > > > It also provides a few qemu clean-ups discovered along the way. The > > qemu-riscv64_spl problem is fixed. > > > > [1] > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > Changes in v6: > > - Fix description of OF_BOARD so it refers just to the current state > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > - Expand the commit message based on comments > > - Expand the commit message based on comments > > You haven’t addressed any concerns expressed on the mailing list.so I am > not in favor of this new version either. > If you make a version without « fake DTs » as you name them, there are good > advances in the documentation and other areas that would be better in > mainline…. > If I am the only one thinking this way and the patch can be accepted, I > would love there is a warning in capital letters at the top of the DTS fake > files that explains the intent of this fake DT, the possible outcomes of > not using the one provided by the platform and the right way of dealing > with DTs for the platform. This is the part that I too am still unhappy about. I do not want reference or fake or whatever device trees in the U-Boot source tree. We should be able to _remove_ the ones we have, that are not required, with doc/board/...rst explaining how to get / view one. Not adding more.
Hi François, On Thu, 2 Dec 2021 at 09:34, François Ozog <francois.ozog@linaro.org> wrote: > > Hi Simon > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : >> >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so >> there are only three ways to obtain a devicetree: >> >> - OF_SEPARATE - the normal way, where the devicetree is built and >> appended to U-Boot >> - OF_EMBED - for development purposes, the devicetree is embedded in >> the ELF file (also used for EFI) >> - OF_BOARD - the board figures it out on its own >> >> The last one is currently set up so that no devicetree is needed at all >> in the U-Boot tree. Most boards do provide one, but some don't. Some >> don't even provide instructions on how to boot on the board. >> >> The problems with this approach are documented in another patch in this >> series: "doc: Add documentation about devicetree usage" >> >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board >> can obtain its devicetree at runtime, even it is has a devicetree built >> in U-Boot. This is because U-Boot may be a second-stage bootloader and its >> caller may have a better idea about the hardware available in the machine. >> This is the case with a few QEMU boards, for example. >> >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an >> option, available with either OF_SEPARATE or OF_EMBED. >> >> This series makes this change, adding various missing devicetree files >> (and placeholders) to make the build work. >> >> Note: If board maintainers are able to add their own patch to add the >> files, some patches in this series can be dropped. >> >> It also provides a few qemu clean-ups discovered along the way. The >> qemu-riscv64_spl problem is fixed. >> >> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ >> >> Changes in v6: >> - Fix description of OF_BOARD so it refers just to the current state >> - Explain that the 'two devicetrees' refers to two *control* devicetrees >> - Expand the commit message based on comments >> - Expand the commit message based on comments > > You haven’t addressed any concerns expressed on the mailing list.so I am not in favor of this new version either. Please see the change log. I have addressed everything except the fundamental disagreement we have. > If you make a version without « fake DTs » as you name them, there are good advances in the documentation and other areas that would be better in mainline…. > If I am the only one thinking this way and the patch can be accepted, I would love there is a warning in capital letters at the top of the DTS fake files that explains the intent of this fake DT, the possible outcomes of not using the one provided by the platform and the right way of dealing with DTs for the platform. The word 'fake' applies to only three of the boards (highbank, bcm7xxx and octeontx), where I could not even figure out where to get a devicetree. One might think this would be a significant problem! Anyway yes I can add a comment to all the files, but please try to ask for everything at once as there is a cost to continually reworking this series. Regards, Simon >> >> >> Changes in v5: >> - Bring into the OF_BOARD series >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed >> - Refer to the 'control' DTB in the first paragraph >> - Use QEMU instead of qemu >> - Merge RISC-V and ARM patches since they are similar >> - Add new patches to clean up fdtdec_setup() and surrounds >> >> Changes in v3: >> - Clarify the 'bug' refered to at the top >> - Reword 'This means that there' paragraph to explain U-Boot-specific things >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs >> >> Changes in v2: >> - Fix typos per Sean (thank you!) and a few others >> - Add a 'Use of U-Boot /config node' section >> - Drop mention of dm-verity since that actually uses the kernel cmdline >> - Explain that OF_BOARD will still work after these changes (in >> 'Once this bug is fixed...' paragraph) >> - Expand a bit on the reason why the 'Current situation' is bad >> - Clarify in a second place that Linux and U-Boot use the same devicetree >> in 'To be clear, while U-Boot...' >> - Expand on why we should have rules for other projects in >> 'Devicetree in another project' >> - Add a comment as to why devicetree in U-Boot is not 'bad design' >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover >> points raised on v1 >> - Add 'Why does U-Boot have its nodes and properties?' >> - Add 'Why not have two devicetrees?' >> >> Simon Glass (25): >> doc: Add documentation about devicetree usage >> arm: qemu: Mention -nographic in the docs >> arm: riscv: qemu: Explain how to extract the generated dt >> arm: qemu: Add a devicetree file for qemu_arm >> arm: qemu: Add a devicetree file for qemu_arm64 >> riscv: qemu: Add devicetree files for qemu_riscv32/64 >> arm: rpi: Add a devicetree file for rpi_4 >> arm: vexpress: Add a devicetree file for juno >> arm: xenguest_arm64: Add a fake devicetree file >> arm: octeontx: Add a fake devicetree file >> arm: xilinx_versal_virt: Add a devicetree file >> arm: bcm7xxx: Add a devicetree file >> arm: qemu-ppce500: Add a devicetree file >> arm: highbank: Add a fake devicetree file >> fdt: Make OF_BOARD a bool option >> Drop CONFIG_BINMAN_STANDALONE_FDT >> doc: Update info on devicetree update >> fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() >> fdt: Drop #ifdefs with MULTI_DTB_FIT >> fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() >> fdt: Drop #ifdef around board_fdt_blob_setup() >> fdt: Use if() for fdtcontroladdr check >> fdt: Drop OF_CONTROL check in fdtdec_setup() >> fdt: Drop remaining preprocessor macros in fdtdec_setup() >> fdt: Don't call board_fdt_blob_setup() without OF_BOARD >> >> Makefile | 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 | 2 +- >> configs/xilinx_versal_virt_defconfig | 1 + >> doc/board/emulation/qemu-arm.rst | 10 +- >> doc/board/emulation/qemu-riscv.rst | 3 + >> doc/develop/devicetree/dt_qemu.rst | 48 + >> doc/develop/devicetree/dt_update.rst | 497 ++++++ >> doc/develop/devicetree/index.rst | 2 + >> dts/Kconfig | 30 +- >> include/asm-generic/global_data.h | 8 + >> include/fdtdec.h | 21 +- >> lib/fdtdec.c | 117 +- >> tools/binman/binman.rst | 20 - >> 49 files changed, 5538 insertions(+), 124 deletions(-) >> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts >> create mode 100644 arch/arm/dts/bcm7xxx.dts >> create mode 100644 arch/arm/dts/highbank.dts >> create mode 100644 arch/arm/dts/juno-r2.dts >> create mode 100644 arch/arm/dts/octeontx.dts >> create mode 100644 arch/arm/dts/qemu-arm.dts >> create mode 100644 arch/arm/dts/qemu-arm64.dts >> create mode 100644 arch/arm/dts/xenguest-arm64.dts >> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts >> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts >> delete mode 100644 arch/riscv/dts/qemu-virt.dts >> create mode 100644 arch/riscv/dts/qemu-virt32.dts >> create mode 100644 arch/riscv/dts/qemu-virt64.dts >> create mode 100644 doc/develop/devicetree/dt_qemu.rst >> create mode 100644 doc/develop/devicetree/dt_update.rst >> >> -- >> 2.34.0.rc2.393.gf8c9666880-goog >> > -- > François-Frédéric Ozog | Director Business Development > T: +33.67221.6485 > francois.ozog@linaro.org | Skype: ffozog >
On 12/2/21 16:58, 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 in another patch in this > series: "doc: Add documentation about devicetree usage" > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > can obtain its devicetree at runtime, even it is has a devicetree built > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > caller may have a better idea about the hardware available in the machine. > This is the case with a few QEMU boards, for example. > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > option, available with either OF_SEPARATE or OF_EMBED. > > This series makes this change, adding various missing devicetree files > (and placeholders) to make the build work. > > Note: If board maintainers are able to add their own patch to add the > files, some patches in this series can be dropped. > > It also provides a few qemu clean-ups discovered along the way. The > qemu-riscv64_spl problem is fixed. Distros like Ubuntu are provided as preinstalled images using U-Boot to launch Linux for usage with QEMU. A single image must be able to be usable in the future irrespective of the QEMU command line device configuration. This means that the devicetree coming from QEMU must be accurately parsed in U-Boot to setup the UEFI memory map. The number and type of CPUs and the NUMA configuration must be accurate. All devices enabled via the QEMU command line must be visible in the device-tree of Linux. Please, observe that information like number of CPU cores, number and type of block devices, namespace IDs used for NVMe drives, etc. cannot be available at build time. It this all guaranteed with this series? If not, this would unfortunately imply a NAK. Best regards Heinrich > > [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > Changes in v6: > - Fix description of OF_BOARD so it refers just to the current state > - Explain that the 'two devicetrees' refers to two *control* devicetrees > - Expand the commit message based on comments > - Expand the commit message based on comments > > Changes in v5: > - Bring into the OF_BOARD series > - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > - Refer to the 'control' DTB in the first paragraph > - Use QEMU instead of qemu > - Merge RISC-V and ARM patches since they are similar > - Add new patches to clean up fdtdec_setup() and surrounds > > Changes in v3: > - Clarify the 'bug' refered to at the top > - Reword 'This means that there' paragraph to explain U-Boot-specific things > - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > > Changes in v2: > - Fix typos per Sean (thank you!) and a few others > - Add a 'Use of U-Boot /config node' section > - Drop mention of dm-verity since that actually uses the kernel cmdline > - Explain that OF_BOARD will still work after these changes (in > 'Once this bug is fixed...' paragraph) > - Expand a bit on the reason why the 'Current situation' is bad > - Clarify in a second place that Linux and U-Boot use the same devicetree > in 'To be clear, while U-Boot...' > - Expand on why we should have rules for other projects in > 'Devicetree in another project' > - Add a comment as to why devicetree in U-Boot is not 'bad design' > - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > - Rewrite 'Devicetree generated on-the-fly in another project' to cover > points raised on v1 > - Add 'Why does U-Boot have its nodes and properties?' > - Add 'Why not have two devicetrees?' > > Simon Glass (25): > doc: Add documentation about devicetree usage > arm: qemu: Mention -nographic in the docs > arm: riscv: qemu: Explain how to extract the generated dt > arm: qemu: Add a devicetree file for qemu_arm > arm: qemu: Add a devicetree file for qemu_arm64 > riscv: qemu: Add devicetree files for qemu_riscv32/64 > arm: rpi: Add a devicetree file for rpi_4 > arm: vexpress: Add a devicetree file for juno > arm: xenguest_arm64: Add a fake devicetree file > arm: octeontx: Add a fake devicetree file > arm: xilinx_versal_virt: Add a devicetree file > arm: bcm7xxx: Add a devicetree file > arm: qemu-ppce500: Add a devicetree file > arm: highbank: Add a fake devicetree file > fdt: Make OF_BOARD a bool option > Drop CONFIG_BINMAN_STANDALONE_FDT > doc: Update info on devicetree update > fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() > fdt: Drop #ifdefs with MULTI_DTB_FIT > fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() > fdt: Drop #ifdef around board_fdt_blob_setup() > fdt: Use if() for fdtcontroladdr check > fdt: Drop OF_CONTROL check in fdtdec_setup() > fdt: Drop remaining preprocessor macros in fdtdec_setup() > fdt: Don't call board_fdt_blob_setup() without OF_BOARD > > Makefile | 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 | 2 +- > configs/xilinx_versal_virt_defconfig | 1 + > doc/board/emulation/qemu-arm.rst | 10 +- > doc/board/emulation/qemu-riscv.rst | 3 + > doc/develop/devicetree/dt_qemu.rst | 48 + > doc/develop/devicetree/dt_update.rst | 497 ++++++ > doc/develop/devicetree/index.rst | 2 + > dts/Kconfig | 30 +- > include/asm-generic/global_data.h | 8 + > include/fdtdec.h | 21 +- > lib/fdtdec.c | 117 +- > tools/binman/binman.rst | 20 - > 49 files changed, 5538 insertions(+), 124 deletions(-) > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > create mode 100644 arch/arm/dts/bcm7xxx.dts > create mode 100644 arch/arm/dts/highbank.dts > create mode 100644 arch/arm/dts/juno-r2.dts > create mode 100644 arch/arm/dts/octeontx.dts > create mode 100644 arch/arm/dts/qemu-arm.dts > create mode 100644 arch/arm/dts/qemu-arm64.dts > create mode 100644 arch/arm/dts/xenguest-arm64.dts > create mode 100644 arch/arm/dts/xilinx-versal-virt.dts > create mode 100644 arch/powerpc/dts/qemu-ppce500.dts > delete mode 100644 arch/riscv/dts/qemu-virt.dts > create mode 100644 arch/riscv/dts/qemu-virt32.dts > create mode 100644 arch/riscv/dts/qemu-virt64.dts > create mode 100644 doc/develop/devicetree/dt_qemu.rst > create mode 100644 doc/develop/devicetree/dt_update.rst >
Hi Tom, On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > Hi Simon > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > there are only three ways to obtain a devicetree: > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > appended to U-Boot > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > the ELF file (also used for EFI) > > > - OF_BOARD - the board figures it out on its own > > > > > > The last one is currently set up so that no devicetree is needed at all > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > don't even provide instructions on how to boot on the board. > > > > > > The problems with this approach are documented in another patch in this > > > series: "doc: Add documentation about devicetree usage" > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > caller may have a better idea about the hardware available in the machine. > > > This is the case with a few QEMU boards, for example. > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > This series makes this change, adding various missing devicetree files > > > (and placeholders) to make the build work. > > > > > > Note: If board maintainers are able to add their own patch to add the > > > files, some patches in this series can be dropped. > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > qemu-riscv64_spl problem is fixed. > > > > > > [1] > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > Changes in v6: > > > - Fix description of OF_BOARD so it refers just to the current state > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > - Expand the commit message based on comments > > > - Expand the commit message based on comments > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > not in favor of this new version either. > > If you make a version without « fake DTs » as you name them, there are good > > advances in the documentation and other areas that would be better in > > mainline…. > > If I am the only one thinking this way and the patch can be accepted, I > > would love there is a warning in capital letters at the top of the DTS fake > > files that explains the intent of this fake DT, the possible outcomes of > > not using the one provided by the platform and the right way of dealing > > with DTs for the platform. > > This is the part that I too am still unhappy about. I do not want > reference or fake or whatever device trees in the U-Boot source tree. > We should be able to _remove_ the ones we have, that are not required, > with doc/board/...rst explaining how to get / view one. Not adding > more. I understand you don't like it and that others don't as well. I wish it had not come to this. However we are only talking about 10 boards, three of which don't even have a devicetree anywhere I can find. I think on balance this is a substantial clean-up. I am happy to add whatever caveats and documentation people want to clarify what is going on here. I'm happy to look at future options where the devicetree is hosted elsewhere, so long as it is trivial to build it within U-Boot for development purposes. I'll also note that the bootstd series shows the devicetree source: Core: 246 devices, 88 uclasses, devicetree: board But for now, I still feel this is the best path forward. Regards, Simon
Hi Heinrich, On Thu, 2 Dec 2021 at 09:47, Heinrich Schuchardt <heinrich.schuchardt@canonical.com> wrote: > > On 12/2/21 16:58, 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 in another patch in this > > series: "doc: Add documentation about devicetree usage" > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > can obtain its devicetree at runtime, even it is has a devicetree built > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > caller may have a better idea about the hardware available in the machine. > > This is the case with a few QEMU boards, for example. > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > option, available with either OF_SEPARATE or OF_EMBED. > > > > This series makes this change, adding various missing devicetree files > > (and placeholders) to make the build work. > > > > Note: If board maintainers are able to add their own patch to add the > > files, some patches in this series can be dropped. > > > > It also provides a few qemu clean-ups discovered along the way. The > > qemu-riscv64_spl problem is fixed. > > Distros like Ubuntu are provided as preinstalled images using U-Boot to > launch Linux for usage with QEMU. A single image must be able to be > usable in the future irrespective of the QEMU command line device > configuration. > > This means that the devicetree coming from QEMU must be accurately > parsed in U-Boot to setup the UEFI memory map. The number and type of > CPUs and the NUMA configuration must be accurate. All devices enabled > via the QEMU command line must be visible in the device-tree of Linux. > > Please, observe that information like number of CPU cores, number and > type of block devices, namespace IDs used for NVMe drives, etc. cannot > be available at build time. > > It this all guaranteed with this series? If not, this would > unfortunately imply a NAK. Yes, it is guaranteed and there is no change there. Regards, Simon
On Thu, 2 Dec 2021 at 16:40, Simon Glass <sjg@chromium.org> wrote: > The word 'fake' applies to only three of the boards (highbank, bcm7xxx > and octeontx), where I could not even figure out where to get a > devicetree. One might think this would be a significant problem! Isn't highbank https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/highbank.dts ? -- PMM
Hi Simon Le jeu. 2 déc. 2021 à 17:40, Simon Glass <sjg@chromium.org> a écrit : > Hi François, > > On Thu, 2 Dec 2021 at 09:34, François Ozog <francois.ozog@linaro.org> > wrote: > > > > Hi Simon > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > >> > >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > >> there are only three ways to obtain a devicetree: > >> > >> - OF_SEPARATE - the normal way, where the devicetree is built and > >> appended to U-Boot > >> - OF_EMBED - for development purposes, the devicetree is embedded in > >> the ELF file (also used for EFI) > >> - OF_BOARD - the board figures it out on its own > >> > >> The last one is currently set up so that no devicetree is needed at all > >> in the U-Boot tree. Most boards do provide one, but some don't. Some > >> don't even provide instructions on how to boot on the board. > >> > >> The problems with this approach are documented in another patch in this > >> series: "doc: Add documentation about devicetree usage" > >> > >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > >> can obtain its devicetree at runtime, even it is has a devicetree built > >> in U-Boot. This is because U-Boot may be a second-stage bootloader and > its > >> caller may have a better idea about the hardware available in the > machine. > >> This is the case with a few QEMU boards, for example. > >> > >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an > >> option, available with either OF_SEPARATE or OF_EMBED. > >> > >> This series makes this change, adding various missing devicetree files > >> (and placeholders) to make the build work. > >> > >> Note: If board maintainers are able to add their own patch to add the > >> files, some patches in this series can be dropped. > >> > >> It also provides a few qemu clean-ups discovered along the way. The > >> qemu-riscv64_spl problem is fixed. > >> > >> [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > >> > >> Changes in v6: > >> - Fix description of OF_BOARD so it refers just to the current state > >> - Explain that the 'two devicetrees' refers to two *control* devicetrees > >> - Expand the commit message based on comments > >> - Expand the commit message based on comments > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > not in favor of this new version either. > > Please see the change log. I have addressed everything except the > fundamental disagreement we have. > > > If you make a version without « fake DTs » as you name them, there are > good advances in the documentation and other areas that would be better in > mainline…. > > If I am the only one thinking this way and the patch can be accepted, I > would love there is a warning in capital letters at the top of the DTS fake > files that explains the intent of this fake DT, the possible outcomes of > not using the one provided by the platform and the right way of dealing > with DTs for the platform. > > The word 'fake' applies to only three of the boards (highbank, bcm7xxx > and octeontx), Qemu is another one, and then you will have all SystemReady compliant boards. > where I could not even figure out where to get a > devicetree. One might think this would be a significant problem! > > Anyway yes I can add a comment to all the files, but please try to ask > for everything at once as there is a cost to continually reworking > this series. I proposed this as a last resort if I was the only one with concerns. But sounds like I am not the only one strongly opinionated here. Another trick would be to use a “.dts.doc” extension so that it is not compiled unless someone is knowingly deciding to use the fake DT for debug purposes (the warning message is still valid). (This is an effort to advance on the good things of the patch) > > > Regards, > Simon > > >> > >> > >> Changes in v5: > >> - Bring into the OF_BOARD series > >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > >> - Refer to the 'control' DTB in the first paragraph > >> - Use QEMU instead of qemu > >> - Merge RISC-V and ARM patches since they are similar > >> - Add new patches to clean up fdtdec_setup() and surrounds > >> > >> Changes in v3: > >> - Clarify the 'bug' refered to at the top > >> - Reword 'This means that there' paragraph to explain U-Boot-specific > things > >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > >> > >> Changes in v2: > >> - Fix typos per Sean (thank you!) and a few others > >> - Add a 'Use of U-Boot /config node' section > >> - Drop mention of dm-verity since that actually uses the kernel cmdline > >> - Explain that OF_BOARD will still work after these changes (in > >> 'Once this bug is fixed...' paragraph) > >> - Expand a bit on the reason why the 'Current situation' is bad > >> - Clarify in a second place that Linux and U-Boot use the same > devicetree > >> in 'To be clear, while U-Boot...' > >> - Expand on why we should have rules for other projects in > >> 'Devicetree in another project' > >> - Add a comment as to why devicetree in U-Boot is not 'bad design' > >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover > >> points raised on v1 > >> - Add 'Why does U-Boot have its nodes and properties?' > >> - Add 'Why not have two devicetrees?' > >> > >> Simon Glass (25): > >> doc: Add documentation about devicetree usage > >> arm: qemu: Mention -nographic in the docs > >> arm: riscv: qemu: Explain how to extract the generated dt > >> arm: qemu: Add a devicetree file for qemu_arm > >> arm: qemu: Add a devicetree file for qemu_arm64 > >> riscv: qemu: Add devicetree files for qemu_riscv32/64 > >> arm: rpi: Add a devicetree file for rpi_4 > >> arm: vexpress: Add a devicetree file for juno > >> arm: xenguest_arm64: Add a fake devicetree file > >> arm: octeontx: Add a fake devicetree file > >> arm: xilinx_versal_virt: Add a devicetree file > >> arm: bcm7xxx: Add a devicetree file > >> arm: qemu-ppce500: Add a devicetree file > >> arm: highbank: Add a fake devicetree file > >> fdt: Make OF_BOARD a bool option > >> Drop CONFIG_BINMAN_STANDALONE_FDT > >> doc: Update info on devicetree update > >> fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() > >> fdt: Drop #ifdefs with MULTI_DTB_FIT > >> fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() > >> fdt: Drop #ifdef around board_fdt_blob_setup() > >> fdt: Use if() for fdtcontroladdr check > >> fdt: Drop OF_CONTROL check in fdtdec_setup() > >> fdt: Drop remaining preprocessor macros in fdtdec_setup() > >> fdt: Don't call board_fdt_blob_setup() without OF_BOARD > >> > >> Makefile | 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 | 2 +- > >> configs/xilinx_versal_virt_defconfig | 1 + > >> doc/board/emulation/qemu-arm.rst | 10 +- > >> doc/board/emulation/qemu-riscv.rst | 3 + > >> doc/develop/devicetree/dt_qemu.rst | 48 + > >> doc/develop/devicetree/dt_update.rst | 497 ++++++ > >> doc/develop/devicetree/index.rst | 2 + > >> dts/Kconfig | 30 +- > >> include/asm-generic/global_data.h | 8 + > >> include/fdtdec.h | 21 +- > >> lib/fdtdec.c | 117 +- > >> tools/binman/binman.rst | 20 - > >> 49 files changed, 5538 insertions(+), 124 deletions(-) > >> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > >> create mode 100644 arch/arm/dts/bcm7xxx.dts > >> create mode 100644 arch/arm/dts/highbank.dts > >> create mode 100644 arch/arm/dts/juno-r2.dts > >> create mode 100644 arch/arm/dts/octeontx.dts > >> create mode 100644 arch/arm/dts/qemu-arm.dts > >> create mode 100644 arch/arm/dts/qemu-arm64.dts > >> create mode 100644 arch/arm/dts/xenguest-arm64.dts > >> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts > >> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts > >> delete mode 100644 arch/riscv/dts/qemu-virt.dts > >> create mode 100644 arch/riscv/dts/qemu-virt32.dts > >> create mode 100644 arch/riscv/dts/qemu-virt64.dts > >> create mode 100644 doc/develop/devicetree/dt_qemu.rst > >> create mode 100644 doc/develop/devicetree/dt_update.rst > >> > >> -- > >> 2.34.0.rc2.393.gf8c9666880-goog > >> > > -- > > François-Frédéric Ozog | Director Business Development > > T: +33.67221.6485 > > francois.ozog@linaro.org | Skype: ffozog > > >
On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > Hi Simon > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > there are only three ways to obtain a devicetree: > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > appended to U-Boot > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > the ELF file (also used for EFI) > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > don't even provide instructions on how to boot on the board. > > > > > > > > The problems with this approach are documented in another patch in this > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > caller may have a better idea about the hardware available in the machine. > > > > This is the case with a few QEMU boards, for example. > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > This series makes this change, adding various missing devicetree files > > > > (and placeholders) to make the build work. > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > files, some patches in this series can be dropped. > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > [1] > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > Changes in v6: > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > - Expand the commit message based on comments > > > > - Expand the commit message based on comments > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > not in favor of this new version either. > > > If you make a version without « fake DTs » as you name them, there are good > > > advances in the documentation and other areas that would be better in > > > mainline…. > > > If I am the only one thinking this way and the patch can be accepted, I > > > would love there is a warning in capital letters at the top of the DTS fake > > > files that explains the intent of this fake DT, the possible outcomes of > > > not using the one provided by the platform and the right way of dealing > > > with DTs for the platform. > > > > This is the part that I too am still unhappy about. I do not want > > reference or fake or whatever device trees in the U-Boot source tree. > > We should be able to _remove_ the ones we have, that are not required, > > with doc/board/...rst explaining how to get / view one. Not adding > > more. > > I understand you don't like it and that others don't as well. I wish > it had not come to this. > > However we are only talking about 10 boards, three of which don't even > have a devicetree anywhere I can find. > > I think on balance this is a substantial clean-up. I am happy to add > whatever caveats and documentation people want to clarify what is > going on here. I'm happy to look at future options where the > devicetree is hosted elsewhere, so long as it is trivial to build it > within U-Boot for development purposes. > > I'll also note that the bootstd series shows the devicetree source: > > Core: 246 devices, 88 uclasses, devicetree: board > > But for now, I still feel this is the best path forward. I'm not sure how to proceed here. The reviews are rather strongly against the "include a device tree that won't be used". The use case of "but for development someone might need to modify the device tree" is handled by platforms documenting where / how to get the real one. We should even update the Kconfig help to note that if you enable this your board docs MUST explain where the device tree can be seen (or have some legal reason you think it's OK to not...). And yes, we're "only" talking about 10 platforms, which include things like the "everyone" has one Pi family, the extraordinarily flexible (and so easy for the reference device tree to be very wrong) QEMU families and then platforms that are including a dts in-tree now because they were told that was required. How about adjusting the make logic so that if a tree isn't found, we use a dummy minimal valid dts file?
On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > Hi Simon > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > there are only three ways to obtain a devicetree: > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > appended to U-Boot > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > the ELF file (also used for EFI) > > > - OF_BOARD - the board figures it out on its own > > > > > > The last one is currently set up so that no devicetree is needed at all > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > don't even provide instructions on how to boot on the board. > > > > > > The problems with this approach are documented in another patch in this > > > series: "doc: Add documentation about devicetree usage" > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > caller may have a better idea about the hardware available in the machine. > > > This is the case with a few QEMU boards, for example. > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > This series makes this change, adding various missing devicetree files > > > (and placeholders) to make the build work. > > > > > > Note: If board maintainers are able to add their own patch to add the > > > files, some patches in this series can be dropped. > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > qemu-riscv64_spl problem is fixed. > > > > > > [1] > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > Changes in v6: > > > - Fix description of OF_BOARD so it refers just to the current state > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > - Expand the commit message based on comments > > > - Expand the commit message based on comments > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > not in favor of this new version either. > > If you make a version without « fake DTs » as you name them, there are good > > advances in the documentation and other areas that would be better in > > mainline…. > > If I am the only one thinking this way and the patch can be accepted, I > > would love there is a warning in capital letters at the top of the DTS fake > > files that explains the intent of this fake DT, the possible outcomes of > > not using the one provided by the platform and the right way of dealing > > with DTs for the platform. > > This is the part that I too am still unhappy about. I do not want > reference or fake or whatever device trees in the U-Boot source tree. > We should be able to _remove_ the ones we have, that are not required, > with doc/board/...rst explaining how to get / view one. Not adding > more. So this is a key point for me and the reason I completely disagree with this approach. This proposal is working in the *exact* opposite direction and we'll never be able to get rid of device trees from U-Boot, even if at some point they move out of the kernel to a 'common' repo'. I'll just repeat what I've been saying since v1. Personally I'd be way happier if we could figure out were the specific U-Boot config nodes are needed and when are they needed. Based on what we figure out we could, pick up the device tree from a previous state bootloader and fix it up with our special nodes before we start using it, using internal DTS files (compiled to .dtbos or similar) that indeed belong in the u-boot tree. Regards /Ilias > > -- > Tom
Hi Tom, On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > appended to U-Boot > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > the ELF file (also used for EFI) > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > caller may have a better idea about the hardware available in the machine. > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > (and placeholders) to make the build work. > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > files, some patches in this series can be dropped. > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > [1] > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there are good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > not using the one provided by the platform and the right way of dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > I understand you don't like it and that others don't as well. I wish > > it had not come to this. > > > > However we are only talking about 10 boards, three of which don't even > > have a devicetree anywhere I can find. > > > > I think on balance this is a substantial clean-up. I am happy to add > > whatever caveats and documentation people want to clarify what is > > going on here. I'm happy to look at future options where the > > devicetree is hosted elsewhere, so long as it is trivial to build it > > within U-Boot for development purposes. > > > > I'll also note that the bootstd series shows the devicetree source: > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > But for now, I still feel this is the best path forward. > > I'm not sure how to proceed here. The reviews are rather strongly > against the "include a device tree that won't be used". The use case of > "but for development someone might need to modify the device tree" is > handled by platforms documenting where / how to get the real one. We > should even update the Kconfig help to note that if you enable this your > board docs MUST explain where the device tree can be seen (or have some > legal reason you think it's OK to not...). Right, we can do lots of things as we have discussed. I am very willing to work on these and make sure it is hard to do the thing. But this series is long enough already. It is more than just development. A devicetree is needed for binman to work, even if it is empty. The documentation idea doesn't really work, as I think I have proven by the difficulty in getting this series together. An automated mechanism that runs in CI might be acceptable, but that is in the future. For now, I believe it just HAS to be in-tree. > > And yes, we're "only" talking about 10 platforms, which include things > like the "everyone" has one Pi family, the extraordinarily flexible (and > so easy for the reference device tree to be very wrong) QEMU families > and then platforms that are including a dts in-tree now because they > were told that was required. Actually it is only rpi4 that doesn't have an in-tree DT. There is actually no reason for it not to, e.g. Linux has it. Why not U-Boot? The argument is the same. Most QEMU boards have an in-tree devicetree. It is only ARM (now copied by RISC-V) which doesn't. > > How about adjusting the make logic so that if a tree isn't found, we use > a dummy minimal valid dts file? This is what I have done for the boards where I could not figure out how to get any sort of DT, yes. But I don't think that should be the default. Regards, Simon
Hi Ilias, On Thu, 2 Dec 2021 at 10:04, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > Hi Simon > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > there are only three ways to obtain a devicetree: > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > appended to U-Boot > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > the ELF file (also used for EFI) > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > don't even provide instructions on how to boot on the board. > > > > > > > > The problems with this approach are documented in another patch in this > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > caller may have a better idea about the hardware available in the machine. > > > > This is the case with a few QEMU boards, for example. > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > This series makes this change, adding various missing devicetree files > > > > (and placeholders) to make the build work. > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > files, some patches in this series can be dropped. > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > [1] > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > Changes in v6: > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > - Expand the commit message based on comments > > > > - Expand the commit message based on comments > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > not in favor of this new version either. > > > If you make a version without « fake DTs » as you name them, there are good > > > advances in the documentation and other areas that would be better in > > > mainline…. > > > If I am the only one thinking this way and the patch can be accepted, I > > > would love there is a warning in capital letters at the top of the DTS fake > > > files that explains the intent of this fake DT, the possible outcomes of > > > not using the one provided by the platform and the right way of dealing > > > with DTs for the platform. > > > > This is the part that I too am still unhappy about. I do not want > > reference or fake or whatever device trees in the U-Boot source tree. > > We should be able to _remove_ the ones we have, that are not required, > > with doc/board/...rst explaining how to get / view one. Not adding > > more. > > So this is a key point for me and the reason I completely disagree > with this approach. This proposal is working in the *exact* opposite > direction and we'll never be able to get rid of device trees from > U-Boot, even if at some point they move out of the kernel to a > 'common' repo'. I'll just repeat what I've been saying since v1. > Personally I'd be way happier if we could figure out were the specific > U-Boot config nodes are needed and when are they needed. Based on > what we figure out we could, pick up the device tree from a previous > state bootloader and fix it up with our special nodes before we start > using it, using internal DTS files (compiled to .dtbos or similar) > that indeed belong in the u-boot tree. Eh? If the device tree files are actually common then there should be a single source. If U-Boot has a copy then it should be identical. The special node thing makes no sense for U-Boot. We just need to upstream our bindings and I am working on that. Are the device tree files moving out of Linux? Regards, Simon
On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > Hi Simon > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > appended to U-Boot > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > the ELF file (also used for EFI) > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > [1] > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > Changes in v6: > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > - Expand the commit message based on comments > > > > > > - Expand the commit message based on comments > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > not in favor of this new version either. > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > advances in the documentation and other areas that would be better in > > > > > mainline…. > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > not using the one provided by the platform and the right way of dealing > > > > > with DTs for the platform. > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > We should be able to _remove_ the ones we have, that are not required, > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > more. > > > > > > I understand you don't like it and that others don't as well. I wish > > > it had not come to this. > > > > > > However we are only talking about 10 boards, three of which don't even > > > have a devicetree anywhere I can find. > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > whatever caveats and documentation people want to clarify what is > > > going on here. I'm happy to look at future options where the > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > within U-Boot for development purposes. > > > > > > I'll also note that the bootstd series shows the devicetree source: > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > But for now, I still feel this is the best path forward. > > > > I'm not sure how to proceed here. The reviews are rather strongly > > against the "include a device tree that won't be used". The use case of > > "but for development someone might need to modify the device tree" is > > handled by platforms documenting where / how to get the real one. We > > should even update the Kconfig help to note that if you enable this your > > board docs MUST explain where the device tree can be seen (or have some > > legal reason you think it's OK to not...). > > Right, we can do lots of things as we have discussed. I am very > willing to work on these and make sure it is hard to do the thing. But > this series is long enough already. Yes, I think the rest of us had hoped you would come around to all of our reasoning by this point, is why this is taking so long. > It is more than just development. A devicetree is needed for binman to > work, even if it is empty. The documentation idea doesn't really work, > as I think I have proven by the difficulty in getting this series > together. An automated mechanism that runs in CI might be acceptable, > but that is in the future. For now, I believe it just HAS to be > in-tree. I still don't see any reason why we need these incorrect and not functionally used device trees in-tree when a dummy invalid tree is enough to make things link. We're dealing with real "we must have X.bin in the output for things to function" issues on other platforms with binman right now. Using a dummy dts should be fine. > > And yes, we're "only" talking about 10 platforms, which include things > > like the "everyone" has one Pi family, the extraordinarily flexible (and > > so easy for the reference device tree to be very wrong) QEMU families > > and then platforms that are including a dts in-tree now because they > > were told that was required. > > Actually it is only rpi4 that doesn't have an in-tree DT. There is > actually no reason for it not to, e.g. Linux has it. Why not U-Boot? > The argument is the same. Because we don't need it! It serves no purpose! It exists in Linux as that's the primary device tree source repository. We could _copy_ it in, if it was useful. But then we need to re-sync it every so often, and for less clear reasons than all of the platforms that we need to sync with the kernel for, AND we use the tree. There's even an argument to be made that it IS in Linux because when you build that dtb, it's what the firmware then ships and uses and provides to everyone at run time, possibly along with whatever other modifications the binary firmware did (see the assorted threads, including one this week about the problems we have because we don't just always use the dtb provided to us at run time). > Most QEMU boards have an in-tree devicetree. It is only ARM (now > copied by RISC-V) which doesn't. Yes, these are more examples of "someone said we need to copy it in, so we copy it in". > > How about adjusting the make logic so that if a tree isn't found, we use > > a dummy minimal valid dts file? > > This is what I have done for the boards where I could not figure out > how to get any sort of DT, yes. But I don't think that should be the > default. The more I think about this, the more I think dummy minimal valid dts should be the fall-back default. This then solves the "I'm a developer, I need to modify the dts files" case because you then just provide the dts instead where it should go, and it's used.
> From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > Hi Simon > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > there are only three ways to obtain a devicetree: > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > appended to U-Boot > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > the ELF file (also used for EFI) > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > don't even provide instructions on how to boot on the board. > > > > > > > > The problems with this approach are documented in another patch in this > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > caller may have a better idea about the hardware available in the machine. > > > > This is the case with a few QEMU boards, for example. > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > This series makes this change, adding various missing devicetree files > > > > (and placeholders) to make the build work. > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > files, some patches in this series can be dropped. > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > [1] > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > Changes in v6: > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > - Expand the commit message based on comments > > > > - Expand the commit message based on comments > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > not in favor of this new version either. > > > If you make a version without « fake DTs » as you name them, there are good > > > advances in the documentation and other areas that would be better in > > > mainline…. > > > If I am the only one thinking this way and the patch can be accepted, I > > > would love there is a warning in capital letters at the top of the DTS fake > > > files that explains the intent of this fake DT, the possible outcomes of > > > not using the one provided by the platform and the right way of dealing > > > with DTs for the platform. > > > > This is the part that I too am still unhappy about. I do not want > > reference or fake or whatever device trees in the U-Boot source tree. > > We should be able to _remove_ the ones we have, that are not required, > > with doc/board/...rst explaining how to get / view one. Not adding > > more. > > So this is a key point for me and the reason I completely disagree > with this approach. This proposal is working in the *exact* opposite > direction and we'll never be able to get rid of device trees from > U-Boot, even if at some point they move out of the kernel to a > 'common' repo'. I'll just repeat what I've been saying since v1. > Personally I'd be way happier if we could figure out were the specific > U-Boot config nodes are needed and when are they needed. Based on > what we figure out we could, pick up the device tree from a previous > state bootloader and fix it up with our special nodes before we start > using it, using internal DTS files (compiled to .dtbos or similar) > that indeed belong in the u-boot tree. I don't think it makes sense to put stuff in the DT that is specific for U-Boot only to pull it out moments later. Maybe it does make some sense to do this to pass information between TPL/SPL and U-Boot proper. But otherwise you can just use global variables... Now I just ran into an issue on Apple M1 that may have some relevance here. I'm adding support for power domains and the serial port requires certain power domains to be on. Since the serial port is initialized in the pre-relocation phase this means that the device tree nodes for the power domain controllers need to have the "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't be able to bind the power domain controller driver in this phase and binding the serial port driver itself will fail. Which makes U-Boot hang without any visible output on the serial console. Within the Asahi Linux group we're currently discussing how to solve this. We could just add the "u-boot,dm-pre-reloc" properties in the device trees that we're going to distribute as part of m1n1 (the "bootloader" than embeds U-Boot). Or we can write some code that adds those properties to the device tree nodes that are dependencies for the serial port. I don't think the suggestion of applying an overlay embedded in U-Boot would work here. The code applying the overlay would need to run very early on in the pre-relocation phase. We'd also have to include overlays for all the models that Apple offers and pick the right one. And if a new model appears we can no longer just add a new device tree to m1n1. But maybe there is a case where the overlay approach would make sense...
Hi Tom, On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > Hi Simon > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > appended to U-Boot > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > the ELF file (also used for EFI) > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > [1] > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > Changes in v6: > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > - Expand the commit message based on comments > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > not in favor of this new version either. > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > advances in the documentation and other areas that would be better in > > > > > > mainline…. > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > with DTs for the platform. > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > more. > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > it had not come to this. > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > have a devicetree anywhere I can find. > > > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > > whatever caveats and documentation people want to clarify what is > > > > going on here. I'm happy to look at future options where the > > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > > within U-Boot for development purposes. > > > > > > > > I'll also note that the bootstd series shows the devicetree source: > > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > > > But for now, I still feel this is the best path forward. > > > > > > I'm not sure how to proceed here. The reviews are rather strongly > > > against the "include a device tree that won't be used". The use case of > > > "but for development someone might need to modify the device tree" is > > > handled by platforms documenting where / how to get the real one. We > > > should even update the Kconfig help to note that if you enable this your > > > board docs MUST explain where the device tree can be seen (or have some > > > legal reason you think it's OK to not...). > > > > Right, we can do lots of things as we have discussed. I am very > > willing to work on these and make sure it is hard to do the thing. But > > this series is long enough already. > > Yes, I think the rest of us had hoped you would come around to all of > our reasoning by this point, is why this is taking so long. > Look, if I thought this was all wrong I would not be doing it. We have a range of opinions: - U-Boot should not have its own nodes/properties - U-Boot should not have DTs in-tree - U-Boot should have DTs only when essential - U-Boot should have DTs in-tree for all boards What's the downside here anyway? > > It is more than just development. A devicetree is needed for binman to > > work, even if it is empty. The documentation idea doesn't really work, > > as I think I have proven by the difficulty in getting this series > > together. An automated mechanism that runs in CI might be acceptable, > > but that is in the future. For now, I believe it just HAS to be > > in-tree. > > I still don't see any reason why we need these incorrect and not > functionally used device trees in-tree when a dummy invalid tree is > enough to make things link. We're dealing with real "we must have X.bin > in the output for things to function" issues on other platforms with > binman right now. Using a dummy dts should be fine. Incorrect in what way? How do I get a real one for development? How do I turn off OF_BOARD and use the in-tree one? The documentation approach is not good enough. > > > > And yes, we're "only" talking about 10 platforms, which include things > > > like the "everyone" has one Pi family, the extraordinarily flexible (and > > > so easy for the reference device tree to be very wrong) QEMU families > > > and then platforms that are including a dts in-tree now because they > > > were told that was required. > > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot? > > The argument is the same. > > Because we don't need it! It serves no purpose! It exists in Linux > as that's the primary device tree source repository. We could _copy_ it > in, if it was useful. But then we need to re-sync it every so often, > and for less clear reasons than all of the platforms that we need to > sync with the kernel for, AND we use the tree. So some people don't need it and it serves no purpose for them. But why do they care? It is not hurting anyone. This is all overblown. > > There's even an argument to be made that it IS in Linux because when you > build that dtb, it's what the firmware then ships and uses and provides > to everyone at run time, possibly along with whatever other > modifications the binary firmware did (see the assorted threads, > including one this week about the problems we have because we don't just > always use the dtb provided to us at run time). > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now > > copied by RISC-V) which doesn't. > > Yes, these are more examples of "someone said we need to copy it in, so > we copy it in". No that's not correct. With x86, ppc, integrator, ast2500 and many others we *need* the DT and *it is not* created by QEMU. > > > > How about adjusting the make logic so that if a tree isn't found, we use > > > a dummy minimal valid dts file? > > > > This is what I have done for the boards where I could not figure out > > how to get any sort of DT, yes. But I don't think that should be the > > default. > > The more I think about this, the more I think dummy minimal valid dts > should be the fall-back default. This then solves the "I'm a developer, > I need to modify the dts files" case because you then just provide the > dts instead where it should go, and it's used. How does it solve it? I don't even know how to get it in many cases. If it is a dummy then I cannot actually use it for development, right? Regards, Simon
Hi Mark, On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > appended to U-Boot > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > the ELF file (also used for EFI) > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > caller may have a better idea about the hardware available in the machine. > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > (and placeholders) to make the build work. > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > files, some patches in this series can be dropped. > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > [1] > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there are good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > not using the one provided by the platform and the right way of dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm adding support for power domains and the serial port > requires certain power domains to be on. Since the serial port is > initialized in the pre-relocation phase this means that the device > tree nodes for the power domain controllers need to have the > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > be able to bind the power domain controller driver in this phase and > binding the serial port driver itself will fail. Which makes U-Boot > hang without any visible output on the serial console. > > Within the Asahi Linux group we're currently discussing how to solve > this. We could just add the "u-boot,dm-pre-reloc" properties in the > device trees that we're going to distribute as part of m1n1 (the > "bootloader" than embeds U-Boot). Or we can write some code that adds > those properties to the device tree nodes that are dependencies for > the serial port. > > I don't think the suggestion of applying an overlay embedded in U-Boot > would work here. The code applying the overlay would need to run very > early on in the pre-relocation phase. We'd also have to include > overlays for all the models that Apple offers and pick the right one. > And if a new model appears we can no longer just add a new device tree > to m1n1. Well put. > > But maybe there is a case where the overlay approach would make sense... There might be, but I haven't found it yet. BTW I suggest we figure out how to upstream the binding for this. I will see if I can send a patch to start the process. The last patch didn't get any comments though. In the interim there is probably no choice but to add the properties into the m1n1 project. Of course, for development, you could just turn off OF_BOARD, with my series applied. Which is a lot of the point of all of this discussion... Regards, Simon
On Thu, 2 Dec 2021 at 19:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit > : > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE > so > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built > and > > > > > appended to U-Boot > > > > > - OF_EMBED - for development purposes, the devicetree is > embedded in > > > > > the ELF file (also used for EFI) > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > The last one is currently set up so that no devicetree is needed > at all > > > > > in the U-Boot tree. Most boards do provide one, but some don't. > Some > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > The problems with this approach are documented in another patch in > this > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > board > > > > > can obtain its devicetree at runtime, even it is has a devicetree > built > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader > and its > > > > > caller may have a better idea about the hardware available in the > machine. > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be > an > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > This series makes this change, adding various missing devicetree > files > > > > > (and placeholders) to make the build work. > > > > > > > > > > Note: If board maintainers are able to add their own patch to add > the > > > > > files, some patches in this series can be dropped. > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > [1] > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current > state > > > > > - Explain that the 'two devicetrees' refers to two *control* > devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so > I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there > are good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be > accepted, I > > > > would love there is a warning in capital letters at the top of the > DTS fake > > > > files that explains the intent of this fake DT, the possible > outcomes of > > > > not using the one provided by the platform and the right way of > dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm adding support for power domains and the serial port > requires certain power domains to be on. Since the serial port is > initialized in the pre-relocation phase this means that the device > tree nodes for the power domain controllers need to have the > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > be able to bind the power domain controller driver in this phase and > binding the serial port driver itself will fail. Which makes U-Boot > hang without any visible output on the serial console. > > Does this hint at a bigger issue that DT shall be parsed and handled in the U-Boot process way early than it is today? Ilias reported a similar problem with TPM handling where you need to discover TPM very early to deal with it. There may be one early parse and two scans (one early, one normal enumeration) > Within the Asahi Linux group we're currently discussing how to solve > this. We could just add the "u-boot,dm-pre-reloc" properties in the > device trees that we're going to distribute as part of m1n1 (the > "bootloader" than embeds U-Boot). Or we can write some code that adds > those properties to the device tree nodes that are dependencies for > the serial port. > > I don't think the suggestion of applying an overlay embedded in U-Boot > would work here. The code applying the overlay would need to run very > early on in the pre-relocation phase. We'd also have to include > overlays for all the models that Apple offers and pick the right one. > And if a new model appears we can no longer just add a new device tree > to m1n1. > > But maybe there is a case where the overlay approach would make sense... >
On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > Hi Simon > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > > appended to U-Boot > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > > the ELF file (also used for EFI) > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > [1] > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > - Expand the commit message based on comments > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > not in favor of this new version either. > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > mainline…. > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > with DTs for the platform. > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > more. > > > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > > it had not come to this. > > > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > > have a devicetree anywhere I can find. > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > > > whatever caveats and documentation people want to clarify what is > > > > > going on here. I'm happy to look at future options where the > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > > > within U-Boot for development purposes. > > > > > > > > > > I'll also note that the bootstd series shows the devicetree source: > > > > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > > > > > But for now, I still feel this is the best path forward. > > > > > > > > I'm not sure how to proceed here. The reviews are rather strongly > > > > against the "include a device tree that won't be used". The use case of > > > > "but for development someone might need to modify the device tree" is > > > > handled by platforms documenting where / how to get the real one. We > > > > should even update the Kconfig help to note that if you enable this your > > > > board docs MUST explain where the device tree can be seen (or have some > > > > legal reason you think it's OK to not...). > > > > > > Right, we can do lots of things as we have discussed. I am very > > > willing to work on these and make sure it is hard to do the thing. But > > > this series is long enough already. > > > > Yes, I think the rest of us had hoped you would come around to all of > > our reasoning by this point, is why this is taking so long. > > > > Look, if I thought this was all wrong I would not be doing it. We have > a range of opinions: And the rest of us wouldn't keep trying to argue otherwise if we didn't see problems with it, still. > - U-Boot should not have its own nodes/properties The caveat there is that aren't documented upstream bindings. I think at this point the lack of screaming and otherwise "wait, no no no don't!" that your current patch has gotten means it's time for a pull request, and for that to go in, and so this line of argument would be simply removed. > - U-Boot should not have DTs in-tree ... for the cases where the DTs are not used at run time, yes. > - U-Boot should have DTs only when essential I don't understand this point. Can you please elaborate? > - U-Boot should have DTs in-tree for all boards This is the line you're pushing and almost every other reviewer disagrees with. > What's the downside here anyway? - A lack of clarity. We have dts files, you modify those dts files, they aren't used. What's the point? Oh, you forgot to tweak something else. Wait, now nothing works. Oh, it's a mismatch between what this dts was at one point, and what it needs to be now to actually work. - We're adding more ongoing sync-up work. While I loudly applaud the custodians that are keeping their dts files in sync very regularly, and I sympathize with the custodians that want to do it more, but are unable to find the time, I do not want to add more of this work. Even more so when it's unclear who would be doing it. Or what the use is. There's probably more if I think about it harder, but those are the first to spring to mind. > > > It is more than just development. A devicetree is needed for binman to > > > work, even if it is empty. The documentation idea doesn't really work, > > > as I think I have proven by the difficulty in getting this series > > > together. An automated mechanism that runs in CI might be acceptable, > > > but that is in the future. For now, I believe it just HAS to be > > > in-tree. > > > > I still don't see any reason why we need these incorrect and not > > functionally used device trees in-tree when a dummy invalid tree is > > enough to make things link. We're dealing with real "we must have X.bin > > in the output for things to function" issues on other platforms with > > binman right now. Using a dummy dts should be fine. > > Incorrect in what way? Well, in the QEMU instance, they're only as correct as the parameters passed to qemu-system-foo when you did -dumpdtb to start with. Lets take TPM as that now should show up in the device tree, or not, depending on if we have the backend side of it? Or all of the examples of how to arbitrarily configure a system as Heinrich noted. Or the Pi examples where we need to use the device tree passed to us because config.txt is the official way to modify things in the device tree on that platform. > How do I get a real one for development? How do I turn off OF_BOARD > and use the in-tree one? How do you turn off the run-time device tree and instead use the in-tree one for development, with your series? > The documentation approach is not good enough. Why? But maybe I can better explain things in Mark's part of the thread about power domains and serial on M1.. > > > > And yes, we're "only" talking about 10 platforms, which include things > > > > like the "everyone" has one Pi family, the extraordinarily flexible (and > > > > so easy for the reference device tree to be very wrong) QEMU families > > > > and then platforms that are including a dts in-tree now because they > > > > were told that was required. > > > > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot? > > > The argument is the same. > > > > Because we don't need it! It serves no purpose! It exists in Linux > > as that's the primary device tree source repository. We could _copy_ it > > in, if it was useful. But then we need to re-sync it every so often, > > and for less clear reasons than all of the platforms that we need to > > sync with the kernel for, AND we use the tree. > > So some people don't need it and it serves no purpose for them. But > why do they care? It is not hurting anyone. This is all overblown. Because it's adding ongoing maintenance work, and reducing clarity of the codebase, to summarize my concerns above. > > There's even an argument to be made that it IS in Linux because when you > > build that dtb, it's what the firmware then ships and uses and provides > > to everyone at run time, possibly along with whatever other > > modifications the binary firmware did (see the assorted threads, > > including one this week about the problems we have because we don't just > > always use the dtb provided to us at run time). > > > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now > > > copied by RISC-V) which doesn't. > > > > Yes, these are more examples of "someone said we need to copy it in, so > > we copy it in". > > No that's not correct. With x86, ppc, integrator, ast2500 and many > others we *need* the DT and *it is not* created by QEMU. You're listing both QEMU virtual machines and QEMU-as-hardware-emulators above, which confuses things. The integrator code runs on real hardware. Real hardware which does not have the device tree on it. I assume that QEMU + Linux - U-Boot for integrator requires you to pass the .dtb in, just like real the real hardware does. That's true of all of the cases I believe where we use QEMU-as-hardware-emulator because QEMU is also authentic to the hardware. > > > > How about adjusting the make logic so that if a tree isn't found, we use > > > > a dummy minimal valid dts file? > > > > > > This is what I have done for the boards where I could not figure out > > > how to get any sort of DT, yes. But I don't think that should be the > > > default. > > > > The more I think about this, the more I think dummy minimal valid dts > > should be the fall-back default. This then solves the "I'm a developer, > > I need to modify the dts files" case because you then just provide the > > dts instead where it should go, and it's used. > > How does it solve it? I don't even know how to get it in many cases. > If it is a dummy then I cannot actually use it for development, right? It solves the problem of "we must have this dts file so that the build will not fail". The next step of "oh, we actually want to use it, and not the run-time provided dtb" would be the same as whatever you're doing with this series.
On Thu, Dec 02, 2021 at 11:21:22AM -0700, Simon Glass wrote: > Hi Mark, > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > Hi Simon > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > appended to U-Boot > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > the ELF file (also used for EFI) > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > [1] > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > Changes in v6: > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > - Expand the commit message based on comments > > > > > > - Expand the commit message based on comments > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > not in favor of this new version either. > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > advances in the documentation and other areas that would be better in > > > > > mainline…. > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > not using the one provided by the platform and the right way of dealing > > > > > with DTs for the platform. > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > We should be able to _remove_ the ones we have, that are not required, > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > more. > > > > > > So this is a key point for me and the reason I completely disagree > > > with this approach. This proposal is working in the *exact* opposite > > > direction and we'll never be able to get rid of device trees from > > > U-Boot, even if at some point they move out of the kernel to a > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > Personally I'd be way happier if we could figure out were the specific > > > U-Boot config nodes are needed and when are they needed. Based on > > > what we figure out we could, pick up the device tree from a previous > > > state bootloader and fix it up with our special nodes before we start > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > that indeed belong in the u-boot tree. > > > > I don't think it makes sense to put stuff in the DT that is specific > > for U-Boot only to pull it out moments later. Maybe it does make some > > sense to do this to pass information between TPL/SPL and U-Boot > > proper. But otherwise you can just use global variables... > > > > Now I just ran into an issue on Apple M1 that may have some relevance > > here. I'm adding support for power domains and the serial port > > requires certain power domains to be on. Since the serial port is > > initialized in the pre-relocation phase this means that the device > > tree nodes for the power domain controllers need to have the > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > > be able to bind the power domain controller driver in this phase and > > binding the serial port driver itself will fail. Which makes U-Boot > > hang without any visible output on the serial console. > > > > Within the Asahi Linux group we're currently discussing how to solve > > this. We could just add the "u-boot,dm-pre-reloc" properties in the > > device trees that we're going to distribute as part of m1n1 (the > > "bootloader" than embeds U-Boot). Or we can write some code that adds > > those properties to the device tree nodes that are dependencies for > > the serial port. > > > > I don't think the suggestion of applying an overlay embedded in U-Boot > > would work here. The code applying the overlay would need to run very > > early on in the pre-relocation phase. We'd also have to include > > overlays for all the models that Apple offers and pick the right one. > > And if a new model appears we can no longer just add a new device tree > > to m1n1. > > Well put. > > > > > But maybe there is a case where the overlay approach would make sense... > > There might be, but I haven't found it yet. > > BTW I suggest we figure out how to upstream the binding for this. I > will see if I can send a patch to start the process. The last patch > didn't get any comments though. Yes, it's probably time to submit and defend some of the more non-trivial properties such as "u-boot,dm-pre-reloc" which I think starts to get at the heart of our issues.
> From: Simon Glass <sjg@chromium.org> > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > Hi Mark, > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > Hi Simon > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > appended to U-Boot > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > the ELF file (also used for EFI) > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > [1] > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > Changes in v6: > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > - Expand the commit message based on comments > > > > > > - Expand the commit message based on comments > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > not in favor of this new version either. > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > advances in the documentation and other areas that would be better in > > > > > mainline…. > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > not using the one provided by the platform and the right way of dealing > > > > > with DTs for the platform. > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > We should be able to _remove_ the ones we have, that are not required, > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > more. > > > > > > So this is a key point for me and the reason I completely disagree > > > with this approach. This proposal is working in the *exact* opposite > > > direction and we'll never be able to get rid of device trees from > > > U-Boot, even if at some point they move out of the kernel to a > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > Personally I'd be way happier if we could figure out were the specific > > > U-Boot config nodes are needed and when are they needed. Based on > > > what we figure out we could, pick up the device tree from a previous > > > state bootloader and fix it up with our special nodes before we start > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > that indeed belong in the u-boot tree. > > > > I don't think it makes sense to put stuff in the DT that is specific > > for U-Boot only to pull it out moments later. Maybe it does make some > > sense to do this to pass information between TPL/SPL and U-Boot > > proper. But otherwise you can just use global variables... > > > > Now I just ran into an issue on Apple M1 that may have some relevance > > here. I'm adding support for power domains and the serial port > > requires certain power domains to be on. Since the serial port is > > initialized in the pre-relocation phase this means that the device > > tree nodes for the power domain controllers need to have the > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > > be able to bind the power domain controller driver in this phase and > > binding the serial port driver itself will fail. Which makes U-Boot > > hang without any visible output on the serial console. > > > > Within the Asahi Linux group we're currently discussing how to solve > > this. We could just add the "u-boot,dm-pre-reloc" properties in the > > device trees that we're going to distribute as part of m1n1 (the > > "bootloader" than embeds U-Boot). Or we can write some code that adds > > those properties to the device tree nodes that are dependencies for > > the serial port. > > > > I don't think the suggestion of applying an overlay embedded in U-Boot > > would work here. The code applying the overlay would need to run very > > early on in the pre-relocation phase. We'd also have to include > > overlays for all the models that Apple offers and pick the right one. > > And if a new model appears we can no longer just add a new device tree > > to m1n1. > > Well put. > > > > > But maybe there is a case where the overlay approach would make sense... > > There might be, but I haven't found it yet. > > BTW I suggest we figure out how to upstream the binding for this. I > will see if I can send a patch to start the process. The last patch > didn't get any comments though. > > In the interim there is probably no choice but to add the properties > into the m1n1 project. Of course, for development, you could just turn > off OF_BOARD, with my series applied. Which is a lot of the point of > all of this discussion... And that is exactly why I don't see the point of this series. There is no chance of that working. The device tree that is currently in the U-Boot tree (essentially because you made me add one) is only a template that gets modified by m1n1 to account for hardware characteristics (amount of memory, cores that are actually enabled, MAC addresses, WiFi antenna configuration, etc. etc.). If I flip OF_BOARD U-Boot would simply not work. The way I do development is that I simply build a device tree, build U-boot and upload them over serial to m1n1 running on the device. I currently do build my device trees out of the U-Boot tree, but the main reason for that is because the Linux development model means that too many of the device tree patches are still in flight. I often use the device tree from a different U-Boot repository clone than the one I do the actual U-Boot development in anyway.
Hi Mark, On Thu, 2 Dec 2021 at 11:47, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > From: Simon Glass <sjg@chromium.org> > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > Hi Mark, > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > Hi Simon > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > appended to U-Boot > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > the ELF file (also used for EFI) > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > [1] > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > Changes in v6: > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > - Expand the commit message based on comments > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > not in favor of this new version either. > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > advances in the documentation and other areas that would be better in > > > > > > mainline…. > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > with DTs for the platform. > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > more. > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > with this approach. This proposal is working in the *exact* opposite > > > > direction and we'll never be able to get rid of device trees from > > > > U-Boot, even if at some point they move out of the kernel to a > > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > > Personally I'd be way happier if we could figure out were the specific > > > > U-Boot config nodes are needed and when are they needed. Based on > > > > what we figure out we could, pick up the device tree from a previous > > > > state bootloader and fix it up with our special nodes before we start > > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > > that indeed belong in the u-boot tree. > > > > > > I don't think it makes sense to put stuff in the DT that is specific > > > for U-Boot only to pull it out moments later. Maybe it does make some > > > sense to do this to pass information between TPL/SPL and U-Boot > > > proper. But otherwise you can just use global variables... > > > > > > Now I just ran into an issue on Apple M1 that may have some relevance > > > here. I'm adding support for power domains and the serial port > > > requires certain power domains to be on. Since the serial port is > > > initialized in the pre-relocation phase this means that the device > > > tree nodes for the power domain controllers need to have the > > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > > > be able to bind the power domain controller driver in this phase and > > > binding the serial port driver itself will fail. Which makes U-Boot > > > hang without any visible output on the serial console. > > > > > > Within the Asahi Linux group we're currently discussing how to solve > > > this. We could just add the "u-boot,dm-pre-reloc" properties in the > > > device trees that we're going to distribute as part of m1n1 (the > > > "bootloader" than embeds U-Boot). Or we can write some code that adds > > > those properties to the device tree nodes that are dependencies for > > > the serial port. > > > > > > I don't think the suggestion of applying an overlay embedded in U-Boot > > > would work here. The code applying the overlay would need to run very > > > early on in the pre-relocation phase. We'd also have to include > > > overlays for all the models that Apple offers and pick the right one. > > > And if a new model appears we can no longer just add a new device tree > > > to m1n1. > > > > Well put. > > > > > > > > But maybe there is a case where the overlay approach would make sense... > > > > There might be, but I haven't found it yet. > > > > BTW I suggest we figure out how to upstream the binding for this. I > > will see if I can send a patch to start the process. The last patch > > didn't get any comments though. > > > > In the interim there is probably no choice but to add the properties > > into the m1n1 project. Of course, for development, you could just turn > > off OF_BOARD, with my series applied. Which is a lot of the point of > > all of this discussion... > > And that is exactly why I don't see the point of this series. There > is no chance of that working. The device tree that is currently in > the U-Boot tree (essentially because you made me add one) is only a > template that gets modified by m1n1 to account for hardware > characteristics (amount of memory, cores that are actually enabled, > MAC addresses, WiFi antenna configuration, etc. etc.). If I flip > OF_BOARD U-Boot would simply not work. > > The way I do development is that I simply build a device tree, build > U-boot and upload them over serial to m1n1 running on the device. I > currently do build my device trees out of the U-Boot tree, but the > main reason for that is because the Linux development model means that > too many of the device tree patches are still in flight. I often use > the device tree from a different U-Boot repository clone than the one > I do the actual U-Boot development in anyway. Yes and I think you have made my point. That is all I am saying. I am not claiming that U-Boot needs to be the golden repo for the .dts, just that it should have something suitable that works well enough for development, and can be modified and updated as development progresses. Regards, SImon
> From: François Ozog <francois.ozog@linaro.org> > Date: Thu, 2 Dec 2021 19:32:17 +0100 > > On Thu, 2 Dec 2021 at 19:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a > écrit : > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > OF_HOSTFILE so > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built > and > > > > > appended to U-Boot > > > > > - OF_EMBED - for development purposes, the devicetree is > embedded in > > > > > the ELF file (also used for EFI) > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > The last one is currently set up so that no devicetree is needed > at all > > > > > in the U-Boot tree. Most boards do provide one, but some don't. > Some > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > The problems with this approach are documented in another patch > in this > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. > Any board > > > > > can obtain its devicetree at runtime, even it is has a > devicetree built > > > > > in U-Boot. This is because U-Boot may be a second-stage > bootloader and its > > > > > caller may have a better idea about the hardware available in > the machine. > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should > be an > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > This series makes this change, adding various missing devicetree > files > > > > > (and placeholders) to make the build work. > > > > > > > > > > Note: If board maintainers are able to add their own patch to > add the > > > > > files, some patches in this series can be dropped. > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. > The > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > [1] > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current > state > > > > > - Explain that the 'two devicetrees' refers to two *control* > devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing > list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there > are good > > > > advances in the documentation and other areas that would be better > in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be > accepted, I > > > > would love there is a warning in capital letters at the top of the > DTS fake > > > > files that explains the intent of this fake DT, the possible > outcomes of > > > > not using the one provided by the platform and the right way of > dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source > tree. > > > We should be able to _remove_ the ones we have, that are not > required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm adding support for power domains and the serial port > requires certain power domains to be on. Since the serial port is > initialized in the pre-relocation phase this means that the device > tree nodes for the power domain controllers need to have the > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > be able to bind the power domain controller driver in this phase and > binding the serial port driver itself will fail. Which makes U-Boot > hang without any visible output on the serial console. > > Does this hint at a bigger issue that DT shall be parsed and handled in the > U-Boot process way early than it is today? No it doesn't. It indicates that it is already parsed and handled very early on in the U-Boot process, which implies that applying modifications in U-Boot itself will be a challenge. > Ilias reported a similar problem with TPM handling where you need to > discover TPM very early to deal with it. > There may be one early parse and two scans (one early, one normal > enumeration) Serial ports are explicitly handled early on. I suppose the TPM could be handled in a similar way if there is a valid reason to do so. But in my opinion the TPM is way to complex for doing something like that. > Within the Asahi Linux group we're currently discussing how to solve > this. We could just add the "u-boot,dm-pre-reloc" properties in the > device trees that we're going to distribute as part of m1n1 (the > "bootloader" than embeds U-Boot). Or we can write some code that adds > those properties to the device tree nodes that are dependencies for > the serial port. > > I don't think the suggestion of applying an overlay embedded in U-Boot > would work here. The code applying the overlay would need to run very > early on in the pre-relocation phase. We'd also have to include > overlays for all the models that Apple offers and pick the right one. > And if a new model appears we can no longer just add a new device tree > to m1n1. > > But maybe there is a case where the overlay approach would make sense... > > -- > > * François-Frédéric Ozog | Director Business Development > T: +33.67221.6485 > francois.ozog@linaro.org | Skype: ffozog > *
Hi Tom, On Thu, 2 Dec 2021 at 11:34, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > > > appended to U-Boot > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > > more. > > > > > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > > > it had not come to this. > > > > > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > > > have a devicetree anywhere I can find. > > > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > > > > whatever caveats and documentation people want to clarify what is > > > > > > going on here. I'm happy to look at future options where the > > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > > > > within U-Boot for development purposes. > > > > > > > > > > > > I'll also note that the bootstd series shows the devicetree source: > > > > > > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > > > > > > > But for now, I still feel this is the best path forward. > > > > > > > > > > I'm not sure how to proceed here. The reviews are rather strongly > > > > > against the "include a device tree that won't be used". The use case of > > > > > "but for development someone might need to modify the device tree" is > > > > > handled by platforms documenting where / how to get the real one. We > > > > > should even update the Kconfig help to note that if you enable this your > > > > > board docs MUST explain where the device tree can be seen (or have some > > > > > legal reason you think it's OK to not...). > > > > > > > > Right, we can do lots of things as we have discussed. I am very > > > > willing to work on these and make sure it is hard to do the thing. But > > > > this series is long enough already. > > > > > > Yes, I think the rest of us had hoped you would come around to all of > > > our reasoning by this point, is why this is taking so long. > > > > > > > Look, if I thought this was all wrong I would not be doing it. We have > > a range of opinions: > > And the rest of us wouldn't keep trying to argue otherwise if we didn't > see problems with it, still. I don't claim it is perfect, just that it is better than what we have. We have lots of ideas on how to improve things, e.g. - upstreaming the bindings - having a way to obtain the correct DT through a script - syncing the DT automatically with an external source - applying validation to the in-tree DT - using binman to make it easier to build images That will take a lot of effort and I don't see anyone else taking it on. All we have is a lot of people with competing ideas, many influenced by other projects (TF-A, QEMU, Xen, m1n1, etc.). We could ask the coreboot people what they think, except that they banned devicetree years ago. Sometimes I wish... > > > - U-Boot should not have its own nodes/properties > > The caveat there is that aren't documented upstream bindings. I think > at this point the lack of screaming and otherwise "wait, no no no > don't!" that your current patch has gotten means it's time for a pull > request, and for that to go in, and so this line of argument would be > simply removed. That is going to be a long process. I have >100 patches pending and only so much energy. We need to make incremental progress and we need a development setup that works for U-Boot developers. > > > - U-Boot should not have DTs in-tree > > ... for the cases where the DTs are not used at run time, yes. Except when they are. E.g. for rpi3 I do actually use the in-tree .dtb for development. I don't what that to be a hassle. U-Boot is a development project and it needs to be easy. > > > - U-Boot should have DTs only when essential > > I don't understand this point. Can you please elaborate? That it should only be in U-Boot if there is no way it can be anywhere else. > > > - U-Boot should have DTs in-tree for all boards > > This is the line you're pushing and almost every other reviewer > disagrees with. Yes. > > > What's the downside here anyway? > > - A lack of clarity. We have dts files, you modify those dts files, > they aren't used. What's the point? Oh, you forgot to tweak > something else. Wait, now nothing works. Oh, it's a mismatch between > what this dts was at one point, and what it needs to be now to > actually work. That's not my experience with this series. It seems to work fine. Ilias and Heinrich have both pointed to things that 'don't work', but actually I believe things work just as they do now. > - We're adding more ongoing sync-up work. While I loudly applaud the > custodians that are keeping their dts files in sync very regularly, > and I sympathize with the custodians that want to do it more, but are > unable to find the time, I do not want to add more of this work. Even > more so when it's unclear who would be doing it. Or what the use is. Well we can make this better, but it is a small number of boards. It is in the noise. > > There's probably more if I think about it harder, but those are the > first to spring to mind. > > > > > It is more than just development. A devicetree is needed for binman to > > > > work, even if it is empty. The documentation idea doesn't really work, > > > > as I think I have proven by the difficulty in getting this series > > > > together. An automated mechanism that runs in CI might be acceptable, > > > > but that is in the future. For now, I believe it just HAS to be > > > > in-tree. > > > > > > I still don't see any reason why we need these incorrect and not > > > functionally used device trees in-tree when a dummy invalid tree is > > > enough to make things link. We're dealing with real "we must have X.bin > > > in the output for things to function" issues on other platforms with > > > binman right now. Using a dummy dts should be fine. > > > > Incorrect in what way? > > Well, in the QEMU instance, they're only as correct as the parameters > passed to qemu-system-foo when you did -dumpdtb to start with. Lets > take TPM as that now should show up in the device tree, or not, > depending on if we have the backend side of it? Or all of the examples > of how to arbitrarily configure a system as Heinrich noted. > > Or the Pi examples where we need to use the device tree passed to us > because config.txt is the official way to modify things in the device > tree on that platform. OK, so when you add extra parameters to the ARM and RISC-V QEMU command line, it doesn't add those extra parameters and those extra devices are not present.That does not sound surprising to me. It should be obvious to anyone doing development on these boards. > > > How do I get a real one for development? How do I turn off OF_BOARD > > and use the in-tree one? > > How do you turn off the run-time device tree and instead use the in-tree > one for development, with your series? Disable OF_BOARD manually. As we discussed, we can put that behind an EXPERT flag or a build flag, or other things. There is a message printed when U-Boot starts, too (with a later series). > > > The documentation approach is not good enough. > > Why? But maybe I can better explain things in Mark's part of the thread > about power domains and serial on M1.. Because I can't find the DT and it takes manual effort to locate it and set it up for development. It is just too hard. > > > > > > And yes, we're "only" talking about 10 platforms, which include things > > > > > like the "everyone" has one Pi family, the extraordinarily flexible (and > > > > > so easy for the reference device tree to be very wrong) QEMU families > > > > > and then platforms that are including a dts in-tree now because they > > > > > were told that was required. > > > > > > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is > > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot? > > > > The argument is the same. > > > > > > Because we don't need it! It serves no purpose! It exists in Linux > > > as that's the primary device tree source repository. We could _copy_ it > > > in, if it was useful. But then we need to re-sync it every so often, > > > and for less clear reasons than all of the platforms that we need to > > > sync with the kernel for, AND we use the tree. > > > > So some people don't need it and it serves no purpose for them. But > > why do they care? It is not hurting anyone. This is all overblown. > > Because it's adding ongoing maintenance work, and reducing clarity of > the codebase, to summarize my concerns above. Yes, but can we just accept that as a cost? We have plans and ideas to reduce it over time, right? > > > > There's even an argument to be made that it IS in Linux because when you > > > build that dtb, it's what the firmware then ships and uses and provides > > > to everyone at run time, possibly along with whatever other > > > modifications the binary firmware did (see the assorted threads, > > > including one this week about the problems we have because we don't just > > > always use the dtb provided to us at run time). > > > > > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now > > > > copied by RISC-V) which doesn't. > > > > > > Yes, these are more examples of "someone said we need to copy it in, so > > > we copy it in". > > > > No that's not correct. With x86, ppc, integrator, ast2500 and many > > others we *need* the DT and *it is not* created by QEMU. > > You're listing both QEMU virtual machines and QEMU-as-hardware-emulators > above, which confuses things. The integrator code runs on real > hardware. Real hardware which does not have the device tree on it. I > assume that QEMU + Linux - U-Boot for integrator requires you to pass > the .dtb in, just like real the real hardware does. That's true of all > of the cases I believe where we use QEMU-as-hardware-emulator because > QEMU is also authentic to the hardware. Yes, I get it. But the common case just works and I want to use binman images in CI as well as development with these things, without hacking QEMU itself. It is just not sensible to have to upgrade QEMU just to get an updated DT for trying something out. > > > > > > How about adjusting the make logic so that if a tree isn't found, we use > > > > > a dummy minimal valid dts file? > > > > > > > > This is what I have done for the boards where I could not figure out > > > > how to get any sort of DT, yes. But I don't think that should be the > > > > default. > > > > > > The more I think about this, the more I think dummy minimal valid dts > > > should be the fall-back default. This then solves the "I'm a developer, > > > I need to modify the dts files" case because you then just provide the > > > dts instead where it should go, and it's used. > > > > How does it solve it? I don't even know how to get it in many cases. > > If it is a dummy then I cannot actually use it for development, right? > > It solves the problem of "we must have this dts file so that the build > will not fail". The next step of "oh, we actually want to use it, and > not the run-time provided dtb" would be the same as whatever you're > doing with this series. Not in my experience. For example, with QEMU I was able to use an in-tree .dts for the bootstd stuff without any issues. This series also explains how to discover the DT, at least for the two QEMU boards that need it. Regards, Simon
> From: Simon Glass <sjg@chromium.org> > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > Hi Mark, > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > From: Simon Glass <sjg@chromium.org> > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > Hi Mark, > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > Hi Simon > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > > appended to U-Boot > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > > the ELF file (also used for EFI) > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > [1] > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > - Expand the commit message based on comments > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > not in favor of this new version either. > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > mainline…. > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > with DTs for the platform. > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > more. > > > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > > with this approach. This proposal is working in the *exact* opposite > > > > > direction and we'll never be able to get rid of device trees from > > > > > U-Boot, even if at some point they move out of the kernel to a > > > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > > > Personally I'd be way happier if we could figure out were the specific > > > > > U-Boot config nodes are needed and when are they needed. Based on > > > > > what we figure out we could, pick up the device tree from a previous > > > > > state bootloader and fix it up with our special nodes before we start > > > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > > > that indeed belong in the u-boot tree. > > > > > > > > I don't think it makes sense to put stuff in the DT that is specific > > > > for U-Boot only to pull it out moments later. Maybe it does make some > > > > sense to do this to pass information between TPL/SPL and U-Boot > > > > proper. But otherwise you can just use global variables... > > > > > > > > Now I just ran into an issue on Apple M1 that may have some relevance > > > > here. I'm adding support for power domains and the serial port > > > > requires certain power domains to be on. Since the serial port is > > > > initialized in the pre-relocation phase this means that the device > > > > tree nodes for the power domain controllers need to have the > > > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > > > > be able to bind the power domain controller driver in this phase and > > > > binding the serial port driver itself will fail. Which makes U-Boot > > > > hang without any visible output on the serial console. > > > > > > > > Within the Asahi Linux group we're currently discussing how to solve > > > > this. We could just add the "u-boot,dm-pre-reloc" properties in the > > > > device trees that we're going to distribute as part of m1n1 (the > > > > "bootloader" than embeds U-Boot). Or we can write some code that adds > > > > those properties to the device tree nodes that are dependencies for > > > > the serial port. > > > > > > > > I don't think the suggestion of applying an overlay embedded in U-Boot > > > > would work here. The code applying the overlay would need to run very > > > > early on in the pre-relocation phase. We'd also have to include > > > > overlays for all the models that Apple offers and pick the right one. > > > > And if a new model appears we can no longer just add a new device tree > > > > to m1n1. > > > > > > Well put. > > > > > > > > > > > But maybe there is a case where the overlay approach would make sense... > > > > > > There might be, but I haven't found it yet. > > > > > > BTW I suggest we figure out how to upstream the binding for this. I > > > will see if I can send a patch to start the process. The last patch > > > didn't get any comments though. > > > > > > In the interim there is probably no choice but to add the properties > > > into the m1n1 project. Of course, for development, you could just turn > > > off OF_BOARD, with my series applied. Which is a lot of the point of > > > all of this discussion... > > > > And that is exactly why I don't see the point of this series. There > > is no chance of that working. The device tree that is currently in > > the U-Boot tree (essentially because you made me add one) is only a > > template that gets modified by m1n1 to account for hardware > > characteristics (amount of memory, cores that are actually enabled, > > MAC addresses, WiFi antenna configuration, etc. etc.). If I flip > > OF_BOARD U-Boot would simply not work. > > > > The way I do development is that I simply build a device tree, build > > U-boot and upload them over serial to m1n1 running on the device. I > > currently do build my device trees out of the U-Boot tree, but the > > main reason for that is because the Linux development model means that > > too many of the device tree patches are still in flight. I often use > > the device tree from a different U-Boot repository clone than the one > > I do the actual U-Boot development in anyway. > > Yes and I think you have made my point. That is all I am saying. I am > not claiming that U-Boot needs to be the golden repo for the .dts, > just that it should have something suitable that works well enough for > development, and can be modified and updated as development > progresses. No you are missing my point. I'm only doing it this way because the Linux development model is so broken that it takes months for patches posted on the mailing list to end up in a somewhat official source tree and I would go bat-shit crazy having to deal with all the merges and rebasing going on. If there was a separate device tree project, I would very much prefer to use that and make device tree changes there such that I could submit any additions to the canonical sources. I'm currently spending too much of my development time synching the device trees in my U-Boot tree with what's going on on the Linux side.
Hi Mark, On Thu, 2 Dec 2021 at 12:22, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > From: Simon Glass <sjg@chromium.org> > > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > > > Hi Mark, > > > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > From: Simon Glass <sjg@chromium.org> > > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > > > Hi Mark, > > > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > > > appended to U-Boot > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > > more. > > > > > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > > > with this approach. This proposal is working in the *exact* opposite > > > > > > direction and we'll never be able to get rid of device trees from > > > > > > U-Boot, even if at some point they move out of the kernel to a > > > > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > > > > Personally I'd be way happier if we could figure out were the specific > > > > > > U-Boot config nodes are needed and when are they needed. Based on > > > > > > what we figure out we could, pick up the device tree from a previous > > > > > > state bootloader and fix it up with our special nodes before we start > > > > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > > > > that indeed belong in the u-boot tree. > > > > > > > > > > I don't think it makes sense to put stuff in the DT that is specific > > > > > for U-Boot only to pull it out moments later. Maybe it does make some > > > > > sense to do this to pass information between TPL/SPL and U-Boot > > > > > proper. But otherwise you can just use global variables... > > > > > > > > > > Now I just ran into an issue on Apple M1 that may have some relevance > > > > > here. I'm adding support for power domains and the serial port > > > > > requires certain power domains to be on. Since the serial port is > > > > > initialized in the pre-relocation phase this means that the device > > > > > tree nodes for the power domain controllers need to have the > > > > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > > > > > be able to bind the power domain controller driver in this phase and > > > > > binding the serial port driver itself will fail. Which makes U-Boot > > > > > hang without any visible output on the serial console. > > > > > > > > > > Within the Asahi Linux group we're currently discussing how to solve > > > > > this. We could just add the "u-boot,dm-pre-reloc" properties in the > > > > > device trees that we're going to distribute as part of m1n1 (the > > > > > "bootloader" than embeds U-Boot). Or we can write some code that adds > > > > > those properties to the device tree nodes that are dependencies for > > > > > the serial port. > > > > > > > > > > I don't think the suggestion of applying an overlay embedded in U-Boot > > > > > would work here. The code applying the overlay would need to run very > > > > > early on in the pre-relocation phase. We'd also have to include > > > > > overlays for all the models that Apple offers and pick the right one. > > > > > And if a new model appears we can no longer just add a new device tree > > > > > to m1n1. > > > > > > > > Well put. > > > > > > > > > > > > > > But maybe there is a case where the overlay approach would make sense... > > > > > > > > There might be, but I haven't found it yet. > > > > > > > > BTW I suggest we figure out how to upstream the binding for this. I > > > > will see if I can send a patch to start the process. The last patch > > > > didn't get any comments though. > > > > > > > > In the interim there is probably no choice but to add the properties > > > > into the m1n1 project. Of course, for development, you could just turn > > > > off OF_BOARD, with my series applied. Which is a lot of the point of > > > > all of this discussion... > > > > > > And that is exactly why I don't see the point of this series. There > > > is no chance of that working. The device tree that is currently in > > > the U-Boot tree (essentially because you made me add one) is only a > > > template that gets modified by m1n1 to account for hardware > > > characteristics (amount of memory, cores that are actually enabled, > > > MAC addresses, WiFi antenna configuration, etc. etc.). If I flip > > > OF_BOARD U-Boot would simply not work. > > > > > > The way I do development is that I simply build a device tree, build > > > U-boot and upload them over serial to m1n1 running on the device. I > > > currently do build my device trees out of the U-Boot tree, but the > > > main reason for that is because the Linux development model means that > > > too many of the device tree patches are still in flight. I often use > > > the device tree from a different U-Boot repository clone than the one > > > I do the actual U-Boot development in anyway. > > > > Yes and I think you have made my point. That is all I am saying. I am > > not claiming that U-Boot needs to be the golden repo for the .dts, > > just that it should have something suitable that works well enough for > > development, and can be modified and updated as development > > progresses. > > No you are missing my point. I'm only doing it this way because the > Linux development model is so broken that it takes months for patches > posted on the mailing list to end up in a somewhat official source > tree and I would go bat-shit crazy having to deal with all the merges > and rebasing going on. > > If there was a separate device tree project, I would very much prefer > to use that and make device tree changes there such that I could > submit any additions to the canonical sources. I'm currently spending > too much of my development time synching the device trees in my U-Boot > tree with what's going on on the Linux side. Right, exactly. I have exactly the same problem and so do other people working with U-Boot. At least we have a work-around. Regards, Simon
On Thu, Dec 02, 2021 at 12:24:24PM -0700, Simon Glass wrote: > Hi Mark, > > On Thu, 2 Dec 2021 at 12:22, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > From: Simon Glass <sjg@chromium.org> > > > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > > > > > Hi Mark, > > > > > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > From: Simon Glass <sjg@chromium.org> > > > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > > > > > Hi Mark, > > > > > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > > > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > > > > appended to U-Boot > > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > > > not in favor of this new version either. > > > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > > > mainline…. > > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > > > more. > > > > > > > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > > > > with this approach. This proposal is working in the *exact* opposite > > > > > > > direction and we'll never be able to get rid of device trees from > > > > > > > U-Boot, even if at some point they move out of the kernel to a > > > > > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > > > > > Personally I'd be way happier if we could figure out were the specific > > > > > > > U-Boot config nodes are needed and when are they needed. Based on > > > > > > > what we figure out we could, pick up the device tree from a previous > > > > > > > state bootloader and fix it up with our special nodes before we start > > > > > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > > > > > that indeed belong in the u-boot tree. > > > > > > > > > > > > I don't think it makes sense to put stuff in the DT that is specific > > > > > > for U-Boot only to pull it out moments later. Maybe it does make some > > > > > > sense to do this to pass information between TPL/SPL and U-Boot > > > > > > proper. But otherwise you can just use global variables... > > > > > > > > > > > > Now I just ran into an issue on Apple M1 that may have some relevance > > > > > > here. I'm adding support for power domains and the serial port > > > > > > requires certain power domains to be on. Since the serial port is > > > > > > initialized in the pre-relocation phase this means that the device > > > > > > tree nodes for the power domain controllers need to have the > > > > > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > > > > > > be able to bind the power domain controller driver in this phase and > > > > > > binding the serial port driver itself will fail. Which makes U-Boot > > > > > > hang without any visible output on the serial console. > > > > > > > > > > > > Within the Asahi Linux group we're currently discussing how to solve > > > > > > this. We could just add the "u-boot,dm-pre-reloc" properties in the > > > > > > device trees that we're going to distribute as part of m1n1 (the > > > > > > "bootloader" than embeds U-Boot). Or we can write some code that adds > > > > > > those properties to the device tree nodes that are dependencies for > > > > > > the serial port. > > > > > > > > > > > > I don't think the suggestion of applying an overlay embedded in U-Boot > > > > > > would work here. The code applying the overlay would need to run very > > > > > > early on in the pre-relocation phase. We'd also have to include > > > > > > overlays for all the models that Apple offers and pick the right one. > > > > > > And if a new model appears we can no longer just add a new device tree > > > > > > to m1n1. > > > > > > > > > > Well put. > > > > > > > > > > > > > > > > > But maybe there is a case where the overlay approach would make sense... > > > > > > > > > > There might be, but I haven't found it yet. > > > > > > > > > > BTW I suggest we figure out how to upstream the binding for this. I > > > > > will see if I can send a patch to start the process. The last patch > > > > > didn't get any comments though. > > > > > > > > > > In the interim there is probably no choice but to add the properties > > > > > into the m1n1 project. Of course, for development, you could just turn > > > > > off OF_BOARD, with my series applied. Which is a lot of the point of > > > > > all of this discussion... > > > > > > > > And that is exactly why I don't see the point of this series. There > > > > is no chance of that working. The device tree that is currently in > > > > the U-Boot tree (essentially because you made me add one) is only a > > > > template that gets modified by m1n1 to account for hardware > > > > characteristics (amount of memory, cores that are actually enabled, > > > > MAC addresses, WiFi antenna configuration, etc. etc.). If I flip > > > > OF_BOARD U-Boot would simply not work. I read this as Mark saying he builds the dtb file for U-Boot as well as Linux out of tree, and feeds those two files to m1n1. m1n1 is responsible for taking the dtb and adjusting as needed, and handing along to U-Boot. > > > > The way I do development is that I simply build a device tree, build > > > > U-boot and upload them over serial to m1n1 running on the device. I > > > > currently do build my device trees out of the U-Boot tree, but the > > > > main reason for that is because the Linux development model means that > > > > too many of the device tree patches are still in flight. I often use > > > > the device tree from a different U-Boot repository clone than the one > > > > I do the actual U-Boot development in anyway. > > > > > > Yes and I think you have made my point. That is all I am saying. I am > > > not claiming that U-Boot needs to be the golden repo for the .dts, > > > just that it should have something suitable that works well enough for > > > development, and can be modified and updated as development > > > progresses. > > > > No you are missing my point. I'm only doing it this way because the > > Linux development model is so broken that it takes months for patches > > posted on the mailing list to end up in a somewhat official source > > tree and I would go bat-shit crazy having to deal with all the merges > > and rebasing going on. > > > > If there was a separate device tree project, I would very much prefer > > to use that and make device tree changes there such that I could > > submit any additions to the canonical sources. I'm currently spending > > too much of my development time synching the device trees in my U-Boot > > tree with what's going on on the Linux side. > > Right, exactly. I have exactly the same problem and so do other people > working with U-Boot. At least we have a work-around. I'm confused. I read this as Mark says "I need to solve this problem for all users, I can't compile the device tree in to U-Boot as it will be wrong" and then Simon says "Yes, compile in the device tree for all users, that's what my series brings us".
Hi Simon,Tom Le jeu. 2 déc. 2021 à 19:34, Tom Rini <trini@konsulko.com> a écrit : > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> > wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> > a écrit : > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > OF_HOSTFILE so > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is > built and > > > > > > > > > appended to U-Boot > > > > > > > > > - OF_EMBED - for development purposes, the devicetree > is embedded in > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > needed at all > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > don't. Some > > > > > > > > > don't even provide instructions on how to boot on the > board. > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > OF_SEPARATE. Any board > > > > > > > > > can obtain its devicetree at runtime, even it is has a > devicetree built > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > bootloader and its > > > > > > > > > caller may have a better idea about the hardware available > in the machine. > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > should be an > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > devicetree files > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > to add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two > *control* devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, > there are good > > > > > > > > advances in the documentation and other areas that would be > better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be > accepted, I > > > > > > > > would love there is a warning in capital letters at the top > of the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible > outcomes of > > > > > > > > not using the one provided by the platform and the right way > of dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > want > > > > > > > reference or fake or whatever device trees in the U-Boot > source tree. > > > > > > > We should be able to _remove_ the ones we have, that are not > required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not > adding > > > > > > > more. > > > > > > > > > > > > I understand you don't like it and that others don't as well. I > wish > > > > > > it had not come to this. > > > > > > > > > > > > However we are only talking about 10 boards, three of which > don't even > > > > > > have a devicetree anywhere I can find. > > > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to > add > > > > > > whatever caveats and documentation people want to clarify what is > > > > > > going on here. I'm happy to look at future options where the > > > > > > devicetree is hosted elsewhere, so long as it is trivial to > build it > > > > > > within U-Boot for development purposes. > > > > > > > > > > > > I'll also note that the bootstd series shows the devicetree > source: > > > > > > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > > > > > > > But for now, I still feel this is the best path forward. > > > > > > > > > > I'm not sure how to proceed here. The reviews are rather strongly > > > > > against the "include a device tree that won't be used". The use > case of > > > > > "but for development someone might need to modify the device tree" > is > > > > > handled by platforms documenting where / how to get the real one. > We > > > > > should even update the Kconfig help to note that if you enable > this your > > > > > board docs MUST explain where the device tree can be seen (or have > some > > > > > legal reason you think it's OK to not...). > > > > > > > > Right, we can do lots of things as we have discussed. I am very > > > > willing to work on these and make sure it is hard to do the thing. > But > > > > this series is long enough already. > > > > > > Yes, I think the rest of us had hoped you would come around to all of > > > our reasoning by this point, is why this is taking so long. > > > > > > > Look, if I thought this was all wrong I would not be doing it. We have > > a range of opinions: > > And the rest of us wouldn't keep trying to argue otherwise if we didn't > see problems with it, still. > > > - U-Boot should not have its own nodes/properties > > The caveat there is that aren't documented upstream bindings. I think > at this point the lack of screaming and otherwise "wait, no no no > don't!" that your current patch has gotten means it's time for a pull > request, and for that to go in, and so this line of argument would be > simply removed. > > > - U-Boot should not have DTs in-tree > > ... for the cases where the DTs are not used at run time, yes. > > > - U-Boot should have DTs only when essential > > I don't understand this point. Can you please elaborate? > > > - U-Boot should have DTs in-tree for all boards > > This is the line you're pushing and almost every other reviewer > disagrees with. For the sake of getting interesting parts of the patch set in and “move on”, what about: providing an empty (see below) DT for boards for which U-Boot receives the “source of truth” so that there are no build issues. The empty DT contains a comment that explains the DT lifecycle for the board and points to the documentation tree for sample DTs. The boards would the ones we talked about and SystemReady boards https://www.arm.com/why-arm/architecture/systems/systemready-certification-program/ir?_ga=2.35159527.79382615.1638484482-159131740.1638484482 > > > What's the downside here anyway? > > - A lack of clarity. We have dts files, you modify those dts files, > they aren't used. What's the point? Oh, you forgot to tweak > something else. Wait, now nothing works. Oh, it's a mismatch between > what this dts was at one point, and what it needs to be now to > actually work. > - We're adding more ongoing sync-up work. While I loudly applaud the > custodians that are keeping their dts files in sync very regularly, > and I sympathize with the custodians that want to do it more, but are > unable to find the time, I do not want to add more of this work. Even > more so when it's unclear who would be doing it. Or what the use is. > > There's probably more if I think about it harder, but those are the > first to spring to mind. > > > > > It is more than just development. A devicetree is needed for binman > to > > > > work, even if it is empty. The documentation idea doesn't really > work, > > > > as I think I have proven by the difficulty in getting this series > > > > together. An automated mechanism that runs in CI might be acceptable, > > > > but that is in the future. For now, I believe it just HAS to be > > > > in-tree. > > > > > > I still don't see any reason why we need these incorrect and not > > > functionally used device trees in-tree when a dummy invalid tree is > > > enough to make things link. We're dealing with real "we must have > X.bin > > > in the output for things to function" issues on other platforms with > > > binman right now. Using a dummy dts should be fine. > > > > Incorrect in what way? > > Well, in the QEMU instance, they're only as correct as the parameters > passed to qemu-system-foo when you did -dumpdtb to start with. Lets > take TPM as that now should show up in the device tree, or not, > depending on if we have the backend side of it? Or all of the examples > of how to arbitrarily configure a system as Heinrich noted. > > Or the Pi examples where we need to use the device tree passed to us > because config.txt is the official way to modify things in the device > tree on that platform. > > > How do I get a real one for development? How do I turn off OF_BOARD > > and use the in-tree one? > > How do you turn off the run-time device tree and instead use the in-tree > one for development, with your series? > > > The documentation approach is not good enough. > > Why? But maybe I can better explain things in Mark's part of the thread > about power domains and serial on M1.. > > > > > > And yes, we're "only" talking about 10 platforms, which include > things > > > > > like the "everyone" has one Pi family, the extraordinarily > flexible (and > > > > > so easy for the reference device tree to be very wrong) QEMU > families > > > > > and then platforms that are including a dts in-tree now because > they > > > > > were told that was required. > > > > > > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is > > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot? > > > > The argument is the same. > > > > > > Because we don't need it! It serves no purpose! It exists in Linux > > > as that's the primary device tree source repository. We could _copy_ > it > > > in, if it was useful. But then we need to re-sync it every so often, > > > and for less clear reasons than all of the platforms that we need to > > > sync with the kernel for, AND we use the tree. > > > > So some people don't need it and it serves no purpose for them. But > > why do they care? It is not hurting anyone. This is all overblown. > > Because it's adding ongoing maintenance work, and reducing clarity of > the codebase, to summarize my concerns above. > > > > There's even an argument to be made that it IS in Linux because when > you > > > build that dtb, it's what the firmware then ships and uses and provides > > > to everyone at run time, possibly along with whatever other > > > modifications the binary firmware did (see the assorted threads, > > > including one this week about the problems we have because we don't > just > > > always use the dtb provided to us at run time). > > > > > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now > > > > copied by RISC-V) which doesn't. > > > > > > Yes, these are more examples of "someone said we need to copy it in, so > > > we copy it in". > > > > No that's not correct. With x86, ppc, integrator, ast2500 and many > > others we *need* the DT and *it is not* created by QEMU. > > You're listing both QEMU virtual machines and QEMU-as-hardware-emulators > above, which confuses things. The integrator code runs on real > hardware. Real hardware which does not have the device tree on it. I > assume that QEMU + Linux - U-Boot for integrator requires you to pass > the .dtb in, just like real the real hardware does. That's true of all > of the cases I believe where we use QEMU-as-hardware-emulator because > QEMU is also authentic to the hardware. > > > > > > How about adjusting the make logic so that if a tree isn't found, > we use > > > > > a dummy minimal valid dts file? > > > > > > > > This is what I have done for the boards where I could not figure out > > > > how to get any sort of DT, yes. But I don't think that should be the > > > > default. > > > > > > The more I think about this, the more I think dummy minimal valid dts > > > should be the fall-back default. This then solves the "I'm a > developer, > > > I need to modify the dts files" case because you then just provide the > > > dts instead where it should go, and it's used. > > > > How does it solve it? I don't even know how to get it in many cases. > > If it is a dummy then I cannot actually use it for development, right? > > It solves the problem of "we must have this dts file so that the build > will not fail". The next step of "oh, we actually want to use it, and > not the run-time provided dtb" would be the same as whatever you're > doing with this series. > > -- > Tom >
Hi Tom, On Thu, 2 Dec 2021 at 14:53, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 02, 2021 at 12:24:24PM -0700, Simon Glass wrote: > > Hi Mark, > > > > On Thu, 2 Dec 2021 at 12:22, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > From: Simon Glass <sjg@chromium.org> > > > > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > > > > > > > Hi Mark, > > > > > > > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > > > From: Simon Glass <sjg@chromium.org> > > > > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > > > > > > > Hi Mark, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > > > > > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > > > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > > > > > appended to U-Boot > > > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > > > > not in favor of this new version either. > > > > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > > > > mainline…. > > > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > > > > more. > > > > > > > > > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > > > > > with this approach. This proposal is working in the *exact* opposite > > > > > > > > direction and we'll never be able to get rid of device trees from > > > > > > > > U-Boot, even if at some point they move out of the kernel to a > > > > > > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > > > > > > Personally I'd be way happier if we could figure out were the specific > > > > > > > > U-Boot config nodes are needed and when are they needed. Based on > > > > > > > > what we figure out we could, pick up the device tree from a previous > > > > > > > > state bootloader and fix it up with our special nodes before we start > > > > > > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > > > > > > that indeed belong in the u-boot tree. > > > > > > > > > > > > > > I don't think it makes sense to put stuff in the DT that is specific > > > > > > > for U-Boot only to pull it out moments later. Maybe it does make some > > > > > > > sense to do this to pass information between TPL/SPL and U-Boot > > > > > > > proper. But otherwise you can just use global variables... > > > > > > > > > > > > > > Now I just ran into an issue on Apple M1 that may have some relevance > > > > > > > here. I'm adding support for power domains and the serial port > > > > > > > requires certain power domains to be on. Since the serial port is > > > > > > > initialized in the pre-relocation phase this means that the device > > > > > > > tree nodes for the power domain controllers need to have the > > > > > > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > > > > > > > be able to bind the power domain controller driver in this phase and > > > > > > > binding the serial port driver itself will fail. Which makes U-Boot > > > > > > > hang without any visible output on the serial console. > > > > > > > > > > > > > > Within the Asahi Linux group we're currently discussing how to solve > > > > > > > this. We could just add the "u-boot,dm-pre-reloc" properties in the > > > > > > > device trees that we're going to distribute as part of m1n1 (the > > > > > > > "bootloader" than embeds U-Boot). Or we can write some code that adds > > > > > > > those properties to the device tree nodes that are dependencies for > > > > > > > the serial port. > > > > > > > > > > > > > > I don't think the suggestion of applying an overlay embedded in U-Boot > > > > > > > would work here. The code applying the overlay would need to run very > > > > > > > early on in the pre-relocation phase. We'd also have to include > > > > > > > overlays for all the models that Apple offers and pick the right one. > > > > > > > And if a new model appears we can no longer just add a new device tree > > > > > > > to m1n1. > > > > > > > > > > > > Well put. > > > > > > > > > > > > > > > > > > > > But maybe there is a case where the overlay approach would make sense... > > > > > > > > > > > > There might be, but I haven't found it yet. > > > > > > > > > > > > BTW I suggest we figure out how to upstream the binding for this. I > > > > > > will see if I can send a patch to start the process. The last patch > > > > > > didn't get any comments though. > > > > > > > > > > > > In the interim there is probably no choice but to add the properties > > > > > > into the m1n1 project. Of course, for development, you could just turn > > > > > > off OF_BOARD, with my series applied. Which is a lot of the point of > > > > > > all of this discussion... > > > > > > > > > > And that is exactly why I don't see the point of this series. There > > > > > is no chance of that working. The device tree that is currently in > > > > > the U-Boot tree (essentially because you made me add one) is only a > > > > > template that gets modified by m1n1 to account for hardware > > > > > characteristics (amount of memory, cores that are actually enabled, > > > > > MAC addresses, WiFi antenna configuration, etc. etc.). If I flip > > > > > OF_BOARD U-Boot would simply not work. > > I read this as Mark saying he builds the dtb file for U-Boot as well as > Linux out of tree, and feeds those two files to m1n1. m1n1 is > responsible for taking the dtb and adjusting as needed, and handing > along to U-Boot. > > > > > > The way I do development is that I simply build a device tree, build > > > > > U-boot and upload them over serial to m1n1 running on the device. I > > > > > currently do build my device trees out of the U-Boot tree, but the > > > > > main reason for that is because the Linux development model means that > > > > > too many of the device tree patches are still in flight. I often use > > > > > the device tree from a different U-Boot repository clone than the one > > > > > I do the actual U-Boot development in anyway. > > > > > > > > Yes and I think you have made my point. That is all I am saying. I am > > > > not claiming that U-Boot needs to be the golden repo for the .dts, > > > > just that it should have something suitable that works well enough for > > > > development, and can be modified and updated as development > > > > progresses. > > > > > > No you are missing my point. I'm only doing it this way because the > > > Linux development model is so broken that it takes months for patches > > > posted on the mailing list to end up in a somewhat official source > > > tree and I would go bat-shit crazy having to deal with all the merges > > > and rebasing going on. > > > > > > If there was a separate device tree project, I would very much prefer > > > to use that and make device tree changes there such that I could > > > submit any additions to the canonical sources. I'm currently spending > > > too much of my development time synching the device trees in my U-Boot > > > tree with what's going on on the Linux side. > > > > Right, exactly. I have exactly the same problem and so do other people > > working with U-Boot. At least we have a work-around. > > I'm confused. I read this as Mark says "I need to solve this problem > for all users, I can't compile the device tree in to U-Boot as it will > be wrong" and then Simon says "Yes, compile in the device tree for all > users, that's what my series brings us". No I just mean, that for development, U-Boot is a nice place to build and include the DT, that's all. Mark is pointing out a workflow issue that I have had as well, in spades. It is useful to be able to modify the DT and have it be built by U-Boot. I did exactly the same thing when testing with m1n1. I'm not suggesting anything else. This is a storm in a teacup. The only reason DT has served U-Boot over all these years is that we have had control of it. Do you honestly think driver model would have worked without that? of-platdata? What about binman? I'm not giving it up until we have our bindings upstream and the DTs are discoverable and automatically downloadable as part of a build. The OF_PRIOR_STAGE thing should never have happened while we are in this precarious state. We need a way to keep control until we have things sorted out. If nothing else, it should help get the support of the people on these threads for getting bindings agreed. At least from what I can tell, the people who said we couldn't have U-Boot properties in the DT are quieter these days. Let's see if that continues. Regards, Simon
On Thu, Dec 02, 2021 at 12:12:16PM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 11:34, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > > > > appended to U-Boot > > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > > > not in favor of this new version either. > > > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > > > mainline…. > > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > > > more. > > > > > > > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > > > > it had not come to this. > > > > > > > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > > > > have a devicetree anywhere I can find. > > > > > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > > > > > whatever caveats and documentation people want to clarify what is > > > > > > > going on here. I'm happy to look at future options where the > > > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > > > > > within U-Boot for development purposes. > > > > > > > > > > > > > > I'll also note that the bootstd series shows the devicetree source: > > > > > > > > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > > > > > > > > > But for now, I still feel this is the best path forward. > > > > > > > > > > > > I'm not sure how to proceed here. The reviews are rather strongly > > > > > > against the "include a device tree that won't be used". The use case of > > > > > > "but for development someone might need to modify the device tree" is > > > > > > handled by platforms documenting where / how to get the real one. We > > > > > > should even update the Kconfig help to note that if you enable this your > > > > > > board docs MUST explain where the device tree can be seen (or have some > > > > > > legal reason you think it's OK to not...). > > > > > > > > > > Right, we can do lots of things as we have discussed. I am very > > > > > willing to work on these and make sure it is hard to do the thing. But > > > > > this series is long enough already. > > > > > > > > Yes, I think the rest of us had hoped you would come around to all of > > > > our reasoning by this point, is why this is taking so long. > > > > > > > > > > Look, if I thought this was all wrong I would not be doing it. We have > > > a range of opinions: > > > > And the rest of us wouldn't keep trying to argue otherwise if we didn't > > see problems with it, still. > > I don't claim it is perfect, just that it is better than what we have. > We have lots of ideas on how to improve things, e.g. > > - upstreaming the bindings > - having a way to obtain the correct DT through a script > - syncing the DT automatically with an external source > - applying validation to the in-tree DT > - using binman to make it easier to build images > > That will take a lot of effort and I don't see anyone else taking it > on. All we have is a lot of people with competing ideas, many > influenced by other projects (TF-A, QEMU, Xen, m1n1, etc.). We could > ask the coreboot people what they think, except that they banned > devicetree years ago. Sometimes I wish... Maybe part of the problem here is disagreement on the problems with what we have. The problems I see are: - We have some dts files out of sync with upstream, but this ISN'T a problem for them as the dtb in U-Boot never leaves the U-Boot world. It could, but it doesn't, so no one notices, and no one works to update it. This is typically 32bit ARM. - We have some dts files out of sync with upstream, AND this IS a problem for them as the dtb can be passed along to the OS, typically via bootefi and so 64bit ARM platforms. - We have a number of u-boot prefixed properties and they need to be both upstreamed and perhaps re-evaluated because it's sometimes very much not clear when / why people need them, as can be seen by some of the copy/paste that's in the -u-boot.dtsi files now, including the typod ones we talked about on IRC. - We're very very inconsistent with the case of "a valid device tree for the OS and/or us exists in memory". It's this last case that's causing all of the headaches in this series because on the one hand, there's only a few platforms here, today. On the other hand, there's a very very strong push for 64bit ARM platforms to all join in this group because given the nature of the architecture, some other firmware runs before us and in theory could / should be responsible. > > > - U-Boot should not have its own nodes/properties > > > > The caveat there is that aren't documented upstream bindings. I think > > at this point the lack of screaming and otherwise "wait, no no no > > don't!" that your current patch has gotten means it's time for a pull > > request, and for that to go in, and so this line of argument would be > > simply removed. > > That is going to be a long process. I have >100 patches pending and > only so much energy. We need to make incremental progress and we need > a development setup that works for U-Boot developers. Right, it will take a bit of time. But it's also the case that you're the person that most deeply understands a good number of them. > > > - U-Boot should not have DTs in-tree > > > > ... for the cases where the DTs are not used at run time, yes. > > Except when they are. E.g. for rpi3 I do actually use the in-tree .dtb > for development. I don't what that to be a hassle. U-Boot is a > development project and it needs to be easy. But it's also a user platform. And it's causing us problems. This is the thread I was referring to earlier: https://lore.kernel.org/u-boot/20211125194223.1094066-1-sjoerd@collabora.com/ and it's not the first, or possibly even only outstanding problem right now. I very much get that part of the overall device tree development cycle is painful. One thought I had today was that one issue here is that you see a problem of "I have 10 boards and each board wants me to supply an updated device tree in its own way, let me unify that". Others of us (at least myself) see a problem of "10 vendors have officially declared you update the device tree for their platform like $this, which is unfortunate but pretty well set in stone, with things well outside our control depending on this". So, to me, the root cause problem with Pi support is that we have rpi_4 and rpi_3 and so forth defconfigs when they should all be supported via rpi_arm64 which uses the device tree passed from the firmware blob and ready for Linux to consume. And if you need to modify the dtb, you do it the supported way via config.txt. Which means that yes, we're back at my point about 10 vendors and so 10 ways to do the same concept. Which is a huge sink when you're working with 10 different platforms. > > > - U-Boot should have DTs only when essential > > > > I don't understand this point. Can you please elaborate? > > That it should only be in U-Boot if there is no way it can be anywhere else. Because of say u-boot,dm-pre-reloc properties, or do you mean the whole device tree itself? > > > - U-Boot should have DTs in-tree for all boards > > > > This is the line you're pushing and almost every other reviewer > > disagrees with. > > Yes. > > > > > > What's the downside here anyway? > > > > - A lack of clarity. We have dts files, you modify those dts files, > > they aren't used. What's the point? Oh, you forgot to tweak > > something else. Wait, now nothing works. Oh, it's a mismatch between > > what this dts was at one point, and what it needs to be now to > > actually work. > > That's not my experience with this series. It seems to work fine. > Ilias and Heinrich have both pointed to things that 'don't work', but > actually I believe things work just as they do now. I'm talking about for average developers. I just answered a question on StackOverflow earlier this week about what all the device trees that are everywhere are even used for, and what needs to be modified to have a change actually show up. The DTS situation in general has a very steep learning curve and this will make things harder I believe. > > - We're adding more ongoing sync-up work. While I loudly applaud the > > custodians that are keeping their dts files in sync very regularly, > > and I sympathize with the custodians that want to do it more, but are > > unable to find the time, I do not want to add more of this work. Even > > more so when it's unclear who would be doing it. Or what the use is. > > Well we can make this better, but it is a small number of boards. It > is in the noise. I'm basing my concern here on the number of SoCs that regularly resync vs the ones that do not. > > There's probably more if I think about it harder, but those are the > > first to spring to mind. > > > > > > > It is more than just development. A devicetree is needed for binman to > > > > > work, even if it is empty. The documentation idea doesn't really work, > > > > > as I think I have proven by the difficulty in getting this series > > > > > together. An automated mechanism that runs in CI might be acceptable, > > > > > but that is in the future. For now, I believe it just HAS to be > > > > > in-tree. > > > > > > > > I still don't see any reason why we need these incorrect and not > > > > functionally used device trees in-tree when a dummy invalid tree is > > > > enough to make things link. We're dealing with real "we must have X.bin > > > > in the output for things to function" issues on other platforms with > > > > binman right now. Using a dummy dts should be fine. > > > > > > Incorrect in what way? > > > > Well, in the QEMU instance, they're only as correct as the parameters > > passed to qemu-system-foo when you did -dumpdtb to start with. Lets > > take TPM as that now should show up in the device tree, or not, > > depending on if we have the backend side of it? Or all of the examples > > of how to arbitrarily configure a system as Heinrich noted. > > > > Or the Pi examples where we need to use the device tree passed to us > > because config.txt is the official way to modify things in the device > > tree on that platform. > > OK, so when you add extra parameters to the ARM and RISC-V QEMU > command line, it doesn't add those extra parameters and those extra > devices are not present.That does not sound surprising to me. It > should be obvious to anyone doing development on these boards. Why is it going to be obvious that we're ignoring the supplied device tree? Why is it expected that U-Boot works like this, when nothing else does? > > > How do I get a real one for development? How do I turn off OF_BOARD > > > and use the in-tree one? > > > > How do you turn off the run-time device tree and instead use the in-tree > > one for development, with your series? > > Disable OF_BOARD manually. As we discussed, we can put that behind an > EXPERT flag or a build flag, or other things. There is a message > printed when U-Boot starts, too (with a later series). OK, so what I'm saying is that for rpi_arm64, qemu_arm*, etc, etc, the default builds that dummy empty device tree, and when you want to do your developer use case you disable OF_BOARD and set it to point at what you want. > > > The documentation approach is not good enough. > > > > Why? But maybe I can better explain things in Mark's part of the thread > > about power domains and serial on M1.. > > Because I can't find the DT and it takes manual effort to locate it > and set it up for development. It is just too hard. You're optimizing things for the "I'm developing on 10 arbitrary different SoCs" which isn't the common use case. Mark for example doesn't have a problem figuring out where the M1 dts files live, no one working on Pi has problems finding the Pi dts files, the Xen folks know what's up in their case, and so on. Yes, the developing broadly use case is hard and needs better documentation so that it's not too hard to come up to speed on a new platform. That's true for everyone. > > > > > > And yes, we're "only" talking about 10 platforms, which include things > > > > > > like the "everyone" has one Pi family, the extraordinarily flexible (and > > > > > > so easy for the reference device tree to be very wrong) QEMU families > > > > > > and then platforms that are including a dts in-tree now because they > > > > > > were told that was required. > > > > > > > > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is > > > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot? > > > > > The argument is the same. > > > > > > > > Because we don't need it! It serves no purpose! It exists in Linux > > > > as that's the primary device tree source repository. We could _copy_ it > > > > in, if it was useful. But then we need to re-sync it every so often, > > > > and for less clear reasons than all of the platforms that we need to > > > > sync with the kernel for, AND we use the tree. > > > > > > So some people don't need it and it serves no purpose for them. But > > > why do they care? It is not hurting anyone. This is all overblown. > > > > Because it's adding ongoing maintenance work, and reducing clarity of > > the codebase, to summarize my concerns above. > > Yes, but can we just accept that as a cost? We have plans and ideas to > reduce it over time, right? In that there's lessons to learn from other projects about source layout so it's easier to re-sync files, sure, there's ideas. But it also continues to just ignore / set aside the problem of how frequently how much of device trees change. It's getting better over time and validation being non-optional in Linux moving forward will really help. But it's still work, and still makes things unclear where / why we're doing what we would be doing. If we're given a perfectly functional and correct device tree in memory for a Pi for example, why do we not use it by default and instead pick one that was built in to U-Boot and misses the changes the user may have made on purpose. That is part of clarity as well. > > > > There's even an argument to be made that it IS in Linux because when you > > > > build that dtb, it's what the firmware then ships and uses and provides > > > > to everyone at run time, possibly along with whatever other > > > > modifications the binary firmware did (see the assorted threads, > > > > including one this week about the problems we have because we don't just > > > > always use the dtb provided to us at run time). > > > > > > > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now > > > > > copied by RISC-V) which doesn't. > > > > > > > > Yes, these are more examples of "someone said we need to copy it in, so > > > > we copy it in". > > > > > > No that's not correct. With x86, ppc, integrator, ast2500 and many > > > others we *need* the DT and *it is not* created by QEMU. > > > > You're listing both QEMU virtual machines and QEMU-as-hardware-emulators > > above, which confuses things. The integrator code runs on real > > hardware. Real hardware which does not have the device tree on it. I > > assume that QEMU + Linux - U-Boot for integrator requires you to pass > > the .dtb in, just like real the real hardware does. That's true of all > > of the cases I believe where we use QEMU-as-hardware-emulator because > > QEMU is also authentic to the hardware. > > Yes, I get it. But the common case just works and I want to use binman > images in CI as well as development with these things, without hacking > QEMU itself. It is just not sensible to have to upgrade QEMU just to > get an updated DT for trying something out. I don't follow you. There's nothing special about the integrator build in CI, which is the whole point. And then I keep saying that if you're modifying the dtb from QEMU, and it's not just a proof of concept or something being developed and upstreamed, something is wrong with our flow. We have something backwards and need to evaluate it. > > > > > > How about adjusting the make logic so that if a tree isn't found, we use > > > > > > a dummy minimal valid dts file? > > > > > > > > > > This is what I have done for the boards where I could not figure out > > > > > how to get any sort of DT, yes. But I don't think that should be the > > > > > default. > > > > > > > > The more I think about this, the more I think dummy minimal valid dts > > > > should be the fall-back default. This then solves the "I'm a developer, > > > > I need to modify the dts files" case because you then just provide the > > > > dts instead where it should go, and it's used. > > > > > > How does it solve it? I don't even know how to get it in many cases. > > > If it is a dummy then I cannot actually use it for development, right? > > > > It solves the problem of "we must have this dts file so that the build > > will not fail". The next step of "oh, we actually want to use it, and > > not the run-time provided dtb" would be the same as whatever you're > > doing with this series. > > Not in my experience. For example, with QEMU I was able to use an > in-tree .dts for the bootstd stuff without any issues. This series > also explains how to discover the DT, at least for the two QEMU boards > that need it. Then something is backwards still. You should be able to flip the CONFIG switch to have the arbitrary dtb you want used, but the default should be the provided device tree.
On Thu, Dec 02, 2021 at 11:36:59PM +0100, François Ozog wrote: > Hi Simon,Tom > > Le jeu. 2 déc. 2021 à 19:34, Tom Rini <trini@konsulko.com> a écrit : > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> > > wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> > > a écrit : > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > OF_HOSTFILE so > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is > > built and > > > > > > > > > > appended to U-Boot > > > > > > > > > > - OF_EMBED - for development purposes, the devicetree > > is embedded in > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > needed at all > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > > don't. Some > > > > > > > > > > don't even provide instructions on how to boot on the > > board. > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > > patch in this > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > > OF_SEPARATE. Any board > > > > > > > > > > can obtain its devicetree at runtime, even it is has a > > devicetree built > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > bootloader and its > > > > > > > > > > caller may have a better idea about the hardware available > > in the machine. > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > should be an > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > devicetree files > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > > to add the > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > way. The > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > current state > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > *control* devicetrees > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > list.so I am > > > > > > > > > not in favor of this new version either. > > > > > > > > > If you make a version without « fake DTs » as you name them, > > there are good > > > > > > > > > advances in the documentation and other areas that would be > > better in > > > > > > > > > mainline…. > > > > > > > > > If I am the only one thinking this way and the patch can be > > accepted, I > > > > > > > > > would love there is a warning in capital letters at the top > > of the DTS fake > > > > > > > > > files that explains the intent of this fake DT, the possible > > outcomes of > > > > > > > > > not using the one provided by the platform and the right way > > of dealing > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > want > > > > > > > > reference or fake or whatever device trees in the U-Boot > > source tree. > > > > > > > > We should be able to _remove_ the ones we have, that are not > > required, > > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > adding > > > > > > > > more. > > > > > > > > > > > > > > I understand you don't like it and that others don't as well. I > > wish > > > > > > > it had not come to this. > > > > > > > > > > > > > > However we are only talking about 10 boards, three of which > > don't even > > > > > > > have a devicetree anywhere I can find. > > > > > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to > > add > > > > > > > whatever caveats and documentation people want to clarify what is > > > > > > > going on here. I'm happy to look at future options where the > > > > > > > devicetree is hosted elsewhere, so long as it is trivial to > > build it > > > > > > > within U-Boot for development purposes. > > > > > > > > > > > > > > I'll also note that the bootstd series shows the devicetree > > source: > > > > > > > > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > > > > > > > > > But for now, I still feel this is the best path forward. > > > > > > > > > > > > I'm not sure how to proceed here. The reviews are rather strongly > > > > > > against the "include a device tree that won't be used". The use > > case of > > > > > > "but for development someone might need to modify the device tree" > > is > > > > > > handled by platforms documenting where / how to get the real one. > > We > > > > > > should even update the Kconfig help to note that if you enable > > this your > > > > > > board docs MUST explain where the device tree can be seen (or have > > some > > > > > > legal reason you think it's OK to not...). > > > > > > > > > > Right, we can do lots of things as we have discussed. I am very > > > > > willing to work on these and make sure it is hard to do the thing. > > But > > > > > this series is long enough already. > > > > > > > > Yes, I think the rest of us had hoped you would come around to all of > > > > our reasoning by this point, is why this is taking so long. > > > > > > > > > > Look, if I thought this was all wrong I would not be doing it. We have > > > a range of opinions: > > > > And the rest of us wouldn't keep trying to argue otherwise if we didn't > > see problems with it, still. > > > > > - U-Boot should not have its own nodes/properties > > > > The caveat there is that aren't documented upstream bindings. I think > > at this point the lack of screaming and otherwise "wait, no no no > > don't!" that your current patch has gotten means it's time for a pull > > request, and for that to go in, and so this line of argument would be > > simply removed. > > > > > - U-Boot should not have DTs in-tree > > > > ... for the cases where the DTs are not used at run time, yes. > > > > > - U-Boot should have DTs only when essential > > > > I don't understand this point. Can you please elaborate? > > > > > - U-Boot should have DTs in-tree for all boards > > > > This is the line you're pushing and almost every other reviewer > > disagrees with. > > For the sake of getting interesting parts of the patch set in and “move > on”, what about: > providing an empty (see below) DT for boards for which U-Boot receives the > “source of truth” so that there are no build issues. > The empty DT contains a comment that explains the DT lifecycle for the > board and points to the documentation tree for sample DTs. > The boards would the ones we talked about and SystemReady boards > https://www.arm.com/why-arm/architecture/systems/systemready-certification-program/ir?_ga=2.35159527.79382615.1638484482-159131740.1638484482 My ROCKPro64 is on the way still, but I'm not sure what SystemReady IR has to do with this exactly. I mean this very much seriously as I was doing some testing with another platform in preparation for certification and I was just using the device tree that in U-Boot. Perhaps I just missed a section in one of the documents however.
Hi Tom, On Thu, 2 Dec 2021 at 15:53, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 02, 2021 at 11:36:59PM +0100, François Ozog wrote: > > Hi Simon,Tom > > > > Le jeu. 2 déc. 2021 à 19:34, Tom Rini <trini@konsulko.com> a écrit : > > > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> > > > a écrit : > > > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > OF_HOSTFILE so > > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is > > > built and > > > > > > > > > > > appended to U-Boot > > > > > > > > > > > - OF_EMBED - for development purposes, the devicetree > > > is embedded in > > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > > needed at all > > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > > > don't. Some > > > > > > > > > > > don't even provide instructions on how to boot on the > > > board. > > > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > > > patch in this > > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > > > OF_SEPARATE. Any board > > > > > > > > > > > can obtain its devicetree at runtime, even it is has a > > > devicetree built > > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > bootloader and its > > > > > > > > > > > caller may have a better idea about the hardware available > > > in the machine. > > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > > should be an > > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > > devicetree files > > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > > > to add the > > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > way. The > > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > current state > > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > > *control* devicetrees > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > list.so I am > > > > > > > > > > not in favor of this new version either. > > > > > > > > > > If you make a version without « fake DTs » as you name them, > > > there are good > > > > > > > > > > advances in the documentation and other areas that would be > > > better in > > > > > > > > > > mainline…. > > > > > > > > > > If I am the only one thinking this way and the patch can be > > > accepted, I > > > > > > > > > > would love there is a warning in capital letters at the top > > > of the DTS fake > > > > > > > > > > files that explains the intent of this fake DT, the possible > > > outcomes of > > > > > > > > > > not using the one provided by the platform and the right way > > > of dealing > > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > > want > > > > > > > > > reference or fake or whatever device trees in the U-Boot > > > source tree. > > > > > > > > > We should be able to _remove_ the ones we have, that are not > > > required, > > > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > > adding > > > > > > > > > more. > > > > > > > > > > > > > > > > I understand you don't like it and that others don't as well. I > > > wish > > > > > > > > it had not come to this. > > > > > > > > > > > > > > > > However we are only talking about 10 boards, three of which > > > don't even > > > > > > > > have a devicetree anywhere I can find. > > > > > > > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to > > > add > > > > > > > > whatever caveats and documentation people want to clarify what is > > > > > > > > going on here. I'm happy to look at future options where the > > > > > > > > devicetree is hosted elsewhere, so long as it is trivial to > > > build it > > > > > > > > within U-Boot for development purposes. > > > > > > > > > > > > > > > > I'll also note that the bootstd series shows the devicetree > > > source: > > > > > > > > > > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > > > > > > > > > > > But for now, I still feel this is the best path forward. > > > > > > > > > > > > > > I'm not sure how to proceed here. The reviews are rather strongly > > > > > > > against the "include a device tree that won't be used". The use > > > case of > > > > > > > "but for development someone might need to modify the device tree" > > > is > > > > > > > handled by platforms documenting where / how to get the real one. > > > We > > > > > > > should even update the Kconfig help to note that if you enable > > > this your > > > > > > > board docs MUST explain where the device tree can be seen (or have > > > some > > > > > > > legal reason you think it's OK to not...). > > > > > > > > > > > > Right, we can do lots of things as we have discussed. I am very > > > > > > willing to work on these and make sure it is hard to do the thing. > > > But > > > > > > this series is long enough already. > > > > > > > > > > Yes, I think the rest of us had hoped you would come around to all of > > > > > our reasoning by this point, is why this is taking so long. > > > > > > > > > > > > > Look, if I thought this was all wrong I would not be doing it. We have > > > > a range of opinions: > > > > > > And the rest of us wouldn't keep trying to argue otherwise if we didn't > > > see problems with it, still. > > > > > > > - U-Boot should not have its own nodes/properties > > > > > > The caveat there is that aren't documented upstream bindings. I think > > > at this point the lack of screaming and otherwise "wait, no no no > > > don't!" that your current patch has gotten means it's time for a pull > > > request, and for that to go in, and so this line of argument would be > > > simply removed. > > > > > > > - U-Boot should not have DTs in-tree > > > > > > ... for the cases where the DTs are not used at run time, yes. > > > > > > > - U-Boot should have DTs only when essential > > > > > > I don't understand this point. Can you please elaborate? > > > > > > > - U-Boot should have DTs in-tree for all boards > > > > > > This is the line you're pushing and almost every other reviewer > > > disagrees with. > > > > For the sake of getting interesting parts of the patch set in and “move > > on”, what about: > > providing an empty (see below) DT for boards for which U-Boot receives the > > “source of truth” so that there are no build issues. > > The empty DT contains a comment that explains the DT lifecycle for the > > board and points to the documentation tree for sample DTs. > > The boards would the ones we talked about and SystemReady boards > > https://www.arm.com/why-arm/architecture/systems/systemready-certification-program/ir?_ga=2.35159527.79382615.1638484482-159131740.1638484482 > > My ROCKPro64 is on the way still, but I'm not sure what SystemReady IR > has to do with this exactly. I mean this very much seriously as I was > doing some testing with another platform in preparation for > certification and I was just using the device tree that in U-Boot. > Perhaps I just missed a section in one of the documents however. So now we find out the full horror of the fragmented mess that things are to become. No way does this make sense. It is already too hard to build things. Just look at the meson/binman series I sent last week. We need to make things easier for people, not harder. Regards, Simon
Hi Tom, On Thu, 2 Dec 2021 at 15:47, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 02, 2021 at 12:12:16PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:34, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > > > > > appended to U-Boot > > > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > > > > not in favor of this new version either. > > > > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > > > > mainline…. > > > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > > > > more. > > > > > > > > > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > > > > > it had not come to this. > > > > > > > > > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > > > > > have a devicetree anywhere I can find. > > > > > > > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > > > > > > whatever caveats and documentation people want to clarify what is > > > > > > > > going on here. I'm happy to look at future options where the > > > > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > > > > > > within U-Boot for development purposes. > > > > > > > > > > > > > > > > I'll also note that the bootstd series shows the devicetree source: > > > > > > > > > > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > > > > > > > > > > > But for now, I still feel this is the best path forward. > > > > > > > > > > > > > > I'm not sure how to proceed here. The reviews are rather strongly > > > > > > > against the "include a device tree that won't be used". The use case of > > > > > > > "but for development someone might need to modify the device tree" is > > > > > > > handled by platforms documenting where / how to get the real one. We > > > > > > > should even update the Kconfig help to note that if you enable this your > > > > > > > board docs MUST explain where the device tree can be seen (or have some > > > > > > > legal reason you think it's OK to not...). > > > > > > > > > > > > Right, we can do lots of things as we have discussed. I am very > > > > > > willing to work on these and make sure it is hard to do the thing. But > > > > > > this series is long enough already. > > > > > > > > > > Yes, I think the rest of us had hoped you would come around to all of > > > > > our reasoning by this point, is why this is taking so long. > > > > > > > > > > > > > Look, if I thought this was all wrong I would not be doing it. We have > > > > a range of opinions: > > > > > > And the rest of us wouldn't keep trying to argue otherwise if we didn't > > > see problems with it, still. > > > > I don't claim it is perfect, just that it is better than what we have. > > We have lots of ideas on how to improve things, e.g. > > > > - upstreaming the bindings > > - having a way to obtain the correct DT through a script > > - syncing the DT automatically with an external source > > - applying validation to the in-tree DT > > - using binman to make it easier to build images > > > > That will take a lot of effort and I don't see anyone else taking it > > on. All we have is a lot of people with competing ideas, many > > influenced by other projects (TF-A, QEMU, Xen, m1n1, etc.). We could > > ask the coreboot people what they think, except that they banned > > devicetree years ago. Sometimes I wish... > > Maybe part of the problem here is disagreement on the problems with what > we have. The problems I see are: > - We have some dts files out of sync with upstream, but this ISN'T a > problem for them as the dtb in U-Boot never leaves the U-Boot world. > It could, but it doesn't, so no one notices, and no one works to > update it. This is typically 32bit ARM. > - We have some dts files out of sync with upstream, AND this IS a > problem for them as the dtb can be passed along to the OS, typically > via bootefi and so 64bit ARM platforms. > - We have a number of u-boot prefixed properties and they need to be > both upstreamed and perhaps re-evaluated because it's sometimes very > much not clear when / why people need them, as can be seen by some of > the copy/paste that's in the -u-boot.dtsi files now, including the > typod ones we talked about on IRC. > - We're very very inconsistent with the case of "a valid device tree for > the OS and/or us exists in memory". > > It's this last case that's causing all of the headaches in this series > because on the one hand, there's only a few platforms here, today. On > the other hand, there's a very very strong push for 64bit ARM platforms > to all join in this group because given the nature of the architecture, > some other firmware runs before us and in theory could / should be > responsible. I don't think it will matter much, though, in the end. If what you say comes to pass then we will have a consistent DT everywhere and it won't matter where it comes from. After all, in the end we need to produce a single firmware image. If binman is used for that, the DT will be placed there. For development, we may have a situation where all the other bits are blobs and just U-Boot is being iterated, to get the higher-level features working properly. We need a way to update the DT easily, e.g. just building it with U-Boot. That is something I do a *lot* and that is what I'm not giving up. Not until it is clearer how things are going to land over the next few years. > > > > > - U-Boot should not have its own nodes/properties > > > > > > The caveat there is that aren't documented upstream bindings. I think > > > at this point the lack of screaming and otherwise "wait, no no no > > > don't!" that your current patch has gotten means it's time for a pull > > > request, and for that to go in, and so this line of argument would be > > > simply removed. > > > > That is going to be a long process. I have >100 patches pending and > > only so much energy. We need to make incremental progress and we need > > a development setup that works for U-Boot developers. > > Right, it will take a bit of time. But it's also the case that you're > the person that most deeply understands a good number of them. > > > > > - U-Boot should not have DTs in-tree > > > > > > ... for the cases where the DTs are not used at run time, yes. > > > > Except when they are. E.g. for rpi3 I do actually use the in-tree .dtb > > for development. I don't what that to be a hassle. U-Boot is a > > development project and it needs to be easy. > > But it's also a user platform. And it's causing us problems. This is > the thread I was referring to earlier: > https://lore.kernel.org/u-boot/20211125194223.1094066-1-sjoerd@collabora.com/ > and it's not the first, or possibly even only outstanding problem right > now. That is dealing with fixing up a loaded DT, as I understand it. We have that problem anyway when we use a loaded DT to pass to Linux. If so, it isn't really related to what we are talking about here. > > I very much get that part of the overall device tree development cycle > is painful. One thought I had today was that one issue here is that you > see a problem of "I have 10 boards and each board wants me to supply an > updated device tree in its own way, let me unify that". Others of us > (at least myself) see a problem of "10 vendors have officially declared > you update the device tree for their platform like $this, which is > unfortunate but pretty well set in stone, with things well outside our > control depending on this". > > So, to me, the root cause problem with Pi support is that we have rpi_4 > and rpi_3 and so forth defconfigs when they should all be supported via > rpi_arm64 which uses the device tree passed from the firmware blob and > ready for Linux to consume. And if you need to modify the dtb, you do > it the supported way via config.txt. Which means that yes, we're back > at my point about 10 vendors and so 10 ways to do the same concept. > Which is a huge sink when you're working with 10 different platforms. OK. > > > > > - U-Boot should have DTs only when essential > > > > > > I don't understand this point. Can you please elaborate? > > > > That it should only be in U-Boot if there is no way it can be anywhere else. > > Because of say u-boot,dm-pre-reloc properties, or do you mean the whole > device tree itself? No I mean this is a position people are taking. I think it destructive. U-Boot should be able to have the DT, just like any other project. They should all be identical (one day), but there is no reason to strip things out of U-Boot just because some other random project decides it wants to pass one along at runtime. > > > > > - U-Boot should have DTs in-tree for all boards > > > > > > This is the line you're pushing and almost every other reviewer > > > disagrees with. > > > > Yes. > > > > > > > > > What's the downside here anyway? > > > > > > - A lack of clarity. We have dts files, you modify those dts files, > > > they aren't used. What's the point? Oh, you forgot to tweak > > > something else. Wait, now nothing works. Oh, it's a mismatch between > > > what this dts was at one point, and what it needs to be now to > > > actually work. > > > > That's not my experience with this series. It seems to work fine. > > Ilias and Heinrich have both pointed to things that 'don't work', but > > actually I believe things work just as they do now. > > I'm talking about for average developers. I just answered a question on > StackOverflow earlier this week about what all the device trees that are > everywhere are even used for, and what needs to be modified to have a > change actually show up. The DTS situation in general has a very steep > learning curve and this will make things harder I believe. OK so I have added: - a way to detect where the DT comes from - showing that on the console - OF_BOARD Is still the default for boards that use it I have offered later: - EXPERT mode to override turning OF_BOARD for boards where it should be enabled - build-time warnings - a build-time environment var/flag to enable this What more do you want? :-) Honestly, let's just go with it. > > > > - We're adding more ongoing sync-up work. While I loudly applaud the > > > custodians that are keeping their dts files in sync very regularly, > > > and I sympathize with the custodians that want to do it more, but are > > > unable to find the time, I do not want to add more of this work. Even > > > more so when it's unclear who would be doing it. Or what the use is. > > > > Well we can make this better, but it is a small number of boards. It > > is in the noise. > > I'm basing my concern here on the number of SoCs that regularly resync > vs the ones that do not. This is not going to be solved this week or next. But we have a plan to resolve it and the current state actually makes all this harder. > > > > There's probably more if I think about it harder, but those are the > > > first to spring to mind. > > > > > > > > > It is more than just development. A devicetree is needed for binman to > > > > > > work, even if it is empty. The documentation idea doesn't really work, > > > > > > as I think I have proven by the difficulty in getting this series > > > > > > together. An automated mechanism that runs in CI might be acceptable, > > > > > > but that is in the future. For now, I believe it just HAS to be > > > > > > in-tree. > > > > > > > > > > I still don't see any reason why we need these incorrect and not > > > > > functionally used device trees in-tree when a dummy invalid tree is > > > > > enough to make things link. We're dealing with real "we must have X.bin > > > > > in the output for things to function" issues on other platforms with > > > > > binman right now. Using a dummy dts should be fine. > > > > > > > > Incorrect in what way? > > > > > > Well, in the QEMU instance, they're only as correct as the parameters > > > passed to qemu-system-foo when you did -dumpdtb to start with. Lets > > > take TPM as that now should show up in the device tree, or not, > > > depending on if we have the backend side of it? Or all of the examples > > > of how to arbitrarily configure a system as Heinrich noted. > > > > > > Or the Pi examples where we need to use the device tree passed to us > > > because config.txt is the official way to modify things in the device > > > tree on that platform. > > > > OK, so when you add extra parameters to the ARM and RISC-V QEMU > > command line, it doesn't add those extra parameters and those extra > > devices are not present.That does not sound surprising to me. It > > should be obvious to anyone doing development on these boards. > > Why is it going to be obvious that we're ignoring the supplied device > tree? Why is it expected that U-Boot works like this, when nothing else > does? Because U-Boot will print that out on boot: U-Boot 2021.10-00190 (Oct 30 2021 - 09:01:29 -0600) DRAM: 128 MiB > Core: 42 devices, 11 uclasses, devicetree: board [or passage, or separate] Flash: 64 MiB https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-23-sjg@chromium.org/ > > > > > How do I get a real one for development? How do I turn off OF_BOARD > > > > and use the in-tree one? > > > > > > How do you turn off the run-time device tree and instead use the in-tree > > > one for development, with your series? > > > > Disable OF_BOARD manually. As we discussed, we can put that behind an > > EXPERT flag or a build flag, or other things. There is a message > > printed when U-Boot starts, too (with a later series). > > OK, so what I'm saying is that for rpi_arm64, qemu_arm*, etc, etc, the > default builds that dummy empty device tree, and when you want to do > your developer use case you disable OF_BOARD and set it to point at what > you want. Where does that 'what you want' come from? > > > > > The documentation approach is not good enough. > > > > > > Why? But maybe I can better explain things in Mark's part of the thread > > > about power domains and serial on M1.. > > > > Because I can't find the DT and it takes manual effort to locate it > > and set it up for development. It is just too hard. > > You're optimizing things for the "I'm developing on 10 arbitrary > different SoCs" which isn't the common use case. Mark for example > doesn't have a problem figuring out where the M1 dts files live, no one > working on Pi has problems finding the Pi dts files, the Xen folks know > what's up in their case, and so on. Yes, the developing broadly use > case is hard and needs better documentation so that it's not too hard to > come up to speed on a new platform. That's true for everyone. It's not remotely feasible for me, at least. I'm pleased that it works for you, but a bit surprised. I don't want to give up the easy building that we have now, until we have something just as easy in place. > > > > > > > > And yes, we're "only" talking about 10 platforms, which include things > > > > > > > like the "everyone" has one Pi family, the extraordinarily flexible (and > > > > > > > so easy for the reference device tree to be very wrong) QEMU families > > > > > > > and then platforms that are including a dts in-tree now because they > > > > > > > were told that was required. > > > > > > > > > > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is > > > > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot? > > > > > > The argument is the same. > > > > > > > > > > Because we don't need it! It serves no purpose! It exists in Linux > > > > > as that's the primary device tree source repository. We could _copy_ it > > > > > in, if it was useful. But then we need to re-sync it every so often, > > > > > and for less clear reasons than all of the platforms that we need to > > > > > sync with the kernel for, AND we use the tree. > > > > > > > > So some people don't need it and it serves no purpose for them. But > > > > why do they care? It is not hurting anyone. This is all overblown. > > > > > > Because it's adding ongoing maintenance work, and reducing clarity of > > > the codebase, to summarize my concerns above. > > > > Yes, but can we just accept that as a cost? We have plans and ideas to > > reduce it over time, right? > > In that there's lessons to learn from other projects about source layout > so it's easier to re-sync files, sure, there's ideas. But it also > continues to just ignore / set aside the problem of how frequently how > much of device trees change. It's getting better over time and > validation being non-optional in Linux moving forward will really help. > But it's still work, and still makes things unclear where / why we're > doing what we would be doing. If we're given a perfectly functional and > correct device tree in memory for a Pi for example, why do we not use > it by default and instead pick one that was built in to U-Boot and > misses the changes the user may have made on purpose. That is part of > clarity as well. But I'm not saying we should not use it by default. This is what I find so confusing, that people are imputing some strange change here. I just want to be able to (as a dev) use the in-tree DT, if I want to, if I know what I am doing. When we have a better system for getting the DT for development purposes, let's use it. But we don't. Again, this series changes *nothing* about how rpi works by default. > > > > > > There's even an argument to be made that it IS in Linux because when you > > > > > build that dtb, it's what the firmware then ships and uses and provides > > > > > to everyone at run time, possibly along with whatever other > > > > > modifications the binary firmware did (see the assorted threads, > > > > > including one this week about the problems we have because we don't just > > > > > always use the dtb provided to us at run time). > > > > > > > > > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now > > > > > > copied by RISC-V) which doesn't. > > > > > > > > > > Yes, these are more examples of "someone said we need to copy it in, so > > > > > we copy it in". > > > > > > > > No that's not correct. With x86, ppc, integrator, ast2500 and many > > > > others we *need* the DT and *it is not* created by QEMU. > > > > > > You're listing both QEMU virtual machines and QEMU-as-hardware-emulators > > > above, which confuses things. The integrator code runs on real > > > hardware. Real hardware which does not have the device tree on it. I > > > assume that QEMU + Linux - U-Boot for integrator requires you to pass > > > the .dtb in, just like real the real hardware does. That's true of all > > > of the cases I believe where we use QEMU-as-hardware-emulator because > > > QEMU is also authentic to the hardware. > > > > Yes, I get it. But the common case just works and I want to use binman > > images in CI as well as development with these things, without hacking > > QEMU itself. It is just not sensible to have to upgrade QEMU just to > > get an updated DT for trying something out. > > I don't follow you. There's nothing special about the integrator build > in CI, which is the whole point. > > And then I keep saying that if you're modifying the dtb from QEMU, and > it's not just a proof of concept or something being developed and > upstreamed, something is wrong with our flow. We have something > backwards and need to evaluate it. Why? There are going to be dozens of different pre-boot loaders, right? Everyone loves writing a new pre-boot loader. How else are you going to deal with whatever weird way each one of them produces a DT so you can modify it for development purposes. Do you want to have to rebuild that pre-boot loader from source every time you want to make a change? Inserting it with U-Boot is the only sane way to develop U-Boot. Mark has found that. I know it for a fact. So we have to make it *impossible* to insert a DT that U-Boot actually uses. Why? > > > > > > > > How about adjusting the make logic so that if a tree isn't found, we use > > > > > > > a dummy minimal valid dts file? > > > > > > > > > > > > This is what I have done for the boards where I could not figure out > > > > > > how to get any sort of DT, yes. But I don't think that should be the > > > > > > default. > > > > > > > > > > The more I think about this, the more I think dummy minimal valid dts > > > > > should be the fall-back default. This then solves the "I'm a developer, > > > > > I need to modify the dts files" case because you then just provide the > > > > > dts instead where it should go, and it's used. > > > > > > > > How does it solve it? I don't even know how to get it in many cases. > > > > If it is a dummy then I cannot actually use it for development, right? > > > > > > It solves the problem of "we must have this dts file so that the build > > > will not fail". The next step of "oh, we actually want to use it, and > > > not the run-time provided dtb" would be the same as whatever you're > > > doing with this series. > > > > Not in my experience. For example, with QEMU I was able to use an > > in-tree .dts for the bootstd stuff without any issues. This series > > also explains how to discover the DT, at least for the two QEMU boards > > that need it. > > Then something is backwards still. You should be able to flip the > CONFIG switch to have the arbitrary dtb you want used, but the default > should be the provided device tree. Yes, agreed. Have I not been saying that from the start? What are we still discussing? I cannot reconcile that statement with what you have said above. Email is such a nightmare. Regards, Simon
On Thu, 2 Dec 2021 09:39:52 -0700 Simon Glass <sjg@chromium.org> wrote: Hi, wow, this thread quickly exploded, jumping in here randomly to add my thoughts: > Hi François, > > On Thu, 2 Dec 2021 at 09:34, François Ozog <francois.ozog@linaro.org> wrote: > > > > Hi Simon > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > >> > >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > >> there are only three ways to obtain a devicetree: > >> > >> - OF_SEPARATE - the normal way, where the devicetree is built and > >> appended to U-Boot > >> - OF_EMBED - for development purposes, the devicetree is embedded in > >> the ELF file (also used for EFI) > >> - OF_BOARD - the board figures it out on its own > >> > >> The last one is currently set up so that no devicetree is needed at all > >> in the U-Boot tree. Most boards do provide one, but some don't. Some > >> don't even provide instructions on how to boot on the board. > >> > >> The problems with this approach are documented in another patch in this > >> series: "doc: Add documentation about devicetree usage" > >> > >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > >> can obtain its devicetree at runtime, even it is has a devicetree built > >> in U-Boot. This is because U-Boot may be a second-stage bootloader and its > >> caller may have a better idea about the hardware available in the machine. > >> This is the case with a few QEMU boards, for example. > >> > >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an > >> option, available with either OF_SEPARATE or OF_EMBED. > >> > >> This series makes this change, adding various missing devicetree files > >> (and placeholders) to make the build work. > >> > >> Note: If board maintainers are able to add their own patch to add the > >> files, some patches in this series can be dropped. > >> > >> It also provides a few qemu clean-ups discovered along the way. The > >> qemu-riscv64_spl problem is fixed. > >> > >> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > >> > >> Changes in v6: > >> - Fix description of OF_BOARD so it refers just to the current state > >> - Explain that the 'two devicetrees' refers to two *control* devicetrees > >> - Expand the commit message based on comments > >> - Expand the commit message based on comments > > > > You haven’t addressed any concerns expressed on the mailing list.so I am not in favor of this new version either. > > Please see the change log. I have addressed everything except the > fundamental disagreement we have. > > > If you make a version without « fake DTs » as you name them, there are good advances in the documentation and other areas that would be better in mainline…. > > If I am the only one thinking this way and the patch can be accepted, I would love there is a warning in capital letters at the top of the DTS fake files that explains the intent of this fake DT, the possible outcomes of not using the one provided by the platform and the right way of dealing with DTs for the platform. > > The word 'fake' applies to only three of the boards (highbank, bcm7xxx > and octeontx), where I could not even figure out where to get a > devicetree. One might think this would be a significant problem! But why? Actually it's the exact opposite, Highbank is somewhat of a (sadly abandoned) poster book child of DT usage: Before the Cortex-A cores boot, the DTB gets loaded by the management processor (ECME) from NOR flash into DRAM. There the memory node gets populated, based on what the ECME detected (it has a DIMM slot!). Then this DTB gets used by U-Boot, which adds the command line and initrd information, based on user choices. And this is eventually consumed by a kernel. So the base DTB here is provided by the system, and software just reacts to it - how it should be. The (arm64) Linux kernel works on this idea: exactly *one* binary image, and the drivers that are needed by the hardware get loaded based on DT information. The fact the .dts files live in the kernel tree is more for practical reasons, because it started there, we enhance DTs and should have a repo holding them, plus all the review knowledge is in the kernel community. Cheers, Andre P.S. I started writing some documentation for Highbank, to be posted soonish. > > Anyway yes I can add a comment to all the files, but please try to ask > for everything at once as there is a cost to continually reworking > this series. > > Regards, > Simon > > >> > >> > >> Changes in v5: > >> - Bring into the OF_BOARD series > >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > >> - Refer to the 'control' DTB in the first paragraph > >> - Use QEMU instead of qemu > >> - Merge RISC-V and ARM patches since they are similar > >> - Add new patches to clean up fdtdec_setup() and surrounds > >> > >> Changes in v3: > >> - Clarify the 'bug' refered to at the top > >> - Reword 'This means that there' paragraph to explain U-Boot-specific things > >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > >> > >> Changes in v2: > >> - Fix typos per Sean (thank you!) and a few others > >> - Add a 'Use of U-Boot /config node' section > >> - Drop mention of dm-verity since that actually uses the kernel cmdline > >> - Explain that OF_BOARD will still work after these changes (in > >> 'Once this bug is fixed...' paragraph) > >> - Expand a bit on the reason why the 'Current situation' is bad > >> - Clarify in a second place that Linux and U-Boot use the same devicetree > >> in 'To be clear, while U-Boot...' > >> - Expand on why we should have rules for other projects in > >> 'Devicetree in another project' > >> - Add a comment as to why devicetree in U-Boot is not 'bad design' > >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover > >> points raised on v1 > >> - Add 'Why does U-Boot have its nodes and properties?' > >> - Add 'Why not have two devicetrees?' > >> > >> Simon Glass (25): > >> doc: Add documentation about devicetree usage > >> arm: qemu: Mention -nographic in the docs > >> arm: riscv: qemu: Explain how to extract the generated dt > >> arm: qemu: Add a devicetree file for qemu_arm > >> arm: qemu: Add a devicetree file for qemu_arm64 > >> riscv: qemu: Add devicetree files for qemu_riscv32/64 > >> arm: rpi: Add a devicetree file for rpi_4 > >> arm: vexpress: Add a devicetree file for juno > >> arm: xenguest_arm64: Add a fake devicetree file > >> arm: octeontx: Add a fake devicetree file > >> arm: xilinx_versal_virt: Add a devicetree file > >> arm: bcm7xxx: Add a devicetree file > >> arm: qemu-ppce500: Add a devicetree file > >> arm: highbank: Add a fake devicetree file > >> fdt: Make OF_BOARD a bool option > >> Drop CONFIG_BINMAN_STANDALONE_FDT > >> doc: Update info on devicetree update > >> fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() > >> fdt: Drop #ifdefs with MULTI_DTB_FIT > >> fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() > >> fdt: Drop #ifdef around board_fdt_blob_setup() > >> fdt: Use if() for fdtcontroladdr check > >> fdt: Drop OF_CONTROL check in fdtdec_setup() > >> fdt: Drop remaining preprocessor macros in fdtdec_setup() > >> fdt: Don't call board_fdt_blob_setup() without OF_BOARD > >> > >> Makefile | 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 | 2 +- > >> configs/xilinx_versal_virt_defconfig | 1 + > >> doc/board/emulation/qemu-arm.rst | 10 +- > >> doc/board/emulation/qemu-riscv.rst | 3 + > >> doc/develop/devicetree/dt_qemu.rst | 48 + > >> doc/develop/devicetree/dt_update.rst | 497 ++++++ > >> doc/develop/devicetree/index.rst | 2 + > >> dts/Kconfig | 30 +- > >> include/asm-generic/global_data.h | 8 + > >> include/fdtdec.h | 21 +- > >> lib/fdtdec.c | 117 +- > >> tools/binman/binman.rst | 20 - > >> 49 files changed, 5538 insertions(+), 124 deletions(-) > >> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > >> create mode 100644 arch/arm/dts/bcm7xxx.dts > >> create mode 100644 arch/arm/dts/highbank.dts > >> create mode 100644 arch/arm/dts/juno-r2.dts > >> create mode 100644 arch/arm/dts/octeontx.dts > >> create mode 100644 arch/arm/dts/qemu-arm.dts > >> create mode 100644 arch/arm/dts/qemu-arm64.dts > >> create mode 100644 arch/arm/dts/xenguest-arm64.dts > >> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts > >> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts > >> delete mode 100644 arch/riscv/dts/qemu-virt.dts > >> create mode 100644 arch/riscv/dts/qemu-virt32.dts > >> create mode 100644 arch/riscv/dts/qemu-virt64.dts > >> create mode 100644 doc/develop/devicetree/dt_qemu.rst > >> create mode 100644 doc/develop/devicetree/dt_update.rst > >> > >> -- > >> 2.34.0.rc2.393.gf8c9666880-goog > >> > > -- > > François-Frédéric Ozog | Director Business Development > > T: +33.67221.6485 > > francois.ozog@linaro.org | Skype: ffozog > >
On Thu, 2 Dec 2021 19:03:46 +0200 Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: Hi, > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > Hi Simon > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > there are only three ways to obtain a devicetree: > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > appended to U-Boot > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > the ELF file (also used for EFI) > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > don't even provide instructions on how to boot on the board. > > > > > > > > The problems with this approach are documented in another patch in this > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > caller may have a better idea about the hardware available in the machine. > > > > This is the case with a few QEMU boards, for example. > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > This series makes this change, adding various missing devicetree files > > > > (and placeholders) to make the build work. > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > files, some patches in this series can be dropped. > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > [1] > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > Changes in v6: > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > - Expand the commit message based on comments > > > > - Expand the commit message based on comments > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > not in favor of this new version either. > > > If you make a version without « fake DTs » as you name them, there are good > > > advances in the documentation and other areas that would be better in > > > mainline…. > > > If I am the only one thinking this way and the patch can be accepted, I > > > would love there is a warning in capital letters at the top of the DTS fake > > > files that explains the intent of this fake DT, the possible outcomes of > > > not using the one provided by the platform and the right way of dealing > > > with DTs for the platform. > > > > This is the part that I too am still unhappy about. I do not want > > reference or fake or whatever device trees in the U-Boot source tree. > > We should be able to _remove_ the ones we have, that are not required, > > with doc/board/...rst explaining how to get / view one. Not adding > > more. > > So this is a key point for me and the reason I completely disagree > with this approach. This proposal is working in the *exact* opposite > direction and we'll never be able to get rid of device trees from > U-Boot, even if at some point they move out of the kernel to a > 'common' repo'. I'll just repeat what I've been saying since v1. > Personally I'd be way happier if we could figure out were the specific > U-Boot config nodes are needed and when are they needed. Based on > what we figure out we could, pick up the device tree from a previous > state bootloader and fix it up with our special nodes before we start > using it, using internal DTS files (compiled to .dtbos or similar) > that indeed belong in the u-boot tree. I agree on that, I always felt like U-Boot is abusing the DT here for its own purposes. If it needs to convey some configuration information, it should do it separately. It can use the DTB *format* (hierarchically organised key/value pairs), but this should not really be mingled with the hardware information. Trusted-Firmware is using this idea: they use the already included libfdt for parsing, but load the various config "DTB"s separately. The "hw_config" DTB (as they call the actual DTB) is treated separately. Cheers, Andre
On Thu, 2 Dec 2021 11:17:38 -0700 Simon Glass <sjg@chromium.org> wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > Hi Simon > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > > appended to U-Boot > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > > the ELF file (also used for EFI) > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > [1] > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > - Expand the commit message based on comments > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > not in favor of this new version either. > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > mainline…. > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > with DTs for the platform. > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > more. > > > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > > it had not come to this. > > > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > > have a devicetree anywhere I can find. > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > > > whatever caveats and documentation people want to clarify what is > > > > > going on here. I'm happy to look at future options where the > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > > > within U-Boot for development purposes. > > > > > > > > > > I'll also note that the bootstd series shows the devicetree source: > > > > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > > > > > But for now, I still feel this is the best path forward. > > > > > > > > I'm not sure how to proceed here. The reviews are rather strongly > > > > against the "include a device tree that won't be used". The use case of > > > > "but for development someone might need to modify the device tree" is > > > > handled by platforms documenting where / how to get the real one. We > > > > should even update the Kconfig help to note that if you enable this your > > > > board docs MUST explain where the device tree can be seen (or have some > > > > legal reason you think it's OK to not...). > > > > > > Right, we can do lots of things as we have discussed. I am very > > > willing to work on these and make sure it is hard to do the thing. But > > > this series is long enough already. > > > > Yes, I think the rest of us had hoped you would come around to all of > > our reasoning by this point, is why this is taking so long. > > > > Look, if I thought this was all wrong I would not be doing it. We have > a range of opinions: > > - U-Boot should not have its own nodes/properties > - U-Boot should not have DTs in-tree > - U-Boot should have DTs only when essential > - U-Boot should have DTs in-tree for all boards > > What's the downside here anyway? > > > > It is more than just development. A devicetree is needed for binman to > > > work, even if it is empty. The documentation idea doesn't really work, > > > as I think I have proven by the difficulty in getting this series > > > together. An automated mechanism that runs in CI might be acceptable, > > > but that is in the future. For now, I believe it just HAS to be > > > in-tree. > > > > I still don't see any reason why we need these incorrect and not > > functionally used device trees in-tree when a dummy invalid tree is > > enough to make things link. We're dealing with real "we must have X.bin > > in the output for things to function" issues on other platforms with > > binman right now. Using a dummy dts should be fine. > > Incorrect in what way? > > How do I get a real one for development? How do I turn off OF_BOARD > and use the in-tree one? > > The documentation approach is not good enough. > > > > > > > And yes, we're "only" talking about 10 platforms, which include things > > > > like the "everyone" has one Pi family, the extraordinarily flexible (and > > > > so easy for the reference device tree to be very wrong) QEMU families > > > > and then platforms that are including a dts in-tree now because they > > > > were told that was required. > > > > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot? > > > The argument is the same. > > > > Because we don't need it! It serves no purpose! It exists in Linux > > as that's the primary device tree source repository. We could _copy_ it > > in, if it was useful. But then we need to re-sync it every so often, > > and for less clear reasons than all of the platforms that we need to > > sync with the kernel for, AND we use the tree. > > So some people don't need it and it serves no purpose for them. But > why do they care? It is not hurting anyone. This is all overblown. > > > > > There's even an argument to be made that it IS in Linux because when you > > build that dtb, it's what the firmware then ships and uses and provides > > to everyone at run time, possibly along with whatever other > > modifications the binary firmware did (see the assorted threads, > > including one this week about the problems we have because we don't just > > always use the dtb provided to us at run time). > > > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now > > > copied by RISC-V) which doesn't. > > > > Yes, these are more examples of "someone said we need to copy it in, so > > we copy it in". > > No that's not correct. With x86, ppc, integrator, ast2500 and many > others we *need* the DT and *it is not* created by QEMU. Maybe because those are fixed platforms, and/or have ways to autodetect most of their hardware? I feel like U-Boot just has a DT here because it uses it as some kind of configuration file, short of hardcoding the hardware information. I think this is one reason that x86 PCs don't use DTs: there is only *one* fixed base platform (1981 IBM PC, with all its oddities), plus probeable hardware (PCI) for most of the devices. I personally absolutely love that QEMU creates the DT based on its command line parameters: that's the way it should be, and the only way it makes sense to me for this dynamic platform. Having some random QEMU DT in the U-Boot tree sounds wrong, IMHO. Cheers, Andre. > > > > > > > How about adjusting the make logic so that if a tree isn't found, we use > > > > a dummy minimal valid dts file? > > > > > > This is what I have done for the boards where I could not figure out > > > how to get any sort of DT, yes. But I don't think that should be the > > > default. > > > > The more I think about this, the more I think dummy minimal valid dts > > should be the fall-back default. This then solves the "I'm a developer, > > I need to modify the dts files" case because you then just provide the > > dts instead where it should go, and it's used. > > How does it solve it? I don't even know how to get it in many cases. > If it is a dummy then I cannot actually use it for development, right? > > Regards, > Simon
Hi Andre, On Thu, 2 Dec 2021 at 18:31, Andre Przywara <andre.przywara@arm.com> wrote: > > On Thu, 2 Dec 2021 11:17:38 -0700 > Simon Glass <sjg@chromium.org> wrote: > > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > > > appended to U-Boot > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > > more. > > > > > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > > > it had not come to this. > > > > > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > > > have a devicetree anywhere I can find. > > > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > > > > whatever caveats and documentation people want to clarify what is > > > > > > going on here. I'm happy to look at future options where the > > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > > > > within U-Boot for development purposes. > > > > > > > > > > > > I'll also note that the bootstd series shows the devicetree source: > > > > > > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > > > > > > > But for now, I still feel this is the best path forward. > > > > > > > > > > I'm not sure how to proceed here. The reviews are rather strongly > > > > > against the "include a device tree that won't be used". The use case of > > > > > "but for development someone might need to modify the device tree" is > > > > > handled by platforms documenting where / how to get the real one. We > > > > > should even update the Kconfig help to note that if you enable this your > > > > > board docs MUST explain where the device tree can be seen (or have some > > > > > legal reason you think it's OK to not...). > > > > > > > > Right, we can do lots of things as we have discussed. I am very > > > > willing to work on these and make sure it is hard to do the thing. But > > > > this series is long enough already. > > > > > > Yes, I think the rest of us had hoped you would come around to all of > > > our reasoning by this point, is why this is taking so long. > > > > > > > Look, if I thought this was all wrong I would not be doing it. We have > > a range of opinions: > > > > - U-Boot should not have its own nodes/properties > > - U-Boot should not have DTs in-tree > > - U-Boot should have DTs only when essential > > - U-Boot should have DTs in-tree for all boards > > > > What's the downside here anyway? > > > > > > It is more than just development. A devicetree is needed for binman to > > > > work, even if it is empty. The documentation idea doesn't really work, > > > > as I think I have proven by the difficulty in getting this series > > > > together. An automated mechanism that runs in CI might be acceptable, > > > > but that is in the future. For now, I believe it just HAS to be > > > > in-tree. > > > > > > I still don't see any reason why we need these incorrect and not > > > functionally used device trees in-tree when a dummy invalid tree is > > > enough to make things link. We're dealing with real "we must have X.bin > > > in the output for things to function" issues on other platforms with > > > binman right now. Using a dummy dts should be fine. > > > > Incorrect in what way? > > > > How do I get a real one for development? How do I turn off OF_BOARD > > and use the in-tree one? > > > > The documentation approach is not good enough. > > > > > > > > > > And yes, we're "only" talking about 10 platforms, which include things > > > > > like the "everyone" has one Pi family, the extraordinarily flexible (and > > > > > so easy for the reference device tree to be very wrong) QEMU families > > > > > and then platforms that are including a dts in-tree now because they > > > > > were told that was required. > > > > > > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is > > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot? > > > > The argument is the same. > > > > > > Because we don't need it! It serves no purpose! It exists in Linux > > > as that's the primary device tree source repository. We could _copy_ it > > > in, if it was useful. But then we need to re-sync it every so often, > > > and for less clear reasons than all of the platforms that we need to > > > sync with the kernel for, AND we use the tree. > > > > So some people don't need it and it serves no purpose for them. But > > why do they care? It is not hurting anyone. This is all overblown. > > > > > > > > There's even an argument to be made that it IS in Linux because when you > > > build that dtb, it's what the firmware then ships and uses and provides > > > to everyone at run time, possibly along with whatever other > > > modifications the binary firmware did (see the assorted threads, > > > including one this week about the problems we have because we don't just > > > always use the dtb provided to us at run time). > > > > > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now > > > > copied by RISC-V) which doesn't. > > > > > > Yes, these are more examples of "someone said we need to copy it in, so > > > we copy it in". > > > > No that's not correct. With x86, ppc, integrator, ast2500 and many > > others we *need* the DT and *it is not* created by QEMU. > > Maybe because those are fixed platforms, and/or have ways to autodetect > most of their hardware? I feel like U-Boot just has a DT here because > it uses it as some kind of configuration file, short of hardcoding the > hardware information. > I think this is one reason that x86 PCs don't use DTs: there is only > *one* fixed base platform (1981 IBM PC, with all its oddities), plus > probeable hardware (PCI) for most of the devices. > > I personally absolutely love that QEMU creates the DT based on its > command line parameters: that's the way it should be, and the only way > it makes sense to me for this dynamic platform. Having some random QEMU > DT in the U-Boot tree sounds wrong, IMHO. The QEMU arm virt maintainer seems less enthusiastic, but I agree it is a useful idea. One might argue that it should work by enabling nodes rather than making them out of whole cloth, or provide a way to add/delete things, but at least it works in the common case. But when you want to develop a new feature, where QEMU doesn't have a node you need, or want to run qemu with SPL, what do you do? Just give up? Go and hack QEMU? Anyway, no one is making you to use the U-Boot devicetree, so don't worry about it. Regards, Simon
On Thu, 2 Dec 2021 13:34:07 -0500 Tom Rini <trini@konsulko.com> wrote: Hi, > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > > > appended to U-Boot > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > > more. > > > > > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > > > it had not come to this. > > > > > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > > > have a devicetree anywhere I can find. > > > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > > > > whatever caveats and documentation people want to clarify what is > > > > > > going on here. I'm happy to look at future options where the > > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > > > > within U-Boot for development purposes. > > > > > > > > > > > > I'll also note that the bootstd series shows the devicetree source: > > > > > > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > > > > > > > But for now, I still feel this is the best path forward. > > > > > > > > > > I'm not sure how to proceed here. The reviews are rather strongly > > > > > against the "include a device tree that won't be used". The use case of > > > > > "but for development someone might need to modify the device tree" is > > > > > handled by platforms documenting where / how to get the real one. We > > > > > should even update the Kconfig help to note that if you enable this your > > > > > board docs MUST explain where the device tree can be seen (or have some > > > > > legal reason you think it's OK to not...). > > > > > > > > Right, we can do lots of things as we have discussed. I am very > > > > willing to work on these and make sure it is hard to do the thing. But > > > > this series is long enough already. > > > > > > Yes, I think the rest of us had hoped you would come around to all of > > > our reasoning by this point, is why this is taking so long. > > > > > > > Look, if I thought this was all wrong I would not be doing it. We have > > a range of opinions: > > And the rest of us wouldn't keep trying to argue otherwise if we didn't > see problems with it, still. > > > - U-Boot should not have its own nodes/properties > > The caveat there is that aren't documented upstream bindings. I think > at this point the lack of screaming and otherwise "wait, no no no > don't!" that your current patch has gotten means it's time for a pull > request, and for that to go in, and so this line of argument would be > simply removed. > > > - U-Boot should not have DTs in-tree > > ... for the cases where the DTs are not used at run time, yes. > > > - U-Boot should have DTs only when essential > > I don't understand this point. Can you please elaborate? > > > - U-Boot should have DTs in-tree for all boards > > This is the line you're pushing and almost every other reviewer > disagrees with. > > > What's the downside here anyway? > > - A lack of clarity. We have dts files, you modify those dts files, > they aren't used. What's the point? Oh, you forgot to tweak > something else. Wait, now nothing works. Oh, it's a mismatch between > what this dts was at one point, and what it needs to be now to > actually work. > - We're adding more ongoing sync-up work. While I loudly applaud the > custodians that are keeping their dts files in sync very regularly, > and I sympathize with the custodians that want to do it more, but are > unable to find the time, I do not want to add more of this work. Even > more so when it's unclear who would be doing it. Or what the use is. > > There's probably more if I think about it harder, but those are the > first to spring to mind. > > > > > It is more than just development. A devicetree is needed for binman to > > > > work, even if it is empty. The documentation idea doesn't really work, > > > > as I think I have proven by the difficulty in getting this series > > > > together. An automated mechanism that runs in CI might be acceptable, > > > > but that is in the future. For now, I believe it just HAS to be > > > > in-tree. > > > > > > I still don't see any reason why we need these incorrect and not > > > functionally used device trees in-tree when a dummy invalid tree is > > > enough to make things link. We're dealing with real "we must have X.bin > > > in the output for things to function" issues on other platforms with > > > binman right now. Using a dummy dts should be fine. > > > > Incorrect in what way? > > Well, in the QEMU instance, they're only as correct as the parameters > passed to qemu-system-foo when you did -dumpdtb to start with. Lets > take TPM as that now should show up in the device tree, or not, > depending on if we have the backend side of it? Or all of the examples > of how to arbitrarily configure a system as Heinrich noted. > > Or the Pi examples where we need to use the device tree passed to us > because config.txt is the official way to modify things in the device > tree on that platform. I feel like a lot of the confusion stems from the very different roles that U-Boot plays on various platforms: - In the traditional way U-Boot is the first and only piece of code that runs between reset and the kernel. Having the DT as part of the U-Boot image, and thus in the U-Boot source tree, makes sense, given that we talk about a particular board only. - Many platforms run other pieces of software (TF-A, SCP firmware) alongside or before U-Boot, but still U-Boot is the main attraction, and is doing firmware and setup duties. Most cheap ARM SoCs (sunxi, RK) fall under this category. Depending on the particular firmware setup, having the DTs in the tree (as a copy of the canonical Linux source) again makes sense, and the DTB should probably be part of the built U-Boot image as well, unless there is some better place. But there is a quite different category of boards, where U-Boot is a mere *loader*, and UEFI provider. The heavy lifting of platform setup (clocks, DRAM, power) is either done by prior firmware code, or by a separate management processor. The RPis, ARM Juno boards, Highbank and many other (typically advanced) platforms fall under this category. U-Boot should be happy about the lesser burden, and just consume whatever DTB it finds in memory. Virtual/dynamic platforms like QEMU or the ARM FVP models also fall into this category: for a virtual platform hardware setup is mostly not needed (DRAM, clock gating), or the emulator takes care of this already. For all those platforms the DTB naturally lives with the other firmware bits already, or is even amended by them, and U-Boot should not try to duplicate this, especially when the hardware is somewhat dynamic. Cheers, Andre > > How do I get a real one for development? How do I turn off OF_BOARD > > and use the in-tree one? > > How do you turn off the run-time device tree and instead use the in-tree > one for development, with your series? > > > The documentation approach is not good enough. > > Why? But maybe I can better explain things in Mark's part of the thread > about power domains and serial on M1.. > > > > > > And yes, we're "only" talking about 10 platforms, which include things > > > > > like the "everyone" has one Pi family, the extraordinarily flexible (and > > > > > so easy for the reference device tree to be very wrong) QEMU families > > > > > and then platforms that are including a dts in-tree now because they > > > > > were told that was required. > > > > > > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is > > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot? > > > > The argument is the same. > > > > > > Because we don't need it! It serves no purpose! It exists in Linux > > > as that's the primary device tree source repository. We could _copy_ it > > > in, if it was useful. But then we need to re-sync it every so often, > > > and for less clear reasons than all of the platforms that we need to > > > sync with the kernel for, AND we use the tree. > > > > So some people don't need it and it serves no purpose for them. But > > why do they care? It is not hurting anyone. This is all overblown. > > Because it's adding ongoing maintenance work, and reducing clarity of > the codebase, to summarize my concerns above. > > > > There's even an argument to be made that it IS in Linux because when you > > > build that dtb, it's what the firmware then ships and uses and provides > > > to everyone at run time, possibly along with whatever other > > > modifications the binary firmware did (see the assorted threads, > > > including one this week about the problems we have because we don't just > > > always use the dtb provided to us at run time). > > > > > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now > > > > copied by RISC-V) which doesn't. > > > > > > Yes, these are more examples of "someone said we need to copy it in, so > > > we copy it in". > > > > No that's not correct. With x86, ppc, integrator, ast2500 and many > > others we *need* the DT and *it is not* created by QEMU. > > You're listing both QEMU virtual machines and QEMU-as-hardware-emulators > above, which confuses things. The integrator code runs on real > hardware. Real hardware which does not have the device tree on it. I > assume that QEMU + Linux - U-Boot for integrator requires you to pass > the .dtb in, just like real the real hardware does. That's true of all > of the cases I believe where we use QEMU-as-hardware-emulator because > QEMU is also authentic to the hardware. > > > > > > How about adjusting the make logic so that if a tree isn't found, we use > > > > > a dummy minimal valid dts file? > > > > > > > > This is what I have done for the boards where I could not figure out > > > > how to get any sort of DT, yes. But I don't think that should be the > > > > default. > > > > > > The more I think about this, the more I think dummy minimal valid dts > > > should be the fall-back default. This then solves the "I'm a developer, > > > I need to modify the dts files" case because you then just provide the > > > dts instead where it should go, and it's used. > > > > How does it solve it? I don't even know how to get it in many cases. > > If it is a dummy then I cannot actually use it for development, right? > > It solves the problem of "we must have this dts file so that the build > will not fail". The next step of "oh, we actually want to use it, and > not the run-time provided dtb" would be the same as whatever you're > doing with this series. >
Hi Andre, On Thu, 2 Dec 2021 at 18:59, Andre Przywara <andre.przywara@arm.com> wrote: > > On Thu, 2 Dec 2021 13:34:07 -0500 > Tom Rini <trini@konsulko.com> wrote: > > Hi, > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > > > > appended to U-Boot > > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > > > not in favor of this new version either. > > > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > > > mainline…. > > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > > > more. > > > > > > > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > > > > it had not come to this. > > > > > > > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > > > > have a devicetree anywhere I can find. > > > > > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > > > > > whatever caveats and documentation people want to clarify what is > > > > > > > going on here. I'm happy to look at future options where the > > > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > > > > > within U-Boot for development purposes. > > > > > > > > > > > > > > I'll also note that the bootstd series shows the devicetree source: > > > > > > > > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > > > > > > > > > But for now, I still feel this is the best path forward. > > > > > > > > > > > > I'm not sure how to proceed here. The reviews are rather strongly > > > > > > against the "include a device tree that won't be used". The use case of > > > > > > "but for development someone might need to modify the device tree" is > > > > > > handled by platforms documenting where / how to get the real one. We > > > > > > should even update the Kconfig help to note that if you enable this your > > > > > > board docs MUST explain where the device tree can be seen (or have some > > > > > > legal reason you think it's OK to not...). > > > > > > > > > > Right, we can do lots of things as we have discussed. I am very > > > > > willing to work on these and make sure it is hard to do the thing. But > > > > > this series is long enough already. > > > > > > > > Yes, I think the rest of us had hoped you would come around to all of > > > > our reasoning by this point, is why this is taking so long. > > > > > > > > > > Look, if I thought this was all wrong I would not be doing it. We have > > > a range of opinions: > > > > And the rest of us wouldn't keep trying to argue otherwise if we didn't > > see problems with it, still. > > > > > - U-Boot should not have its own nodes/properties > > > > The caveat there is that aren't documented upstream bindings. I think > > at this point the lack of screaming and otherwise "wait, no no no > > don't!" that your current patch has gotten means it's time for a pull > > request, and for that to go in, and so this line of argument would be > > simply removed. > > > > > - U-Boot should not have DTs in-tree > > > > ... for the cases where the DTs are not used at run time, yes. > > > > > - U-Boot should have DTs only when essential > > > > I don't understand this point. Can you please elaborate? > > > > > - U-Boot should have DTs in-tree for all boards > > > > This is the line you're pushing and almost every other reviewer > > disagrees with. > > > > > What's the downside here anyway? > > > > - A lack of clarity. We have dts files, you modify those dts files, > > they aren't used. What's the point? Oh, you forgot to tweak > > something else. Wait, now nothing works. Oh, it's a mismatch between > > what this dts was at one point, and what it needs to be now to > > actually work. > > - We're adding more ongoing sync-up work. While I loudly applaud the > > custodians that are keeping their dts files in sync very regularly, > > and I sympathize with the custodians that want to do it more, but are > > unable to find the time, I do not want to add more of this work. Even > > more so when it's unclear who would be doing it. Or what the use is. > > > > There's probably more if I think about it harder, but those are the > > first to spring to mind. > > > > > > > It is more than just development. A devicetree is needed for binman to > > > > > work, even if it is empty. The documentation idea doesn't really work, > > > > > as I think I have proven by the difficulty in getting this series > > > > > together. An automated mechanism that runs in CI might be acceptable, > > > > > but that is in the future. For now, I believe it just HAS to be > > > > > in-tree. > > > > > > > > I still don't see any reason why we need these incorrect and not > > > > functionally used device trees in-tree when a dummy invalid tree is > > > > enough to make things link. We're dealing with real "we must have X.bin > > > > in the output for things to function" issues on other platforms with > > > > binman right now. Using a dummy dts should be fine. > > > > > > Incorrect in what way? > > > > Well, in the QEMU instance, they're only as correct as the parameters > > passed to qemu-system-foo when you did -dumpdtb to start with. Lets > > take TPM as that now should show up in the device tree, or not, > > depending on if we have the backend side of it? Or all of the examples > > of how to arbitrarily configure a system as Heinrich noted. > > > > Or the Pi examples where we need to use the device tree passed to us > > because config.txt is the official way to modify things in the device > > tree on that platform. > > I feel like a lot of the confusion stems from the very different > roles that U-Boot plays on various platforms: > - In the traditional way U-Boot is the first and only piece of code > that runs between reset and the kernel. Having the DT as part of the > U-Boot image, and thus in the U-Boot source tree, makes sense, given > that we talk about a particular board only. > - Many platforms run other pieces of software (TF-A, SCP firmware) > alongside or before U-Boot, but still U-Boot is the main attraction, > and is doing firmware and setup duties. Most cheap ARM SoCs (sunxi, > RK) fall under this category. Depending on the particular firmware > setup, having the DTs in the tree (as a copy of the canonical Linux > source) again makes sense, and the DTB should probably be part of the > built U-Boot image as well, unless there is some better place. > > But there is a quite different category of boards, where U-Boot is a > mere *loader*, and UEFI provider. The heavy lifting of platform setup > (clocks, DRAM, power) is either done by prior firmware code, or by a > separate management processor. The RPis, ARM Juno boards, Highbank and > many other (typically advanced) platforms fall under this category. > U-Boot should be happy about the lesser burden, and just consume > whatever DTB it finds in memory. > Virtual/dynamic platforms like QEMU or the ARM FVP models also fall > into this category: for a virtual platform hardware setup is mostly not > needed (DRAM, clock gating), or the emulator takes care of this already. > > For all those platforms the DTB naturally lives with the other firmware > bits already, or is even amended by them, and U-Boot should not try to > duplicate this, especially when the hardware is somewhat dynamic. Yes that is all understood and have been bashed to death in various threads. Still, it is not unreasonable, I think, for U-Boot to have a way to use an in-tree devicetree for development and testing purposes. It also reasonable, I think, to require some in-tree documentation about how to get U-Boot running on the board. BTW I hope these other pieces of software are open-source! Regards, Simon > > Cheers, > Andre > > > > How do I get a real one for development? How do I turn off OF_BOARD > > > and use the in-tree one? > > > > How do you turn off the run-time device tree and instead use the in-tree > > one for development, with your series? > > > > > The documentation approach is not good enough. > > > > Why? But maybe I can better explain things in Mark's part of the thread > > about power domains and serial on M1.. > > > > > > > > And yes, we're "only" talking about 10 platforms, which include things > > > > > > like the "everyone" has one Pi family, the extraordinarily flexible (and > > > > > > so easy for the reference device tree to be very wrong) QEMU families > > > > > > and then platforms that are including a dts in-tree now because they > > > > > > were told that was required. > > > > > > > > > > Actually it is only rpi4 that doesn't have an in-tree DT. There is > > > > > actually no reason for it not to, e.g. Linux has it. Why not U-Boot? > > > > > The argument is the same. > > > > > > > > Because we don't need it! It serves no purpose! It exists in Linux > > > > as that's the primary device tree source repository. We could _copy_ it > > > > in, if it was useful. But then we need to re-sync it every so often, > > > > and for less clear reasons than all of the platforms that we need to > > > > sync with the kernel for, AND we use the tree. > > > > > > So some people don't need it and it serves no purpose for them. But > > > why do they care? It is not hurting anyone. This is all overblown. > > > > Because it's adding ongoing maintenance work, and reducing clarity of > > the codebase, to summarize my concerns above. > > > > > > There's even an argument to be made that it IS in Linux because when you > > > > build that dtb, it's what the firmware then ships and uses and provides > > > > to everyone at run time, possibly along with whatever other > > > > modifications the binary firmware did (see the assorted threads, > > > > including one this week about the problems we have because we don't just > > > > always use the dtb provided to us at run time). > > > > > > > > > Most QEMU boards have an in-tree devicetree. It is only ARM (now > > > > > copied by RISC-V) which doesn't. > > > > > > > > Yes, these are more examples of "someone said we need to copy it in, so > > > > we copy it in". > > > > > > No that's not correct. With x86, ppc, integrator, ast2500 and many > > > others we *need* the DT and *it is not* created by QEMU. > > > > You're listing both QEMU virtual machines and QEMU-as-hardware-emulators > > above, which confuses things. The integrator code runs on real > > hardware. Real hardware which does not have the device tree on it. I > > assume that QEMU + Linux - U-Boot for integrator requires you to pass > > the .dtb in, just like real the real hardware does. That's true of all > > of the cases I believe where we use QEMU-as-hardware-emulator because > > QEMU is also authentic to the hardware. > > > > > > > > How about adjusting the make logic so that if a tree isn't found, we use > > > > > > a dummy minimal valid dts file? > > > > > > > > > > This is what I have done for the boards where I could not figure out > > > > > how to get any sort of DT, yes. But I don't think that should be the > > > > > default. > > > > > > > > The more I think about this, the more I think dummy minimal valid dts > > > > should be the fall-back default. This then solves the "I'm a developer, > > > > I need to modify the dts files" case because you then just provide the > > > > dts instead where it should go, and it's used. > > > > > > How does it solve it? I don't even know how to get it in many cases. > > > If it is a dummy then I cannot actually use it for development, right? > > > > It solves the problem of "we must have this dts file so that the build > > will not fail". The next step of "oh, we actually want to use it, and > > not the run-time provided dtb" would be the same as whatever you're > > doing with this series. > > >
Hi Mark, > > > > > [...] > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there are good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > not using the one provided by the platform and the right way of dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... Last time we said we don't really have to remove them, but I get the point. > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm adding support for power domains and the serial port > requires certain power domains to be on. Since the serial port is > initialized in the pre-relocation phase this means that the device > tree nodes for the power domain controllers need to have the > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > be able to bind the power domain controller driver in this phase and > binding the serial port driver itself will fail. Which makes U-Boot > hang without any visible output on the serial console. Very relevant indeed. That's close to what I was afraid of when I said "if we could figure out were the specific U-Boot config nodes are needed and *when* are they needed". Obviously this is a clear no go, since more boards will have similar requirements in the future. > > Within the Asahi Linux group we're currently discussing how to solve > this. We could just add the "u-boot,dm-pre-reloc" properties in the > device trees that we're going to distribute as part of m1n1 (the > "bootloader" than embeds U-Boot). Or we can write some code that adds > those properties to the device tree nodes that are dependencies for > the serial port. That might make sense for a project like m1n1 were you are dealing with a handful of devices, but I think it's going to be a pain on a larger scale, unless of course the bindings are documented in upstream. In that case we could ask previous bootloaders to add them etc. > > I don't think the suggestion of applying an overlay embedded in U-Boot > would work here. The code applying the overlay would need to run very > early on in the pre-relocation phase. Yep it wouldn't > We'd also have to include > overlays for all the models that Apple offers and pick the right one. > And if a new model appears we can no longer just add a new device tree > to m1n1. > > But maybe there is a case where the overlay approach would make sense... I think there is, for example I was thinking of TF-A doing all the hardware init and then handover a DTB into u-boot on a register. In that case U-boot could fixup the DTB before initialing the rest of the subsystems and make DM happy. However as you pointed out that's not the case for all boards and dealing with this in the early pre-relocation stage is close to impossible, so let's drop that. Thanks! /Ilias
Hi Simon, > > > > > [...] > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there are good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > not using the one provided by the platform and the right way of dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > Eh? If the device tree files are actually common then there should be > a single source. If U-Boot has a copy then it should be identical. > > The special node thing makes no sense for U-Boot. We just need to > upstream our bindings and I am working on that. Yea we discussed this on v5. If the device bindings are upstreamed things gets substantially easier. But that's a big if. > > Are the device tree files moving out of Linux? There was an effort from Linaro and iirc we tried to move a few and see how things would work out, but there's nothing official. Regards /Ilias
On 12/2/21 17:50, Simon Glass wrote: > Hi Heinrich, > > On Thu, 2 Dec 2021 at 09:47, Heinrich Schuchardt > <heinrich.schuchardt@canonical.com> wrote: >> >> On 12/2/21 16:58, 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 in another patch in this >>> series: "doc: Add documentation about devicetree usage" >>> >>> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board >>> can obtain its devicetree at runtime, even it is has a devicetree built >>> in U-Boot. This is because U-Boot may be a second-stage bootloader and its >>> caller may have a better idea about the hardware available in the machine. >>> This is the case with a few QEMU boards, for example. >>> >>> So it makes no sense to have OF_BOARD as a 'choice'. It should be an >>> option, available with either OF_SEPARATE or OF_EMBED. >>> >>> This series makes this change, adding various missing devicetree files >>> (and placeholders) to make the build work. >>> >>> Note: If board maintainers are able to add their own patch to add the >>> files, some patches in this series can be dropped. >>> >>> It also provides a few qemu clean-ups discovered along the way. The >>> qemu-riscv64_spl problem is fixed. >> >> Distros like Ubuntu are provided as preinstalled images using U-Boot to >> launch Linux for usage with QEMU. A single image must be able to be >> usable in the future irrespective of the QEMU command line device >> configuration. >> >> This means that the devicetree coming from QEMU must be accurately >> parsed in U-Boot to setup the UEFI memory map. The number and type of >> CPUs and the NUMA configuration must be accurate. All devices enabled >> via the QEMU command line must be visible in the device-tree of Linux. >> >> Please, observe that information like number of CPU cores, number and >> type of block devices, namespace IDs used for NVMe drives, etc. cannot >> be available at build time. >> >> It this all guaranteed with this series? If not, this would >> unfortunately imply a NAK. > > Yes, it is guaranteed and there is no change there. Compiling qemu_arm64_defconfig yields dtbdump.efi. I used this to dump the devicetree exposed to UEFI binaries. The number of CPUs and the memory size matches the call parameters of QEMU. Emulated devices like SCSI and NVMe drives and TPMv2 work inside U-Boot. I also tested: * qemu-riscv64_smode_defconfig as fw_jump payload for OpenSBI * qemu-riscv64_spl_defconfig and found no issues. Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canaonical.com>
> Date: Fri, 3 Dec 2021 09:50:44 +0200 > From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > Hi Mark, > > > > > > > > > [...] > > > > > > > Changes in v6: > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > - Expand the commit message based on comments > > > > > > - Expand the commit message based on comments > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > not in favor of this new version either. > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > advances in the documentation and other areas that would be better in > > > > > mainline…. > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > not using the one provided by the platform and the right way of dealing > > > > > with DTs for the platform. > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > We should be able to _remove_ the ones we have, that are not required, > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > more. > > > > > > So this is a key point for me and the reason I completely disagree > > > with this approach. This proposal is working in the *exact* opposite > > > direction and we'll never be able to get rid of device trees from > > > U-Boot, even if at some point they move out of the kernel to a > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > Personally I'd be way happier if we could figure out were the specific > > > U-Boot config nodes are needed and when are they needed. Based on > > > what we figure out we could, pick up the device tree from a previous > > > state bootloader and fix it up with our special nodes before we start > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > that indeed belong in the u-boot tree. > > > > I don't think it makes sense to put stuff in the DT that is specific > > for U-Boot only to pull it out moments later. Maybe it does make some > > sense to do this to pass information between TPL/SPL and U-Boot > > proper. But otherwise you can just use global variables... > > Last time we said we don't really have to remove them, but I get the > point. Ah, when I said "pull it out" I meant "read it back"; not "delete it". > > Now I just ran into an issue on Apple M1 that may have some relevance > > here. I'm adding support for power domains and the serial port > > requires certain power domains to be on. Since the serial port is > > initialized in the pre-relocation phase this means that the device > > tree nodes for the power domain controllers need to have the > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > > be able to bind the power domain controller driver in this phase and > > binding the serial port driver itself will fail. Which makes U-Boot > > hang without any visible output on the serial console. > > Very relevant indeed. That's close to what I was afraid of when I said > "if we could figure out were the specific U-Boot config nodes are needed > and *when* are they needed". Obviously this is a clear no go, since more > boards will have similar requirements in the future. > > > > > Within the Asahi Linux group we're currently discussing how to solve > > this. We could just add the "u-boot,dm-pre-reloc" properties in the > > device trees that we're going to distribute as part of m1n1 (the > > "bootloader" than embeds U-Boot). Or we can write some code that adds > > those properties to the device tree nodes that are dependencies for > > the serial port. > > That might make sense for a project like m1n1 were you are dealing with a > handful of devices, but I think it's going to be a pain on a larger scale, > unless of course the bindings are documented in upstream. In that case we > could ask previous bootloaders to add them etc. > > > > > I don't think the suggestion of applying an overlay embedded in U-Boot > > would work here. The code applying the overlay would need to run very > > early on in the pre-relocation phase. > > Yep it wouldn't > > > We'd also have to include > > overlays for all the models that Apple offers and pick the right one. > > And if a new model appears we can no longer just add a new device tree > > to m1n1. > > > > But maybe there is a case where the overlay approach would make sense... > > I think there is, for example I was thinking of TF-A doing all the hardware init > and then handover a DTB into u-boot on a register. In that case U-boot > could fixup the DTB before initialing the rest of the subsystems and make DM > happy. However as you pointed out that's not the case for all boards and > dealing with this in the early pre-relocation stage is close to > impossible, so let's drop that. > > > Thanks! > /Ilias >
On 12/3/21 11:27, Mark Kettenis wrote: >> Date: Fri, 3 Dec 2021 09:50:44 +0200 >> From: Ilias Apalodimas <ilias.apalodimas@linaro.org> >> >> Hi Mark, >> >>>>>>> >> >> [...] >> >>>>>>> Changes in v6: >>>>>>> - Fix description of OF_BOARD so it refers just to the current state >>>>>>> - Explain that the 'two devicetrees' refers to two *control* devicetrees >>>>>>> - Expand the commit message based on comments >>>>>>> - Expand the commit message based on comments >>>>>> >>>>>> You haven’t addressed any concerns expressed on the mailing list.so I am >>>>>> not in favor of this new version either. >>>>>> If you make a version without « fake DTs » as you name them, there are good >>>>>> advances in the documentation and other areas that would be better in >>>>>> mainline…. >>>>>> If I am the only one thinking this way and the patch can be accepted, I >>>>>> would love there is a warning in capital letters at the top of the DTS fake >>>>>> files that explains the intent of this fake DT, the possible outcomes of >>>>>> not using the one provided by the platform and the right way of dealing >>>>>> with DTs for the platform. >>>>> >>>>> This is the part that I too am still unhappy about. I do not want >>>>> reference or fake or whatever device trees in the U-Boot source tree. >>>>> We should be able to _remove_ the ones we have, that are not required, >>>>> with doc/board/...rst explaining how to get / view one. Not adding >>>>> more. >>>> >>>> So this is a key point for me and the reason I completely disagree >>>> with this approach. This proposal is working in the *exact* opposite >>>> direction and we'll never be able to get rid of device trees from >>>> U-Boot, even if at some point they move out of the kernel to a >>>> 'common' repo'. I'll just repeat what I've been saying since v1. >>>> Personally I'd be way happier if we could figure out were the specific >>>> U-Boot config nodes are needed and when are they needed. Based on >>>> what we figure out we could, pick up the device tree from a previous >>>> state bootloader and fix it up with our special nodes before we start >>>> using it, using internal DTS files (compiled to .dtbos or similar) >>>> that indeed belong in the u-boot tree. Applying a devicetree overlay can be implemented in common/board_f.c before the first usage of the devicetree to initialize devices (there are some that are initialized before relocation). >>> >>> I don't think it makes sense to put stuff in the DT that is specific >>> for U-Boot only to pull it out moments later. Maybe it does make some >>> sense to do this to pass information between TPL/SPL and U-Boot >>> proper. But otherwise you can just use global variables... Linux will silently ignore any node for which it does not have a compatible string. So application of an overlay once in U-Boot is sufficient. Best regards Heinrich >> >> Last time we said we don't really have to remove them, but I get the >> point. > > Ah, when I said "pull it out" I meant "read it back"; not "delete it". > >>> Now I just ran into an issue on Apple M1 that may have some relevance >>> here. I'm adding support for power domains and the serial port >>> requires certain power domains to be on. Since the serial port is >>> initialized in the pre-relocation phase this means that the device >>> tree nodes for the power domain controllers need to have the >>> "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't >>> be able to bind the power domain controller driver in this phase and >>> binding the serial port driver itself will fail. Which makes U-Boot >>> hang without any visible output on the serial console. >> >> Very relevant indeed. That's close to what I was afraid of when I said >> "if we could figure out were the specific U-Boot config nodes are needed >> and *when* are they needed". Obviously this is a clear no go, since more >> boards will have similar requirements in the future. >> >>> >>> Within the Asahi Linux group we're currently discussing how to solve >>> this. We could just add the "u-boot,dm-pre-reloc" properties in the >>> device trees that we're going to distribute as part of m1n1 (the >>> "bootloader" than embeds U-Boot). Or we can write some code that adds >>> those properties to the device tree nodes that are dependencies for >>> the serial port. >> >> That might make sense for a project like m1n1 were you are dealing with a >> handful of devices, but I think it's going to be a pain on a larger scale, >> unless of course the bindings are documented in upstream. In that case we >> could ask previous bootloaders to add them etc. >> >>> >>> I don't think the suggestion of applying an overlay embedded in U-Boot >>> would work here. The code applying the overlay would need to run very >>> early on in the pre-relocation phase. >> >> Yep it wouldn't >> >>> We'd also have to include >>> overlays for all the models that Apple offers and pick the right one. >>> And if a new model appears we can no longer just add a new device tree >>> to m1n1. >>> >>> But maybe there is a case where the overlay approach would make sense... >> >> I think there is, for example I was thinking of TF-A doing all the hardware init >> and then handover a DTB into u-boot on a register. In that case U-boot >> could fixup the DTB before initialing the rest of the subsystems and make DM >> happy. However as you pointed out that's not the case for all boards and >> dealing with this in the early pre-relocation stage is close to >> impossible, so let's drop that. >> >> >> Thanks! >> /Ilias >>
Hi Heinrich, On Fri, Dec 03, 2021 at 02:59:44PM +0100, Heinrich Schuchardt wrote: > On 12/3/21 11:27, Mark Kettenis wrote: > > > Date: Fri, 3 Dec 2021 09:50:44 +0200 > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > > > > > Hi Mark, > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > Changes in v6: > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > - Expand the commit message based on comments > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > not in favor of this new version either. > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > mainline…. > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > with DTs for the platform. > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > more. > > > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > > with this approach. This proposal is working in the *exact* opposite > > > > > direction and we'll never be able to get rid of device trees from > > > > > U-Boot, even if at some point they move out of the kernel to a > > > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > > > Personally I'd be way happier if we could figure out were the specific > > > > > U-Boot config nodes are needed and when are they needed. Based on > > > > > what we figure out we could, pick up the device tree from a previous > > > > > state bootloader and fix it up with our special nodes before we start > > > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > > > that indeed belong in the u-boot tree. > > Applying a devicetree overlay can be implemented in common/board_f.c > before the first usage of the devicetree to initialize devices (there > are some that are initialized before relocation). Thanks for digging this up. Tbh I misunderstood the original mail from Mark. When I read pre-reloc I assumed no C environment was up yet. However this raises a few questions. 1. The .dtbos will need to be embedded in the u-boot binary since there's no FS access (or in some cases storage access to begin with) 2. The RAM we have is going to be limited if we want to apply the overlays before consoles etc are up, since it basically has to happen at some point near 'fdtdec_setup' 3.Are we are going to need some logic on how to apply the .dtbos? E.g think of the same hardware with different configuration. You'll be able to use the same binary, if you can somehow configure which overlays you want to apply. Thanks /Ilias > > > > > > > > > I don't think it makes sense to put stuff in the DT that is specific > > > > for U-Boot only to pull it out moments later. Maybe it does make some > > > > sense to do this to pass information between TPL/SPL and U-Boot > > > > proper. But otherwise you can just use global variables... > > Linux will silently ignore any node for which it does not have a > compatible string. So application of an overlay once in U-Boot is > sufficient. > > Best regards > > Heinrich > > > > > > > Last time we said we don't really have to remove them, but I get the > > > point. > > > > Ah, when I said "pull it out" I meant "read it back"; not "delete it". > > > > > > Now I just ran into an issue on Apple M1 that may have some relevance > > > > here. I'm adding support for power domains and the serial port > > > > requires certain power domains to be on. Since the serial port is > > > > initialized in the pre-relocation phase this means that the device > > > > tree nodes for the power domain controllers need to have the > > > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > > > > be able to bind the power domain controller driver in this phase and > > > > binding the serial port driver itself will fail. Which makes U-Boot > > > > hang without any visible output on the serial console. > > > > > > Very relevant indeed. That's close to what I was afraid of when I said > > > "if we could figure out were the specific U-Boot config nodes are needed > > > and *when* are they needed". Obviously this is a clear no go, since more > > > boards will have similar requirements in the future. > > > > > > > > > > > Within the Asahi Linux group we're currently discussing how to solve > > > > this. We could just add the "u-boot,dm-pre-reloc" properties in the > > > > device trees that we're going to distribute as part of m1n1 (the > > > > "bootloader" than embeds U-Boot). Or we can write some code that adds > > > > those properties to the device tree nodes that are dependencies for > > > > the serial port. > > > > > > That might make sense for a project like m1n1 were you are dealing with a > > > handful of devices, but I think it's going to be a pain on a larger scale, > > > unless of course the bindings are documented in upstream. In that case we > > > could ask previous bootloaders to add them etc. > > > > > > > > > > > I don't think the suggestion of applying an overlay embedded in U-Boot > > > > would work here. The code applying the overlay would need to run very > > > > early on in the pre-relocation phase. > > > > > > Yep it wouldn't > > > > > > > We'd also have to include > > > > overlays for all the models that Apple offers and pick the right one. > > > > And if a new model appears we can no longer just add a new device tree > > > > to m1n1. > > > > > > > > But maybe there is a case where the overlay approach would make sense... > > > > > > I think there is, for example I was thinking of TF-A doing all the hardware init > > > and then handover a DTB into u-boot on a register. In that case U-boot > > > could fixup the DTB before initialing the rest of the subsystems and make DM > > > happy. However as you pointed out that's not the case for all boards and > > > dealing with this in the early pre-relocation stage is close to > > > impossible, so let's drop that. > > > > > > > > > Thanks! > > > /Ilias > > > >
On Fri, Dec 03, 2021 at 04:30:40PM +0200, Ilias Apalodimas wrote: > Hi Heinrich, > > On Fri, Dec 03, 2021 at 02:59:44PM +0100, Heinrich Schuchardt wrote: > > On 12/3/21 11:27, Mark Kettenis wrote: > > > > Date: Fri, 3 Dec 2021 09:50:44 +0200 > > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > > > > > > > Hi Mark, > > > > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > > more. > > > > > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > > > with this approach. This proposal is working in the *exact* opposite > > > > > > direction and we'll never be able to get rid of device trees from > > > > > > U-Boot, even if at some point they move out of the kernel to a > > > > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > > > > Personally I'd be way happier if we could figure out were the specific > > > > > > U-Boot config nodes are needed and when are they needed. Based on > > > > > > what we figure out we could, pick up the device tree from a previous > > > > > > state bootloader and fix it up with our special nodes before we start > > > > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > > > > that indeed belong in the u-boot tree. > > > > > Applying a devicetree overlay can be implemented in common/board_f.c > > before the first usage of the devicetree to initialize devices (there > > are some that are initialized before relocation). > > Thanks for digging this up. Tbh I misunderstood the original mail from > Mark. When I read pre-reloc I assumed no C environment was up yet. > However this raises a few questions. > 1. The .dtbos will need to be embedded in the u-boot binary since > there's no FS access (or in some cases storage access to begin with) > 2. The RAM we have is going to be limited if we want to apply the overlays > before consoles etc are up, since it basically has to happen at some point > near 'fdtdec_setup' > 3.Are we are going to need some logic on how to apply the .dtbos? E.g think of > the same hardware with different configuration. You'll be able to use the > same binary, if you can somehow configure which overlays you want to apply. This has come up before and the answer has been "doing it this early will be too large" where large can mean either of .text space (we have many constrained platforms) or memory usage (this is before DRAM potentially). It's also on the flip side one of those places where maybe it's less of a problem on arm64 (where prior stages will have initialized much already) than arm32 (where we are very early) and other platforms. And we need solutions that work for both cases.
On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch in this > series: "doc: Add documentation about devicetree usage" > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > can obtain its devicetree at runtime, even it is has a devicetree built > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > caller may have a better idea about the hardware available in the machine. > This is the case with a few QEMU boards, for example. > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > option, available with either OF_SEPARATE or OF_EMBED. > > This series makes this change, adding various missing devicetree files > (and placeholders) to make the build work. > > Note: If board maintainers are able to add their own patch to add the > files, some patches in this series can be dropped. > > It also provides a few qemu clean-ups discovered along the way. The > qemu-riscv64_spl problem is fixed. Note that I can't run-time test this as the last patch fails to apply and is dependent on non-trivial missing changes ("/* The devicetree is typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c and that's part of the unchanging context where things fail to apply). So, here's my first bit of confusion. Today, I build for rpi_arm64 and no dtb files are built. I run this on my Pi 3 and everything works. With your series, I see all the dtbs have been built, and dts/dt.dtb and u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
Hi Tom, > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > > > more. > > > > > > > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > > > > with this approach. This proposal is working in the *exact* opposite > > > > > > > direction and we'll never be able to get rid of device trees from > > > > > > > U-Boot, even if at some point they move out of the kernel to a > > > > > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > > > > > Personally I'd be way happier if we could figure out were the specific > > > > > > > U-Boot config nodes are needed and when are they needed. Based on > > > > > > > what we figure out we could, pick up the device tree from a previous > > > > > > > state bootloader and fix it up with our special nodes before we start > > > > > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > > > > > that indeed belong in the u-boot tree. > > > > > > > > Applying a devicetree overlay can be implemented in common/board_f.c > > > before the first usage of the devicetree to initialize devices (there > > > are some that are initialized before relocation). > > > > Thanks for digging this up. Tbh I misunderstood the original mail from > > Mark. When I read pre-reloc I assumed no C environment was up yet. > > However this raises a few questions. > > 1. The .dtbos will need to be embedded in the u-boot binary since > > there's no FS access (or in some cases storage access to begin with) > > 2. The RAM we have is going to be limited if we want to apply the overlays > > before consoles etc are up, since it basically has to happen at some point > > near 'fdtdec_setup' > > 3.Are we are going to need some logic on how to apply the .dtbos? E.g think of > > the same hardware with different configuration. You'll be able to use the > > same binary, if you can somehow configure which overlays you want to apply. > > This has come up before and the answer has been "doing it this early > will be too large" where large can mean either of .text space (we have > many constrained platforms) or memory usage (this is before DRAM > potentially). It's also on the flip side one of those places where > maybe it's less of a problem on arm64 (where prior stages will have > initialized much already) than arm32 (where we are very early) and other > platforms. And we need solutions that work for both cases. So I have an answer on my (3).a We can use the bloblist for that. We could do something along the lines of 1. Include .dtbos in u-boot source 2. Standardize the bloblist handover discussion we had across bootloaders, so that the bloblist contains information of what .dtbos to apply. We can even take it a step further and request specific .dtbos to be applied before/after DRAM init to save some boards from the DRAM issue. 3. U-Boot applies the .dtbos on the fly. What's more interesting is that looking around what we currently have, the renesas RCAR platform is already doing something *very* similar [1]. [1] board/renesas/rcar-common/common.c -> fdtdec_board_setup Cheers /Ilias > > -- > Tom
On Thu, Dec 02, 2021 at 03:55:03PM -0700, Simon Glass wrote: [snip] > So now we find out the full horror of the fragmented mess that things > are to become. No way does this make sense. > > It is already too hard to build things. Just look at the meson/binman > series I sent last week. We need to make things easier for people, not > harder. I think this gets at one of my points. It seems exceedingly unlikely to me that every semi vendor is going to stop making their own tooling and per SoC requirements here and instead converge on a common one. I feel like that's not even true in x86, but it's largely just Intel or AMD rather than a handful of vendors. I see places we can make change happen and places we're going to have to use what we're given. Unless Arm Ltd pushes something, every semi gets to "innovate" in this area up until the point where SystemReady (well, the underlying specifications) say you MUST do X.
Hi Tom, On Fri, 3 Dec 2021 at 07:55, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch in this > > series: "doc: Add documentation about devicetree usage" > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > can obtain its devicetree at runtime, even it is has a devicetree built > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > caller may have a better idea about the hardware available in the machine. > > This is the case with a few QEMU boards, for example. > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > option, available with either OF_SEPARATE or OF_EMBED. > > > > This series makes this change, adding various missing devicetree files > > (and placeholders) to make the build work. > > > > Note: If board maintainers are able to add their own patch to add the > > files, some patches in this series can be dropped. > > > > It also provides a few qemu clean-ups discovered along the way. The > > qemu-riscv64_spl problem is fixed. > > Note that I can't run-time test this as the last patch fails to apply > and is dependent on non-trivial missing changes ("/* The devicetree is > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c > and that's part of the unchanging context where things fail to apply). That code is the penultimate patch ("fdt: Drop remaining preprocessor macros in fdtdec_setup()"). Did that patch apply OK? It is based on -next and is at dm/ofb-working if you want to compare. > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and > no dtb files are built. I run this on my Pi 3 and everything works. > With your series, I see all the dtbs have been built, and dts/dt.dtb and > u-boot.dtb have a Pi 4 dtb in them. Should this even run now? Yes, so long as OF_BOARD is enabled, which it is in this series. This is basically the same as the situation with rpi3, except it uses OF_EMBED (need to fix...) If we get as far as the std passage stuff then it will print out the source of the DT when it starts. If you like I could move three patches into this series: f88bd6a431a (HEAD -> ofb6) dm: core: Allow getting some basic stats 8121102a004 passage: Report the devicetree source c9c791ddedf passage: Record where the devicetree came from 5a0b7505498 (dm/ofb-working, dm-public/ofb-working) fdt: Don't call board_fdt_blob_setup() without OF_BOARD Booting with rpi3 and rpi4 I get (see the "devicetree:" bit): U-Boot 2022.01-rc3-00154-gf88bd6a431a (Dec 03 2021 - 08:32:41 -0700) DRAM: 992 MiB RPI 3 Model B (0xa02082) Core: 61 devices, 11 uclasses, devicetree: embed MMC: mmc@7e202000: 0, sdhci@7e300000: 1 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial Out: vidconsole Err: vidconsole U-Boot 2022.01-rc3-00154-gf88bd6a431a (Dec 03 2021 - 08:33:43 -0700) DRAM: 3.9 GiB RPI 4 Model B (0xc03111) Core: 197 devices, 13 uclasses, devicetree: board MMC: mmcnr@7e300000: 1, mmc@7e340000: 0 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial Out: vidconsole Regards, Simon
Hi Tom, On Fri, 3 Dec 2021 at 08:14, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 02, 2021 at 03:55:03PM -0700, Simon Glass wrote: > > [snip] > > So now we find out the full horror of the fragmented mess that things > > are to become. No way does this make sense. > > > > It is already too hard to build things. Just look at the meson/binman > > series I sent last week. We need to make things easier for people, not > > harder. > > I think this gets at one of my points. It seems exceedingly unlikely to > me that every semi vendor is going to stop making their own tooling and > per SoC requirements here and instead converge on a common one. I feel > like that's not even true in x86, but it's largely just Intel or AMD > rather than a handful of vendors. I see places we can make change > happen and places we're going to have to use what we're given. Unless > Arm Ltd pushes something, every semi gets to "innovate" in this area up > until the point where SystemReady (well, the underlying specifications) > say you MUST do X. Yes, I think you are right. So I think the best we can do for now is describe the image and the tools needed to make it, leaving the user to collect the required binaries and tools that are needed, repeating until binman stops saying 'missing external blobs'. BTW binman does have a way to show help for how to get each blob (tools/binman/missing-blob-help) and I plan to do the same for tools when I respin the meson series. For x86, Intel tools have ended up open source over time, e.g. under the influence of Chrome OS. I am less sure on the AMD side though, but will check that and push there if needed. I'd suggest that Arm should require the tools to be open-source. I will make that point next time I have a chance. Regards, Simon
On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote: > Hi Tom, > > On Fri, 3 Dec 2021 at 07:55, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch in this > > > series: "doc: Add documentation about devicetree usage" > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > caller may have a better idea about the hardware available in the machine. > > > This is the case with a few QEMU boards, for example. > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > This series makes this change, adding various missing devicetree files > > > (and placeholders) to make the build work. > > > > > > Note: If board maintainers are able to add their own patch to add the > > > files, some patches in this series can be dropped. > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > qemu-riscv64_spl problem is fixed. > > > > Note that I can't run-time test this as the last patch fails to apply > > and is dependent on non-trivial missing changes ("/* The devicetree is > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c > > and that's part of the unchanging context where things fail to apply). > > That code is the penultimate patch ("fdt: Drop remaining preprocessor > macros in fdtdec_setup()"). Did that patch apply OK? It is based on > -next and is at dm/ofb-working if you want to compare. I just fetch'd and built that instead, thanks. > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and > > no dtb files are built. I run this on my Pi 3 and everything works. > > With your series, I see all the dtbs have been built, and dts/dt.dtb and > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now? > > Yes, so long as OF_BOARD is enabled, which it is in this series. This > is basically the same as the situation with rpi3, except it uses > OF_EMBED (need to fix...) OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the .config, so I'm telling it to use the run-time device tree. It will never ever use this dtb, under any circumstance, right?
Hi Tom, On Fri, 3 Dec 2021 at 08:57, Tom Rini <trini@konsulko.com> wrote: > > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Fri, 3 Dec 2021 at 07:55, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch in this > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > caller may have a better idea about the hardware available in the machine. > > > > This is the case with a few QEMU boards, for example. > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > This series makes this change, adding various missing devicetree files > > > > (and placeholders) to make the build work. > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > files, some patches in this series can be dropped. > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > qemu-riscv64_spl problem is fixed. > > > > > > Note that I can't run-time test this as the last patch fails to apply > > > and is dependent on non-trivial missing changes ("/* The devicetree is > > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c > > > and that's part of the unchanging context where things fail to apply). > > > > That code is the penultimate patch ("fdt: Drop remaining preprocessor > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on > > -next and is at dm/ofb-working if you want to compare. > > I just fetch'd and built that instead, thanks. > > > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and > > > no dtb files are built. I run this on my Pi 3 and everything works. > > > With your series, I see all the dtbs have been built, and dts/dt.dtb and > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now? > > > > Yes, so long as OF_BOARD is enabled, which it is in this series. This > > is basically the same as the situation with rpi3, except it uses > > OF_EMBED (need to fix...) > > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the > .config, so I'm telling it to use the run-time device tree. It will > never ever use this dtb, under any circumstance, right? That's right, unless you disable OF_BOARD and build U-Boot again. Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided. I didn't even know that...yet another example of the confusion of the current state. Regards, Simon
On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote: > Hi Tom, > > On Fri, 3 Dec 2021 at 08:57, Tom Rini <trini@konsulko.com> wrote: > > > > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Fri, 3 Dec 2021 at 07:55, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch in this > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > caller may have a better idea about the hardware available in the machine. > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > (and placeholders) to make the build work. > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > files, some patches in this series can be dropped. > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > Note that I can't run-time test this as the last patch fails to apply > > > > and is dependent on non-trivial missing changes ("/* The devicetree is > > > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c > > > > and that's part of the unchanging context where things fail to apply). > > > > > > That code is the penultimate patch ("fdt: Drop remaining preprocessor > > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on > > > -next and is at dm/ofb-working if you want to compare. > > > > I just fetch'd and built that instead, thanks. > > > > > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and > > > > no dtb files are built. I run this on my Pi 3 and everything works. > > > > With your series, I see all the dtbs have been built, and dts/dt.dtb and > > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now? > > > > > > Yes, so long as OF_BOARD is enabled, which it is in this series. This > > > is basically the same as the situation with rpi3, except it uses > > > OF_EMBED (need to fix...) > > > > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a > > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the > > .config, so I'm telling it to use the run-time device tree. It will > > never ever use this dtb, under any circumstance, right? > > That's right, unless you disable OF_BOARD and build U-Boot again. And then it would fail to boot, because I'm on a 3, not a 4. > Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided. > I didn't even know that...yet another example of the confusion of the > current state. So, I'm trying to use this example here to lead to what I think is a reasonable compromise. As you note, with CONFIG_OF_BOARD=y all of those built trees, and the embedded tree, will not ever be used. But it makes the make logic a tiny bit easier to have some tree, not no tree. Why can't we: - When CONFIG_OF_BOARD=y not build those trees as part of "all" (individual rules should still work). - For linking, use an empty minimal valid dts. Because when CONFIG_OF_BOARD=y you will HAVE TO change the configuration to know what device tree you want it to even use if you disable CONFIG_OF_BOARD. You cannot assume that CONFIG_DEFAULT_DEVICE_TREE is correct, which is why it's unset currently. Does this make sense? If not, why not? And I have thoughts about other platforms too, but I want to stick with a fairly concrete example first.
is generallyHi Tom, On Fri, 3 Dec 2021 at 09:31, Tom Rini <trini@konsulko.com> wrote: > > On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Fri, 3 Dec 2021 at 08:57, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Fri, 3 Dec 2021 at 07:55, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch in this > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > Note that I can't run-time test this as the last patch fails to apply > > > > > and is dependent on non-trivial missing changes ("/* The devicetree is > > > > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c > > > > > and that's part of the unchanging context where things fail to apply). > > > > > > > > That code is the penultimate patch ("fdt: Drop remaining preprocessor > > > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on > > > > -next and is at dm/ofb-working if you want to compare. > > > > > > I just fetch'd and built that instead, thanks. > > > > > > > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and > > > > > no dtb files are built. I run this on my Pi 3 and everything works. > > > > > With your series, I see all the dtbs have been built, and dts/dt.dtb and > > > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now? > > > > > > > > Yes, so long as OF_BOARD is enabled, which it is in this series. This > > > > is basically the same as the situation with rpi3, except it uses > > > > OF_EMBED (need to fix...) > > > > > > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a > > > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the > > > .config, so I'm telling it to use the run-time device tree. It will > > > never ever use this dtb, under any circumstance, right? > > > > That's right, unless you disable OF_BOARD and build U-Boot again. > > And then it would fail to boot, because I'm on a 3, not a 4. Yes, but that's because the DT is wrong, right? The build builds all the different DTs but just selects one (the default) to put into u-boot.dtb and u-boot.bin We could make it generate images for all of them. I have thought about that as it stops us needing different boards just to handle having multiple DT options. But I haven't really looked at it. > > > Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided. > > I didn't even know that...yet another example of the confusion of the > > current state. > > So, I'm trying to use this example here to lead to what I think is a > reasonable compromise. As you note, with CONFIG_OF_BOARD=y all of those > built trees, and the embedded tree, will not ever be used. But it makes (except during development and for build testing) > the make logic a tiny bit easier to have some tree, not no tree. Why > can't we: > - When CONFIG_OF_BOARD=y not build those trees as part of "all" > (individual rules should still work). > - For linking, use an empty minimal valid dts. > > Because when CONFIG_OF_BOARD=y you will HAVE TO change the configuration > to know what device tree you want it to even use if you disable > CONFIG_OF_BOARD. You cannot assume that CONFIG_DEFAULT_DEVICE_TREE is > correct, which is why it's unset currently. > > Does this make sense? If not, why not? And I have thoughts about other > platforms too, but I want to stick with a fairly concrete example first. Well CONFIG_DEFAULT_DEVICE_TREE is generally correct. As above we could support generating multiple outputs, perhaps. I think Binman would be the best way to handle that, e.g. from a list of DTs. It makes some sense. I don't agree with not even building the trees. We should continue to build all the related DTs so we know that switching off OF_BOARD will work. If it isn't built, people won't even add it, right? Also you are going back to OF_BOARD having build-time effects, which I want to get away from. It should be a run-time option. That is my bottom line, really. In the future I hope that standard passage will provide a DT and we will be able to display where it came from, including what program provided it, for example. But disabling OF_BOARD should simply make the built-in one kick in. If it isn't there, how can it? Don't you find the current situation really confusing? It just makes no sense to me. Are you looking to have an empty DT in u-boot.bin? Perhaps we should provide a way to do that? But what is driving that desire? Regards, Simon
On Fri, Dec 03, 2021 at 09:45:12AM -0700, Simon Glass wrote: > is generallyHi Tom, > > On Fri, 3 Dec 2021 at 09:31, Tom Rini <trini@konsulko.com> wrote: > > > > On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Fri, 3 Dec 2021 at 08:57, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Fri, 3 Dec 2021 at 07:55, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch in this > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > Note that I can't run-time test this as the last patch fails to apply > > > > > > and is dependent on non-trivial missing changes ("/* The devicetree is > > > > > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c > > > > > > and that's part of the unchanging context where things fail to apply). > > > > > > > > > > That code is the penultimate patch ("fdt: Drop remaining preprocessor > > > > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on > > > > > -next and is at dm/ofb-working if you want to compare. > > > > > > > > I just fetch'd and built that instead, thanks. > > > > > > > > > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and > > > > > > no dtb files are built. I run this on my Pi 3 and everything works. > > > > > > With your series, I see all the dtbs have been built, and dts/dt.dtb and > > > > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now? > > > > > > > > > > Yes, so long as OF_BOARD is enabled, which it is in this series. This > > > > > is basically the same as the situation with rpi3, except it uses > > > > > OF_EMBED (need to fix...) > > > > > > > > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a > > > > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the > > > > .config, so I'm telling it to use the run-time device tree. It will > > > > never ever use this dtb, under any circumstance, right? > > > > > > That's right, unless you disable OF_BOARD and build U-Boot again. > > > > And then it would fail to boot, because I'm on a 3, not a 4. > > Yes, but that's because the DT is wrong, right? The build builds all > the different DTs but just selects one (the default) to put into > u-boot.dtb and u-boot.bin > > We could make it generate images for all of them. I have thought about > that as it stops us needing different boards just to handle having > multiple DT options. But I haven't really looked at it. It would be wrong because it's the wrong device tree for the hardware, yes. And we don't want to build N different binaries, the point of the target is that everything works like a good data-driven platform should. One binary, N platforms work because we get the configuration at run-time. > > > Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided. > > > I didn't even know that...yet another example of the confusion of the > > > current state. > > > > So, I'm trying to use this example here to lead to what I think is a > > reasonable compromise. As you note, with CONFIG_OF_BOARD=y all of those > > built trees, and the embedded tree, will not ever be used. But it makes > > (except during development and for build testing) But that's not relevant. For development you're changing the config. And for build testing zero device trees should be built, if zero device trees are included. > > the make logic a tiny bit easier to have some tree, not no tree. Why > > can't we: > > - When CONFIG_OF_BOARD=y not build those trees as part of "all" > > (individual rules should still work). > > - For linking, use an empty minimal valid dts. > > > > Because when CONFIG_OF_BOARD=y you will HAVE TO change the configuration > > to know what device tree you want it to even use if you disable > > CONFIG_OF_BOARD. You cannot assume that CONFIG_DEFAULT_DEVICE_TREE is > > correct, which is why it's unset currently. > > > > Does this make sense? If not, why not? And I have thoughts about other > > platforms too, but I want to stick with a fairly concrete example first. > > Well CONFIG_DEFAULT_DEVICE_TREE is generally correct. As above we > could support generating multiple outputs, perhaps. I think Binman > would be the best way to handle that, e.g. from a list of DTs. It's correct when we set it to non-zero, yes. But otherwise it's empty on purpose. And we already have a mechanism for when there's a single dtb that's common enough for N platforms, and we select the right one at run time. Nothing new needed here. > It makes some sense. > > I don't agree with not even building the trees. We should continue to > build all the related DTs so we know that switching off OF_BOARD will > work. If it isn't built, people won't even add it, right? We don't know that it will work just because we built some device trees. There's not even for certain device trees to add to the source trees. > Also you are going back to OF_BOARD having build-time effects, which I > want to get away from. It should be a run-time option. That is my > bottom line, really. In the future I hope that standard passage will > provide a DT and we will be able to display where it came from, > including what program provided it, for example. But disabling > OF_BOARD should simply make the built-in one kick in. If it isn't > there, how can it? I don't see how run-time option makes any sense when we know that there are cases where it's never the correct choice. You keep aiming to optimize a corner of the U-Boot internal developer workflow. That I think is maybe the big center of the disagreement. > Don't you find the current situation really confusing? It just makes > no sense to me. There's things that need to be cleaned up because we have some small number of platforms that went off and did their own thing. But largely yes, things make sense to me. We have: - We embedded the device tree that will configure U-Boot, because there is no way for the hardware to have provided us one. - We do not embed the device tree that will configure U-Boot, because there is already one present in memory for us to use. Then we have the developer option of: - We embedded the device tree that will configure U-Boot, because we're developing something. > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > provide a way to do that? But what is driving that desire? I'm looking for ways to convince you that we do not need to include a device tree in the binary. There's a growing set of devices where the device tree exists with the device. If it's missing, that's a huge fatal error we can't do all that much about. If we need to do something to that device tree for U-Boot, yes, fine, we should make it straight forward for the developer to do that. But that's not the common case! I guess another part of the problem is that historically almost all platforms were in the first case I list above, no run time provided device tree, so we took the kernel one and added our bindings to it. Now we're being bit by the growing number of platforms that are the second case, and how do we get our properties in there, and which ones even make sense to do that for.
On Thu, Dec 02, 2021 at 07:03:30PM -0700, Simon Glass wrote: > Hi Andre, > > On Thu, 2 Dec 2021 at 18:59, Andre Przywara <andre.przywara@arm.com> wrote: > > > > On Thu, 2 Dec 2021 13:34:07 -0500 > > Tom Rini <trini@konsulko.com> wrote: > > > > Hi, > > > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > > > > > appended to U-Boot > > > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > > > > not in favor of this new version either. > > > > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > > > > mainline…. > > > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > > > > more. > > > > > > > > > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > > > > > it had not come to this. > > > > > > > > > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > > > > > have a devicetree anywhere I can find. > > > > > > > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > > > > > > whatever caveats and documentation people want to clarify what is > > > > > > > > going on here. I'm happy to look at future options where the > > > > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > > > > > > within U-Boot for development purposes. > > > > > > > > > > > > > > > > I'll also note that the bootstd series shows the devicetree source: > > > > > > > > > > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > > > > > > > > > > > But for now, I still feel this is the best path forward. > > > > > > > > > > > > > > I'm not sure how to proceed here. The reviews are rather strongly > > > > > > > against the "include a device tree that won't be used". The use case of > > > > > > > "but for development someone might need to modify the device tree" is > > > > > > > handled by platforms documenting where / how to get the real one. We > > > > > > > should even update the Kconfig help to note that if you enable this your > > > > > > > board docs MUST explain where the device tree can be seen (or have some > > > > > > > legal reason you think it's OK to not...). > > > > > > > > > > > > Right, we can do lots of things as we have discussed. I am very > > > > > > willing to work on these and make sure it is hard to do the thing. But > > > > > > this series is long enough already. > > > > > > > > > > Yes, I think the rest of us had hoped you would come around to all of > > > > > our reasoning by this point, is why this is taking so long. > > > > > > > > > > > > > Look, if I thought this was all wrong I would not be doing it. We have > > > > a range of opinions: > > > > > > And the rest of us wouldn't keep trying to argue otherwise if we didn't > > > see problems with it, still. > > > > > > > - U-Boot should not have its own nodes/properties > > > > > > The caveat there is that aren't documented upstream bindings. I think > > > at this point the lack of screaming and otherwise "wait, no no no > > > don't!" that your current patch has gotten means it's time for a pull > > > request, and for that to go in, and so this line of argument would be > > > simply removed. > > > > > > > - U-Boot should not have DTs in-tree > > > > > > ... for the cases where the DTs are not used at run time, yes. > > > > > > > - U-Boot should have DTs only when essential > > > > > > I don't understand this point. Can you please elaborate? > > > > > > > - U-Boot should have DTs in-tree for all boards > > > > > > This is the line you're pushing and almost every other reviewer > > > disagrees with. > > > > > > > What's the downside here anyway? > > > > > > - A lack of clarity. We have dts files, you modify those dts files, > > > they aren't used. What's the point? Oh, you forgot to tweak > > > something else. Wait, now nothing works. Oh, it's a mismatch between > > > what this dts was at one point, and what it needs to be now to > > > actually work. > > > - We're adding more ongoing sync-up work. While I loudly applaud the > > > custodians that are keeping their dts files in sync very regularly, > > > and I sympathize with the custodians that want to do it more, but are > > > unable to find the time, I do not want to add more of this work. Even > > > more so when it's unclear who would be doing it. Or what the use is. > > > > > > There's probably more if I think about it harder, but those are the > > > first to spring to mind. > > > > > > > > > It is more than just development. A devicetree is needed for binman to > > > > > > work, even if it is empty. The documentation idea doesn't really work, > > > > > > as I think I have proven by the difficulty in getting this series > > > > > > together. An automated mechanism that runs in CI might be acceptable, > > > > > > but that is in the future. For now, I believe it just HAS to be > > > > > > in-tree. > > > > > > > > > > I still don't see any reason why we need these incorrect and not > > > > > functionally used device trees in-tree when a dummy invalid tree is > > > > > enough to make things link. We're dealing with real "we must have X.bin > > > > > in the output for things to function" issues on other platforms with > > > > > binman right now. Using a dummy dts should be fine. > > > > > > > > Incorrect in what way? > > > > > > Well, in the QEMU instance, they're only as correct as the parameters > > > passed to qemu-system-foo when you did -dumpdtb to start with. Lets > > > take TPM as that now should show up in the device tree, or not, > > > depending on if we have the backend side of it? Or all of the examples > > > of how to arbitrarily configure a system as Heinrich noted. > > > > > > Or the Pi examples where we need to use the device tree passed to us > > > because config.txt is the official way to modify things in the device > > > tree on that platform. > > > > I feel like a lot of the confusion stems from the very different > > roles that U-Boot plays on various platforms: > > - In the traditional way U-Boot is the first and only piece of code > > that runs between reset and the kernel. Having the DT as part of the > > U-Boot image, and thus in the U-Boot source tree, makes sense, given > > that we talk about a particular board only. > > - Many platforms run other pieces of software (TF-A, SCP firmware) > > alongside or before U-Boot, but still U-Boot is the main attraction, > > and is doing firmware and setup duties. Most cheap ARM SoCs (sunxi, > > RK) fall under this category. Depending on the particular firmware > > setup, having the DTs in the tree (as a copy of the canonical Linux > > source) again makes sense, and the DTB should probably be part of the > > built U-Boot image as well, unless there is some better place. > > > > But there is a quite different category of boards, where U-Boot is a > > mere *loader*, and UEFI provider. The heavy lifting of platform setup > > (clocks, DRAM, power) is either done by prior firmware code, or by a > > separate management processor. The RPis, ARM Juno boards, Highbank and > > many other (typically advanced) platforms fall under this category. > > U-Boot should be happy about the lesser burden, and just consume > > whatever DTB it finds in memory. > > Virtual/dynamic platforms like QEMU or the ARM FVP models also fall > > into this category: for a virtual platform hardware setup is mostly not > > needed (DRAM, clock gating), or the emulator takes care of this already. > > > > For all those platforms the DTB naturally lives with the other firmware > > bits already, or is even amended by them, and U-Boot should not try to > > duplicate this, especially when the hardware is somewhat dynamic. > > Yes that is all understood and have been bashed to death in various > threads. Still, it is not unreasonable, I think, for U-Boot to have a > way to use an in-tree devicetree for development and testing purposes. > It also reasonable, I think, to require some in-tree documentation > about how to get U-Boot running on the board. OK, but what at least I'm saying (and I think others are too), is that it's also not unreasonable to say that on some platforms that development and testing purpose might require the developer to enable things, rather than be the out of the box case (and may be more or less hard to do, depending on the platform).
Hi Tom, On Fri, 3 Dec 2021 at 12:25, Tom Rini <trini@konsulko.com> wrote: > > On Fri, Dec 03, 2021 at 09:45:12AM -0700, Simon Glass wrote: > > is generallyHi Tom, > > > > On Fri, 3 Dec 2021 at 09:31, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Fri, 3 Dec 2021 at 08:57, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Fri, 3 Dec 2021 at 07:55, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch in this > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > Note that I can't run-time test this as the last patch fails to apply > > > > > > > and is dependent on non-trivial missing changes ("/* The devicetree is > > > > > > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c > > > > > > > and that's part of the unchanging context where things fail to apply). > > > > > > > > > > > > That code is the penultimate patch ("fdt: Drop remaining preprocessor > > > > > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on > > > > > > -next and is at dm/ofb-working if you want to compare. > > > > > > > > > > I just fetch'd and built that instead, thanks. > > > > > > > > > > > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and > > > > > > > no dtb files are built. I run this on my Pi 3 and everything works. > > > > > > > With your series, I see all the dtbs have been built, and dts/dt.dtb and > > > > > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now? > > > > > > > > > > > > Yes, so long as OF_BOARD is enabled, which it is in this series. This > > > > > > is basically the same as the situation with rpi3, except it uses > > > > > > OF_EMBED (need to fix...) > > > > > > > > > > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a > > > > > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the > > > > > .config, so I'm telling it to use the run-time device tree. It will > > > > > never ever use this dtb, under any circumstance, right? > > > > > > > > That's right, unless you disable OF_BOARD and build U-Boot again. > > > > > > And then it would fail to boot, because I'm on a 3, not a 4. > > > > Yes, but that's because the DT is wrong, right? The build builds all > > the different DTs but just selects one (the default) to put into > > u-boot.dtb and u-boot.bin > > > > We could make it generate images for all of them. I have thought about > > that as it stops us needing different boards just to handle having > > multiple DT options. But I haven't really looked at it. > > It would be wrong because it's the wrong device tree for the hardware, > yes. And we don't want to build N different binaries, the point of the > target is that everything works like a good data-driven platform should. > One binary, N platforms work because we get the configuration at > run-time. That sounds fine then. I don't think we have a run-time problem. > > > > > Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided. > > > > I didn't even know that...yet another example of the confusion of the > > > > current state. > > > > > > So, I'm trying to use this example here to lead to what I think is a > > > reasonable compromise. As you note, with CONFIG_OF_BOARD=y all of those > > > built trees, and the embedded tree, will not ever be used. But it makes > > > > (except during development and for build testing) > > But that's not relevant. For development you're changing the config. > And for build testing zero device trees should be built, if zero device > trees are included. There is where we don't agree. > > > > the make logic a tiny bit easier to have some tree, not no tree. Why > > > can't we: > > > - When CONFIG_OF_BOARD=y not build those trees as part of "all" > > > (individual rules should still work). > > > - For linking, use an empty minimal valid dts. > > > > > > Because when CONFIG_OF_BOARD=y you will HAVE TO change the configuration > > > to know what device tree you want it to even use if you disable > > > CONFIG_OF_BOARD. You cannot assume that CONFIG_DEFAULT_DEVICE_TREE is > > > correct, which is why it's unset currently. > > > > > > Does this make sense? If not, why not? And I have thoughts about other > > > platforms too, but I want to stick with a fairly concrete example first. > > > > Well CONFIG_DEFAULT_DEVICE_TREE is generally correct. As above we > > could support generating multiple outputs, perhaps. I think Binman > > would be the best way to handle that, e.g. from a list of DTs. > > It's correct when we set it to non-zero, yes. But otherwise it's empty > on purpose. And we already have a mechanism for when there's a single > dtb that's common enough for N platforms, and we select the right one at > run time. Nothing new needed here. OK good. > > > It makes some sense. > > > > I don't agree with not even building the trees. We should continue to > > build all the related DTs so we know that switching off OF_BOARD will > > work. If it isn't built, people won't even add it, right? > > We don't know that it will work just because we built some device trees. > There's not even for certain device trees to add to the source trees. It needs to work, at least to a basic level. That's my point. We need to make this discoverable. > > > Also you are going back to OF_BOARD having build-time effects, which I > > want to get away from. It should be a run-time option. That is my > > bottom line, really. In the future I hope that standard passage will > > provide a DT and we will be able to display where it came from, > > including what program provided it, for example. But disabling > > OF_BOARD should simply make the built-in one kick in. If it isn't > > there, how can it? > > I don't see how run-time option makes any sense when we know that there > are cases where it's never the correct choice. You keep aiming to > optimize a corner of the U-Boot internal developer workflow. That I > think is maybe the big center of the disagreement. Yes, indeed. > > > Don't you find the current situation really confusing? It just makes > > no sense to me. > > There's things that need to be cleaned up because we have some small > number of platforms that went off and did their own thing. But largely > yes, things make sense to me. We have: > - We embedded the device tree that will configure U-Boot, because there > is no way for the hardware to have provided us one. > - We do not embed the device tree that will configure U-Boot, because > there is already one present in memory for us to use. > > Then we have the developer option of: > - We embedded the device tree that will configure U-Boot, because we're > developing something. Yes, agreed those are the cases. To me this needs to be a run-time choice. > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > provide a way to do that? But what is driving that desire? > > I'm looking for ways to convince you that we do not need to include a > device tree in the binary. There's a growing set of devices where the > device tree exists with the device. If it's missing, that's a huge > fatal error we can't do all that much about. If we need to do something > to that device tree for U-Boot, yes, fine, we should make it straight > forward for the developer to do that. But that's not the common case! Well we could add another Kconfig which tells U-Boot not to include a devicetree in u-boot.bin, if that would resolve this? I just want to make sure that we always build the devicetrees and that it is easy for a knowledgeable dev to switch over to use them, without spelunking through dozens of other projects to discover the secret DT that no one will tell us about. > > I guess another part of the problem is that historically almost all > platforms were in the first case I list above, no run time provided > device tree, so we took the kernel one and added our bindings to it. > Now we're being bit by the growing number of platforms that are the > second case, and how do we get our properties in there, and which ones > even make sense to do that for. I think upstreaming the bindings is the solution there. I've made a start, but we need to make progress with this series and all the other things in flight. I think a lot of people want U-Boot to not have a devicetree source files in it for ARMv8 platforms. I am strongly opposed to that. I've laid out my reasons very clearly in the past. I think this is a good summary: https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html I believe I have been consistent in this although with all the discussion I'm really not sure anymore. The problem is that various people have various views about how U-Boot should work with devicetree. I strongly believe that until we have bindings upstream, a central repo for DTs with easy downloading for builds, automated validation, among other things, we must maintain the devicetree in U-Boot. Just from the POV of energy expended, I do not want to be arguing with the Linaro folks about what U-Boot is allowed to do every month for the next two years. I'd rather set out the stall now and then deal with the problems it causes from that perspective. As you know, I also think many of the issues raised with my proposal here are not terminal and in fact are not even going to matter in practice. I believe they can be dealt with collaboratively over time as they come up. But what cannot be done, is rewriting U-Boot to fit with 6 other projects with their own idea of what U-Boot should be. Slightly sideways, looking into the future, everyone is going to become heartily sick of the complexity of building these images. Having something like Binman which can stitch things together can help. I think the meson RFC shows how this could be done to the benefit of all. At that point the DT is available and can be poked into various places in the image, or made available as needed. See next email. Regards, Simon
Hi Tom, On Fri, 3 Dec 2021 at 13:43, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 02, 2021 at 07:03:30PM -0700, Simon Glass wrote: > > Hi Andre, > > > > On Thu, 2 Dec 2021 at 18:59, Andre Przywara <andre.przywara@arm.com> wrote: > > > > > > On Thu, 2 Dec 2021 13:34:07 -0500 > > > Tom Rini <trini@konsulko.com> wrote: > > > > > > Hi, > > > > > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg@chromium.org> a écrit : > > > > > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > > > > > > > appended to U-Boot > > > > > > > > > > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch in this > > > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > > > > > > > > caller may have a better idea about the hardware available in the machine. > > > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > > > > > > > > not in favor of this new version either. > > > > > > > > > > > If you make a version without « fake DTs » as you name them, there are good > > > > > > > > > > > advances in the documentation and other areas that would be better in > > > > > > > > > > > mainline…. > > > > > > > > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > > > > > > > > would love there is a warning in capital letters at the top of the DTS fake > > > > > > > > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > > > > > > > > not using the one provided by the platform and the right way of dealing > > > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > > > > > more. > > > > > > > > > > > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > > > > > > it had not come to this. > > > > > > > > > > > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > > > > > > have a devicetree anywhere I can find. > > > > > > > > > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > > > > > > > whatever caveats and documentation people want to clarify what is > > > > > > > > > going on here. I'm happy to look at future options where the > > > > > > > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > > > > > > > within U-Boot for development purposes. > > > > > > > > > > > > > > > > > > I'll also note that the bootstd series shows the devicetree source: > > > > > > > > > > > > > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > > > > > > > > > > > > > But for now, I still feel this is the best path forward. > > > > > > > > > > > > > > > > I'm not sure how to proceed here. The reviews are rather strongly > > > > > > > > against the "include a device tree that won't be used". The use case of > > > > > > > > "but for development someone might need to modify the device tree" is > > > > > > > > handled by platforms documenting where / how to get the real one. We > > > > > > > > should even update the Kconfig help to note that if you enable this your > > > > > > > > board docs MUST explain where the device tree can be seen (or have some > > > > > > > > legal reason you think it's OK to not...). > > > > > > > > > > > > > > Right, we can do lots of things as we have discussed. I am very > > > > > > > willing to work on these and make sure it is hard to do the thing. But > > > > > > > this series is long enough already. > > > > > > > > > > > > Yes, I think the rest of us had hoped you would come around to all of > > > > > > our reasoning by this point, is why this is taking so long. > > > > > > > > > > > > > > > > Look, if I thought this was all wrong I would not be doing it. We have > > > > > a range of opinions: > > > > > > > > And the rest of us wouldn't keep trying to argue otherwise if we didn't > > > > see problems with it, still. > > > > > > > > > - U-Boot should not have its own nodes/properties > > > > > > > > The caveat there is that aren't documented upstream bindings. I think > > > > at this point the lack of screaming and otherwise "wait, no no no > > > > don't!" that your current patch has gotten means it's time for a pull > > > > request, and for that to go in, and so this line of argument would be > > > > simply removed. > > > > > > > > > - U-Boot should not have DTs in-tree > > > > > > > > ... for the cases where the DTs are not used at run time, yes. > > > > > > > > > - U-Boot should have DTs only when essential > > > > > > > > I don't understand this point. Can you please elaborate? > > > > > > > > > - U-Boot should have DTs in-tree for all boards > > > > > > > > This is the line you're pushing and almost every other reviewer > > > > disagrees with. > > > > > > > > > What's the downside here anyway? > > > > > > > > - A lack of clarity. We have dts files, you modify those dts files, > > > > they aren't used. What's the point? Oh, you forgot to tweak > > > > something else. Wait, now nothing works. Oh, it's a mismatch between > > > > what this dts was at one point, and what it needs to be now to > > > > actually work. > > > > - We're adding more ongoing sync-up work. While I loudly applaud the > > > > custodians that are keeping their dts files in sync very regularly, > > > > and I sympathize with the custodians that want to do it more, but are > > > > unable to find the time, I do not want to add more of this work. Even > > > > more so when it's unclear who would be doing it. Or what the use is. > > > > > > > > There's probably more if I think about it harder, but those are the > > > > first to spring to mind. > > > > > > > > > > > It is more than just development. A devicetree is needed for binman to > > > > > > > work, even if it is empty. The documentation idea doesn't really work, > > > > > > > as I think I have proven by the difficulty in getting this series > > > > > > > together. An automated mechanism that runs in CI might be acceptable, > > > > > > > but that is in the future. For now, I believe it just HAS to be > > > > > > > in-tree. > > > > > > > > > > > > I still don't see any reason why we need these incorrect and not > > > > > > functionally used device trees in-tree when a dummy invalid tree is > > > > > > enough to make things link. We're dealing with real "we must have X.bin > > > > > > in the output for things to function" issues on other platforms with > > > > > > binman right now. Using a dummy dts should be fine. > > > > > > > > > > Incorrect in what way? > > > > > > > > Well, in the QEMU instance, they're only as correct as the parameters > > > > passed to qemu-system-foo when you did -dumpdtb to start with. Lets > > > > take TPM as that now should show up in the device tree, or not, > > > > depending on if we have the backend side of it? Or all of the examples > > > > of how to arbitrarily configure a system as Heinrich noted. > > > > > > > > Or the Pi examples where we need to use the device tree passed to us > > > > because config.txt is the official way to modify things in the device > > > > tree on that platform. > > > > > > I feel like a lot of the confusion stems from the very different > > > roles that U-Boot plays on various platforms: > > > - In the traditional way U-Boot is the first and only piece of code > > > that runs between reset and the kernel. Having the DT as part of the > > > U-Boot image, and thus in the U-Boot source tree, makes sense, given > > > that we talk about a particular board only. > > > - Many platforms run other pieces of software (TF-A, SCP firmware) > > > alongside or before U-Boot, but still U-Boot is the main attraction, > > > and is doing firmware and setup duties. Most cheap ARM SoCs (sunxi, > > > RK) fall under this category. Depending on the particular firmware > > > setup, having the DTs in the tree (as a copy of the canonical Linux > > > source) again makes sense, and the DTB should probably be part of the > > > built U-Boot image as well, unless there is some better place. > > > > > > But there is a quite different category of boards, where U-Boot is a > > > mere *loader*, and UEFI provider. The heavy lifting of platform setup > > > (clocks, DRAM, power) is either done by prior firmware code, or by a > > > separate management processor. The RPis, ARM Juno boards, Highbank and > > > many other (typically advanced) platforms fall under this category. > > > U-Boot should be happy about the lesser burden, and just consume > > > whatever DTB it finds in memory. > > > Virtual/dynamic platforms like QEMU or the ARM FVP models also fall > > > into this category: for a virtual platform hardware setup is mostly not > > > needed (DRAM, clock gating), or the emulator takes care of this already. > > > > > > For all those platforms the DTB naturally lives with the other firmware > > > bits already, or is even amended by them, and U-Boot should not try to > > > duplicate this, especially when the hardware is somewhat dynamic. > > > > Yes that is all understood and have been bashed to death in various > > threads. Still, it is not unreasonable, I think, for U-Boot to have a > > way to use an in-tree devicetree for development and testing purposes. > > It also reasonable, I think, to require some in-tree documentation > > about how to get U-Boot running on the board. > > OK, but what at least I'm saying (and I think others are too), is that > it's also not unreasonable to say that on some platforms that > development and testing purpose might require the developer to enable > things, rather than be the out of the box case (and may be more or less > hard to do, depending on the platform). Can we just say that *for now*, that is actually not acceptable and we'll move to that model when we have our various pre-conditions (bindings upstream, a central repo for DTs with easy downloading for builds, automated validation) set up? I am trying to keep firmware together and make it easy to build and understand. Perhaps I can indicate how easy I'd like it to be. I'd like to build the board in U-Boot. I'd like Binman (or whatever tool we end up with here) to spit out a - list of missing binaries along with instructions on where to get them from / how to build them - list of missing tools along with instructions on where to get them from / how to build them and once we have installed those once, we can build U-Boot again and that platform successfully boots. Future iteration in U-Boot should be simply a case of rebuilding U-Boot. Iteration in other projects should just involve building that project, then running the packaging tool again. Regards, Simon
On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: [huge snip] > > There's things that need to be cleaned up because we have some small > > number of platforms that went off and did their own thing. But largely > > yes, things make sense to me. We have: > > - We embedded the device tree that will configure U-Boot, because there > > is no way for the hardware to have provided us one. > > - We do not embed the device tree that will configure U-Boot, because > > there is already one present in memory for us to use. > > > > Then we have the developer option of: > > - We embedded the device tree that will configure U-Boot, because we're > > developing something. > > Yes, agreed those are the cases. To me this needs to be a run-time choice. But it's not possible. That's the problem we keep going around and around about. People keep raising real life examples where you cannot make a run time choice between "device tree we're passed at run time" and "device tree we're compiled with". And it's not helpful. It is ALWAYS the case that we know that we want to override the run time device tree with our own, because it's a developer developing things or it's a user / production case where we must use the provided tree. NOT doing that is what leads to madness like we see for example on Pi where if we don't use the passed tree we still need to copy X/Y/Z out of it. > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > provide a way to do that? But what is driving that desire? > > > > I'm looking for ways to convince you that we do not need to include a > > device tree in the binary. There's a growing set of devices where the > > device tree exists with the device. If it's missing, that's a huge > > fatal error we can't do all that much about. If we need to do something > > to that device tree for U-Boot, yes, fine, we should make it straight > > forward for the developer to do that. But that's not the common case! > > Well we could add another Kconfig which tells U-Boot not to include a > devicetree in u-boot.bin, if that would resolve this? > > I just want to make sure that we always build the devicetrees and that > it is easy for a knowledgeable dev to switch over to use them, without > spelunking through dozens of other projects to discover the secret DT > that no one will tell us about. Should we demand better documentation for boards? Yes. But it's still a valid case to have zero device trees for a given platform in-tree. Xen is an example of this. QEMU is an example of this. Platforms need to work without adding special tweaks for us. Maybe that means some features can't be tested in QEMU-as-virtual-platform and only in QEMU-faithfully-emulating-specific-physical-platforms. > > I guess another part of the problem is that historically almost all > > platforms were in the first case I list above, no run time provided > > device tree, so we took the kernel one and added our bindings to it. > > Now we're being bit by the growing number of platforms that are the > > second case, and how do we get our properties in there, and which ones > > even make sense to do that for. > > I think upstreaming the bindings is the solution there. I've made a > start, but we need to make progress with this series and all the other > things in flight. I think a lot of people want U-Boot to not have a > devicetree source files in it for ARMv8 platforms. I am strongly > opposed to that. I've laid out my reasons very clearly in the past. I > think this is a good summary: > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html Yes, there are some ARMv8 platforms we will have to have the source files to, in tree, because they won't come to us at run time. But others we won't for practical reasons, namely that we can't statically provide something that exists dynamically without massive duplication of code or just taking things from that passed to us tree. > I believe I have been consistent in this although with all the > discussion I'm really not sure anymore. Yes, everyone has been consistent in these discussions. > The problem is that various people have various views about how U-Boot > should work with devicetree. I strongly believe that until we have > bindings upstream, a central repo for DTs with easy downloading for > builds, automated validation, among other things, we must maintain the > devicetree in U-Boot. Just from the POV of energy expended, I do not > want to be arguing with the Linaro folks about what U-Boot is allowed > to do every month for the next two years. I'd rather set out the stall > now and then deal with the problems it causes from that perspective. The problems of the last going on 12 years won't be solved instantly. The conflict as I see it is that you're insisting that all platforms must have statically usable device trees, and I (and I believe others) are saying that's unreasonable in cases where the trees are dynamic at heart, lets just ensure we have good enough documentation for them, which we don't today. To be clear and pick an example, I don't want Pi dts files in U-Boot, but, OK, it's an easy enough case to sync them up and so long as we aren't yet at the "now we pick at run time between compiled in or passed to us dtb", I can accept them in tree, but not in the resulting binary for OF_CONTROL=y. But as the Xen folks have also noted, there's no reasonable tree to include there. It does need to be better documented how to fire it up however, in our sources.
Hi Tom, On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote: > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > [huge snip] > > > There's things that need to be cleaned up because we have some small > > > number of platforms that went off and did their own thing. But largely > > > yes, things make sense to me. We have: > > > - We embedded the device tree that will configure U-Boot, because there > > > is no way for the hardware to have provided us one. > > > - We do not embed the device tree that will configure U-Boot, because > > > there is already one present in memory for us to use. > > > > > > Then we have the developer option of: > > > - We embedded the device tree that will configure U-Boot, because we're > > > developing something. > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice. > > But it's not possible. That's the problem we keep going around and > around about. People keep raising real life examples where you cannot > make a run time choice between "device tree we're passed at run time" > and "device tree we're compiled with". I haven't seen one. The most extreme case is QEMU and it works fine. I even added a test with it. What am I missing? > > And it's not helpful. It is ALWAYS the case that we know that we want > to override the run time device tree with our own, because it's a > developer developing things or it's a user / production case where we > must use the provided tree. NOT doing that is what leads to madness > like we see for example on Pi where if we don't use the passed tree we > still need to copy X/Y/Z out of it. Aren't you talking about the distro DT there, rather than the the one on the boot disk? That is my reading of that patch. If we need to do that sort of thing, it doesn't matter where the the cointrol DT comes from. You are still going to have to do that sort of thing. It is not ALWAYS the case. I've shown you how easy it is to disable OF_BOARD and still boot / iterate. > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > provide a way to do that? But what is driving that desire? > > > > > > I'm looking for ways to convince you that we do not need to include a > > > device tree in the binary. There's a growing set of devices where the > > > device tree exists with the device. If it's missing, that's a huge > > > fatal error we can't do all that much about. If we need to do something > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > forward for the developer to do that. But that's not the common case! > > > > Well we could add another Kconfig which tells U-Boot not to include a > > devicetree in u-boot.bin, if that would resolve this? > > > > I just want to make sure that we always build the devicetrees and that > > it is easy for a knowledgeable dev to switch over to use them, without > > spelunking through dozens of other projects to discover the secret DT > > that no one will tell us about. > > Should we demand better documentation for boards? Yes. But it's still > a valid case to have zero device trees for a given platform in-tree. > Xen is an example of this. QEMU is an example of this. Platforms need > to work without adding special tweaks for us. Maybe that means some > features can't be tested in QEMU-as-virtual-platform and only in > QEMU-faithfully-emulating-specific-physical-platforms. You mention QEMU (for ARM and RISC-V) and now XEN. They are a special case, I think. How about we create a special Kconfig for that case? We need to make some progress here. > > > > I guess another part of the problem is that historically almost all > > > platforms were in the first case I list above, no run time provided > > > device tree, so we took the kernel one and added our bindings to it. > > > Now we're being bit by the growing number of platforms that are the > > > second case, and how do we get our properties in there, and which ones > > > even make sense to do that for. > > > > I think upstreaming the bindings is the solution there. I've made a > > start, but we need to make progress with this series and all the other > > things in flight. I think a lot of people want U-Boot to not have a > > devicetree source files in it for ARMv8 platforms. I am strongly > > opposed to that. I've laid out my reasons very clearly in the past. I > > think this is a good summary: > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > > Yes, there are some ARMv8 platforms we will have to have the source > files to, in tree, because they won't come to us at run time. But > others we won't for practical reasons, namely that we can't statically > provide something that exists dynamically without massive duplication of > code or just taking things from that passed to us tree. So let's require that the static ones have the Linux DT in our tree for now. The dynamic ones are just QEMU for ARM and Xen, I think. If that's it then I can agree a special case for them, so long as we sort out the docs for Xen. > > > I believe I have been consistent in this although with all the > > discussion I'm really not sure anymore. > > Yes, everyone has been consistent in these discussions. I'd like to think more people accept that U-Boot is allowed its own properties than did at the start. > > > The problem is that various people have various views about how U-Boot > > should work with devicetree. I strongly believe that until we have > > bindings upstream, a central repo for DTs with easy downloading for > > builds, automated validation, among other things, we must maintain the > > devicetree in U-Boot. Just from the POV of energy expended, I do not > > want to be arguing with the Linaro folks about what U-Boot is allowed > > to do every month for the next two years. I'd rather set out the stall > > now and then deal with the problems it causes from that perspective. > > The problems of the last going on 12 years won't be solved instantly. > The conflict as I see it is that you're insisting that all platforms > must have statically usable device trees, and I (and I believe others) > are saying that's unreasonable in cases where the trees are dynamic at > heart, lets just ensure we have good enough documentation for them, > which we don't today. > > To be clear and pick an example, I don't want Pi dts files in U-Boot, > but, OK, it's an easy enough case to sync them up and so long as we > aren't yet at the "now we pick at run time between compiled in or passed > to us dtb", I can accept them in tree, but not in the resulting binary > for OF_CONTROL=y. But as the Xen folks have also noted, there's no > reasonable tree to include there. It does need to be better documented > how to fire it up however, in our sources. I'm OK with us copying in the Linux devicetree and using that. But OF_BOARD must be a run-time option and able to be disabled. The devicetree must be built, so it is actually real. We can have a separate OF_OMIT or something like that to omit the devicetree from the output image, perhaps. All of the other things need to wait until we make progress with devicetree bindings, validation, How can we make progress on this? We have different goals, as I have explained, so we are not going to agree on everything. Regards, Simon
Hi Simon, [...] > > [huge snip] > > > > There's things that need to be cleaned up because we have some small > > > > number of platforms that went off and did their own thing. But largely > > > > yes, things make sense to me. We have: > > > > - We embedded the device tree that will configure U-Boot, because there > > > > is no way for the hardware to have provided us one. > > > > - We do not embed the device tree that will configure U-Boot, because > > > > there is already one present in memory for us to use. > > > > > > > > Then we have the developer option of: > > > > - We embedded the device tree that will configure U-Boot, because we're > > > > developing something. > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice. > > I am not convinced the case is "we are developing something". The arguments for this are something along the lines of: 1. U-Boot will fail to compile if OF_SEPARATE is selected and you provide no DT so we need to include it. With which I disagree. The config option says "You must provide an external device tree" for a reason. 2. The DT's are hard to find. The 'hard to find' RPI DTs are in fact committed in the kernel. I am not sure about the rest, but honestly this isn't a convincing argument for me. What else are we gaining with it being a run time choice? One of the things this approach does address, but we keep conveniently ignoring, is that it tries to preserve the current status quo. You can go and add the special missing U-Boot nodes in those DT's. So that would bypass problems if the bindings get NAK'ed. But this is going to work against the fragmentation we are trying to resolve. > > But it's not possible. That's the problem we keep going around and > > around about. People keep raising real life examples where you cannot > > make a run time choice between "device tree we're passed at run time" > > and "device tree we're compiled with". > > I haven't seen one. The most extreme case is QEMU and it works fine. I > even added a test with it. What am I missing? IMHO 3b595da441cf is the commit that started the problem and tangled those 2 options. Note that this support has been removed from the dragonboard later in 0204d1b56b2f .... > > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > to override the run time device tree with our own, because it's a > > developer developing things or it's a user / production case where we > > must use the provided tree. NOT doing that is what leads to madness > > like we see for example on Pi where if we don't use the passed tree we > > still need to copy X/Y/Z out of it. > > Aren't you talking about the distro DT there, rather than the the one > on the boot disk? That is my reading of that patch. If we need to do > that sort of thing, it doesn't matter where the the cointrol DT comes > from. You are still going to have to do that sort of thing. > > It is not ALWAYS the case. I've shown you how easy it is to disable > OF_BOARD and still boot / iterate. > > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > device tree in the binary. There's a growing set of devices where the > > > > device tree exists with the device. If it's missing, that's a huge > > > > fatal error we can't do all that much about. If we need to do something > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > forward for the developer to do that. But that's not the common case! > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > I just want to make sure that we always build the devicetrees and that > > > it is easy for a knowledgeable dev to switch over to use them, without > > > spelunking through dozens of other projects to discover the secret DT > > > that no one will tell us about. So the translation of this for me is: We have 2 discrete options (that can be cleaned up further) which choose either to embed or receive the DTB. Let's tangle them and introduce a *new* third option to separate them if someone needs to. Which makes no sense to me. > > > > Should we demand better documentation for boards? Yes. But it's still > > a valid case to have zero device trees for a given platform in-tree. > > Xen is an example of this. QEMU is an example of this. Platforms need > > to work without adding special tweaks for us. Maybe that means some > > features can't be tested in QEMU-as-virtual-platform and only in > > QEMU-faithfully-emulating-specific-physical-platforms. > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > case, I think. How about we create a special Kconfig for that case? We > need to make some progress here. > > > > > > > I guess another part of the problem is that historically almost all > > > > platforms were in the first case I list above, no run time provided > > > > device tree, so we took the kernel one and added our bindings to it. > > > > Now we're being bit by the growing number of platforms that are the > > > > second case, and how do we get our properties in there, and which ones > > > > even make sense to do that for. > > > > > > I think upstreaming the bindings is the solution there. I've made a > > > start, but we need to make progress with this series and all the other > > > things in flight. I think a lot of people want U-Boot to not have a > > > devicetree source files in it for ARMv8 platforms. I am strongly > > > opposed to that. I've laid out my reasons very clearly in the past. I > > > think this is a good summary: > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > > > > Yes, there are some ARMv8 platforms we will have to have the source > > files to, in tree, because they won't come to us at run time. But > > others we won't for practical reasons, namely that we can't statically > > provide something that exists dynamically without massive duplication of > > code or just taking things from that passed to us tree. > > So let's require that the static ones have the Linux DT in our tree > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If > that's it then I can agree a special case for them, so long as we sort > out the docs for Xen. > > > > > > I believe I have been consistent in this although with all the > > > discussion I'm really not sure anymore. > > > > Yes, everyone has been consistent in these discussions. > > I'd like to think more people accept that U-Boot is allowed its own > properties than did at the start. > > > > > > The problem is that various people have various views about how U-Boot > > > should work with devicetree. I strongly believe that until we have > > > bindings upstream, a central repo for DTs with easy downloading for > > > builds, automated validation, among other things, we must maintain the > > > devicetree in U-Boot. Just from the POV of energy expended, I do not > > > want to be arguing with the Linaro folks about what U-Boot is allowed > > > to do every month for the next two years. I'd rather set out the stall > > > now and then deal with the problems it causes from that perspective. > > > > The problems of the last going on 12 years won't be solved instantly. > > The conflict as I see it is that you're insisting that all platforms > > must have statically usable device trees, and I (and I believe others) > > are saying that's unreasonable in cases where the trees are dynamic at > > heart, lets just ensure we have good enough documentation for them, > > which we don't today. > > > > To be clear and pick an example, I don't want Pi dts files in U-Boot, > > but, OK, it's an easy enough case to sync them up and so long as we > > aren't yet at the "now we pick at run time between compiled in or passed > > to us dtb", I can accept them in tree, but not in the resulting binary > > for OF_CONTROL=y. But as the Xen folks have also noted, there's no > > reasonable tree to include there. It does need to be better documented > > how to fire it up however, in our sources. > > I'm OK with us copying in the Linux devicetree and using that. But > OF_BOARD must be a run-time option and able to be disabled. The > devicetree must be built, so it is actually real. We can have a > separate OF_OMIT or something like that to omit the devicetree from > the output image, perhaps. > > All of the other things need to wait until we make progress with > devicetree bindings, validation, > > How can we make progress on this? We have different goals, as I have > explained, so we are not going to agree on everything. > > Regards, > Simon Regards /Ilias
> From: Simon Glass <sjg@chromium.org> > Date: Sat, 4 Dec 2021 08:20:55 -0700 > > Hi Tom, > > On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote: > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > [huge snip] > > > > There's things that need to be cleaned up because we have some small > > > > number of platforms that went off and did their own thing. But largely > > > > yes, things make sense to me. We have: > > > > - We embedded the device tree that will configure U-Boot, because there > > > > is no way for the hardware to have provided us one. > > > > - We do not embed the device tree that will configure U-Boot, because > > > > there is already one present in memory for us to use. > > > > > > > > Then we have the developer option of: > > > > - We embedded the device tree that will configure U-Boot, because we're > > > > developing something. > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice. > > > > But it's not possible. That's the problem we keep going around and > > around about. People keep raising real life examples where you cannot > > make a run time choice between "device tree we're passed at run time" > > and "device tree we're compiled with". > > I haven't seen one. The most extreme case is QEMU and it works fine. I > even added a test with it. What am I missing? Try it on your M1 Mac. > > And it's not helpful. It is ALWAYS the case that we know that we want > > to override the run time device tree with our own, because it's a > > developer developing things or it's a user / production case where we > > must use the provided tree. NOT doing that is what leads to madness > > like we see for example on Pi where if we don't use the passed tree we > > still need to copy X/Y/Z out of it. > > Aren't you talking about the distro DT there, rather than the the one > on the boot disk? That is my reading of that patch. If we need to do > that sort of thing, it doesn't matter where the the cointrol DT comes > from. You are still going to have to do that sort of thing. > > It is not ALWAYS the case. I've shown you how easy it is to disable > OF_BOARD and still boot / iterate. You are cheating. If you dump the device tree passed to U-Boot (or the OS) and don't change anything in the configuration of whatever is passing U-Boot that device tree this is likely to work fine. But it won't work in general. > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > device tree in the binary. There's a growing set of devices where the > > > > device tree exists with the device. If it's missing, that's a huge > > > > fatal error we can't do all that much about. If we need to do something > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > forward for the developer to do that. But that's not the common case! > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > I just want to make sure that we always build the devicetrees and that > > > it is easy for a knowledgeable dev to switch over to use them, without > > > spelunking through dozens of other projects to discover the secret DT > > > that no one will tell us about. > > > > Should we demand better documentation for boards? Yes. But it's still > > a valid case to have zero device trees for a given platform in-tree. > > Xen is an example of this. QEMU is an example of this. Platforms need > > to work without adding special tweaks for us. Maybe that means some > > features can't be tested in QEMU-as-virtual-platform and only in > > QEMU-faithfully-emulating-specific-physical-platforms. > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > case, I think. How about we create a special Kconfig for that case? We > need to make some progress here. No, Apple M1 and Raspberry Pi 4 also fall into that case. And I suspect at least some of the other boards that currently defined OF_BOARD fall into this category. So rather than changing the meaning of OF_BOARD, how about introducing another Kconfig option that indicates that switching to a device tree built into U-Boot is ok? You could use that to implement the runtime switching that you desire. This would prevent confusing users with options that result in making their systems unusable. > > > > I guess another part of the problem is that historically almost all > > > > platforms were in the first case I list above, no run time provided > > > > device tree, so we took the kernel one and added our bindings to it. > > > > Now we're being bit by the growing number of platforms that are the > > > > second case, and how do we get our properties in there, and which ones > > > > even make sense to do that for. > > > > > > I think upstreaming the bindings is the solution there. I've made a > > > start, but we need to make progress with this series and all the other > > > things in flight. I think a lot of people want U-Boot to not have a > > > devicetree source files in it for ARMv8 platforms. I am strongly > > > opposed to that. I've laid out my reasons very clearly in the past. I > > > think this is a good summary: > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > > > > Yes, there are some ARMv8 platforms we will have to have the source > > files to, in tree, because they won't come to us at run time. But > > others we won't for practical reasons, namely that we can't statically > > provide something that exists dynamically without massive duplication of > > code or just taking things from that passed to us tree. > > So let's require that the static ones have the Linux DT in our tree > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If > that's it then I can agree a special case for them, so long as we sort > out the docs for Xen. No Raspberry Pi (all models) and Apple M1 are also dynamic. And there are probably a few more that I'm not familliar with. We've explain how these are dynamic in this thread and earlier discussions many times already, but I can do it again if you need me to. > > > I believe I have been consistent in this although with all the > > > discussion I'm really not sure anymore. > > > > Yes, everyone has been consistent in these discussions. > > I'd like to think more people accept that U-Boot is allowed its own > properties than did at the start. > > > > > > The problem is that various people have various views about how U-Boot > > > should work with devicetree. I strongly believe that until we have > > > bindings upstream, a central repo for DTs with easy downloading for > > > builds, automated validation, among other things, we must maintain the > > > devicetree in U-Boot. Just from the POV of energy expended, I do not > > > want to be arguing with the Linaro folks about what U-Boot is allowed > > > to do every month for the next two years. I'd rather set out the stall > > > now and then deal with the problems it causes from that perspective. > > > > The problems of the last going on 12 years won't be solved instantly. > > The conflict as I see it is that you're insisting that all platforms > > must have statically usable device trees, and I (and I believe others) > > are saying that's unreasonable in cases where the trees are dynamic at > > heart, lets just ensure we have good enough documentation for them, > > which we don't today. > > > > To be clear and pick an example, I don't want Pi dts files in U-Boot, > > but, OK, it's an easy enough case to sync them up and so long as we > > aren't yet at the "now we pick at run time between compiled in or passed > > to us dtb", I can accept them in tree, but not in the resulting binary > > for OF_CONTROL=y. But as the Xen folks have also noted, there's no > > reasonable tree to include there. It does need to be better documented > > how to fire it up however, in our sources. > > I'm OK with us copying in the Linux devicetree and using that. But > OF_BOARD must be a run-time option and able to be disabled. The > devicetree must be built, so it is actually real. We can have a > separate OF_OMIT or something like that to omit the devicetree from > the output image, perhaps. > > All of the other things need to wait until we make progress with > devicetree bindings, validation, > > How can we make progress on this? We have different goals, as I have > explained, so we are not going to agree on everything. > > Regards, > Simon >
Hi Simon Le sam. 4 déc. 2021 à 16:21, Simon Glass <sjg@chromium.org> a écrit : > Hi Tom, > > On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote: > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > [huge snip] > > > > There's things that need to be cleaned up because we have some small > > > > number of platforms that went off and did their own thing. But > largely > > > > yes, things make sense to me. We have: > > > > - We embedded the device tree that will configure U-Boot, because > there > > > > is no way for the hardware to have provided us one. > > > > - We do not embed the device tree that will configure U-Boot, because > > > > there is already one present in memory for us to use. > > > > > > > > Then we have the developer option of: > > > > - We embedded the device tree that will configure U-Boot, because > we're > > > > developing something. > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time > choice. > > > > But it's not possible. That's the problem we keep going around and > > around about. People keep raising real life examples where you cannot > > make a run time choice between "device tree we're passed at run time" > > and "device tree we're compiled with". > > I haven't seen one. The most extreme case is QEMU and it works fine. I > even added a test with it. What am I missing? > > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > to override the run time device tree with our own, because it's a > > developer developing things or it's a user / production case where we > > must use the provided tree. NOT doing that is what leads to madness > > like we see for example on Pi where if we don't use the passed tree we > > still need to copy X/Y/Z out of it. > > Aren't you talking about the distro DT there, rather than the the one > on the boot disk? That is my reading of that patch. If we need to do > that sort of thing, it doesn't matter where the the cointrol DT comes > from. You are still going to have to do that sort of thing. > > It is not ALWAYS the case. I've shown you how easy it is to disable > OF_BOARD and still boot / iterate. > > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we > should > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > device tree in the binary. There's a growing set of devices where > the > > > > device tree exists with the device. If it's missing, that's a huge > > > > fatal error we can't do all that much about. If we need to do > something > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > forward for the developer to do that. But that's not the common > case! > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > I just want to make sure that we always build the devicetrees and that > > > it is easy for a knowledgeable dev to switch over to use them, without > > > spelunking through dozens of other projects to discover the secret DT > > > that no one will tell us about. > > > > Should we demand better documentation for boards? Yes. But it's still > > a valid case to have zero device trees for a given platform in-tree. > > Xen is an example of this. QEMU is an example of this. Platforms need > > to work without adding special tweaks for us. Maybe that means some > > features can't be tested in QEMU-as-virtual-platform and only in > > QEMU-faithfully-emulating-specific-physical-platforms. > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > case, I think. How about we create a special Kconfig for that case? We > need to make some progress here. > > > > > > > I guess another part of the problem is that historically almost all > > > > platforms were in the first case I list above, no run time provided > > > > device tree, so we took the kernel one and added our bindings to it. > > > > Now we're being bit by the growing number of platforms that are the > > > > second case, and how do we get our properties in there, and which > ones > > > > even make sense to do that for. > > > > > > I think upstreaming the bindings is the solution there. I've made a > > > start, but we need to make progress with this series and all the other > > > things in flight. I think a lot of people want U-Boot to not have a > > > devicetree source files in it for ARMv8 platforms. I am strongly > > > opposed to that. I've laid out my reasons very clearly in the past. I > > > think this is a good summary: > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > > > > Yes, there are some ARMv8 platforms we will have to have the source > > files to, in tree, because they won't come to us at run time. But > > others we won't for practical reasons, namely that we can't statically > > provide something that exists dynamically without massive duplication of > > code or just taking things from that passed to us tree. > > So let's require that the static ones have the Linux DT in our tree > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If > that's it then I can agree a special case for them, so long as we sort > out the docs for Xen. > > > > > > I believe I have been consistent in this although with all the > > > discussion I'm really not sure anymore. > > > > Yes, everyone has been consistent in these discussions. > > I'd like to think more people accept that U-Boot is allowed its own > properties than did at the start. there is no question that U-Boot can have its properties specified in Device Tree. What we may not agree in is how those properties make it to U-Boot. > > > > > > > The problem is that various people have various views about how U-Boot > > > should work with devicetree. I strongly believe that until we have > > > bindings upstream, a central repo for DTs with easy downloading for > > > builds, automated validation, among other things, we must maintain the > > > devicetree in U-Boot. Just from the POV of energy expended, I do not > > > want to be arguing with the Linaro folks about what U-Boot is allowed > > > to do every month for the next two years. I'd rather set out the stall > > > now and then deal with the problems it causes from that perspective. > > > > The problems of the last going on 12 years won't be solved instantly. > > The conflict as I see it is that you're insisting that all platforms > > must have statically usable device trees, and I (and I believe others) > > are saying that's unreasonable in cases where the trees are dynamic at > > heart, lets just ensure we have good enough documentation for them, > > which we don't today. > > > > To be clear and pick an example, I don't want Pi dts files in U-Boot, > > but, OK, it's an easy enough case to sync them up and so long as we > > aren't yet at the "now we pick at run time between compiled in or passed > > to us dtb", I can accept them in tree, but not in the resulting binary > > for OF_CONTROL=y. But as the Xen folks have also noted, there's no > > reasonable tree to include there. It does need to be better documented > > how to fire it up however, in our sources. > > I'm OK with us copying in the Linux devicetree and using that. But > OF_BOARD must be a run-time option and able to be disabled. The > devicetree must be built, so it is actually real. We can have a > separate OF_OMIT or something like that to omit the devicetree from > the output image, perhaps. > > All of the other things need to wait until we make progress with > devicetree bindings, validation, > > How can we make progress on this? We have different goals, as I have > explained, so we are not going to agree on everything. > A V7 with empty device trees (except with comments to explain why they are empty and how to force one for dev purposes) for platforms that provide U-Boot with DT (RPI, Qemu, xen…) seem a good base unless someone can propose a better way forward. If we build consensus on the feature aspect of the patch set I will be able to dedicate some time on the documentation part as I thought it was useless to check those until we agree on the functional part. > > Regards, > Simon >
Hi Ilias, On Sat, 4 Dec 2021 at 08:58, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > Hi Simon, > > [...] > > > [huge snip] > > > > > There's things that need to be cleaned up because we have some small > > > > > number of platforms that went off and did their own thing. But largely > > > > > yes, things make sense to me. We have: > > > > > - We embedded the device tree that will configure U-Boot, because there > > > > > is no way for the hardware to have provided us one. > > > > > - We do not embed the device tree that will configure U-Boot, because > > > > > there is already one present in memory for us to use. > > > > > > > > > > Then we have the developer option of: > > > > > - We embedded the device tree that will configure U-Boot, because we're > > > > > developing something. > > > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice. > > > > > I am not convinced the case is "we are developing something". The > arguments for this are something along the lines of: > 1. U-Boot will fail to compile if OF_SEPARATE is selected and you provide > no DT so we need to include it. With which I disagree. The config option > says "You must provide an external device tree" for a reason. Where are you reading that? I'm lost. OF_SEPARATE means it is not embedded in U-Boot but is attached to the end of it. > 2. The DT's are hard to find. The 'hard to find' RPI DTs are in fact > committed in the kernel. I am not sure about the rest, but honestly this > isn't a convincing argument for me. Great, so you've solved that one but even that was confusing for me, as my patch should make clear. Every single board would be its own special snowflake if we went that way. So if they are in the kernel, we just need to put them in U-Boot too, so problem solved. The auto-sync thing that I believe Rob is working on will make things easy. > > What else are we gaining with it being a run time choice? One of the We are requiring a DT to be present in the U-Boot tree for development, documentation and discoverability purposes. Devs can turn OF_BOARD on and off as it suits them when iterating on a platform. > things this approach does address, but we keep conveniently ignoring, is > that it tries to preserve the current status quo. You can go and add the > special missing U-Boot nodes in those DT's. So that would bypass problems > if the bindings get NAK'ed. But this is going to work against the > fragmentation we are trying to resolve. Well that's another reason why we need in-tree DTs at the moment. That reason goes away once we have our bindings upstream and are able to do what we need with DT there. > > > > But it's not possible. That's the problem we keep going around and > > > around about. People keep raising real life examples where you cannot > > > make a run time choice between "device tree we're passed at run time" > > > and "device tree we're compiled with". > > > > I haven't seen one. The most extreme case is QEMU and it works fine. I > > even added a test with it. What am I missing? (I think my point there is made) > > IMHO 3b595da441cf is the commit that started the problem and tangled those > 2 options. Note that this support has been removed from the dragonboard > later in 0204d1b56b2f .... Yes it is one of them. There may be cases where we want to patch up the DT that U-Boot builds. In fact OF_BOARD does not mean it came from a prior stage. All sorts of things could be going on. We should not conflate building a DT with OF_BOARD. > > > > > > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > > to override the run time device tree with our own, because it's a > > > developer developing things or it's a user / production case where we > > > must use the provided tree. NOT doing that is what leads to madness > > > like we see for example on Pi where if we don't use the passed tree we > > > still need to copy X/Y/Z out of it. > > > > Aren't you talking about the distro DT there, rather than the the one > > on the boot disk? That is my reading of that patch. If we need to do > > that sort of thing, it doesn't matter where the the cointrol DT comes > > from. You are still going to have to do that sort of thing. > > > > It is not ALWAYS the case. I've shown you how easy it is to disable > > OF_BOARD and still boot / iterate. > > > > > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > > device tree in the binary. There's a growing set of devices where the > > > > > device tree exists with the device. If it's missing, that's a huge > > > > > fatal error we can't do all that much about. If we need to do something > > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > > forward for the developer to do that. But that's not the common case! > > > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > > > I just want to make sure that we always build the devicetrees and that > > > > it is easy for a knowledgeable dev to switch over to use them, without > > > > spelunking through dozens of other projects to discover the secret DT > > > > that no one will tell us about. > > So the translation of this for me is: > We have 2 discrete options (that can be cleaned up further) which choose > either to embed or receive the DTB. Let's tangle them and introduce a > *new* third option to separate them if someone needs to. Which makes no > sense to me. Embed is confusing because OF_EMBED means to link it into U-Boot (just used for debugging) I think this is the core of the problem. There are just lots of ideas about how all of this should work. Please try out the series and see if you find any problems. Then we can talk about actual issues rather than things that might happen. The two options you refer to are OF_SEPARATE and OF_BOARD. We will perhaps have OF_PASSAGE at some point. We already have OF_EMBED. To me, OF_BOARD and OF_PASSAGE are run-time things because they indicate what we expect to happen at runtime. If something goes wrong, we might still be able to print an error message, if we have a backup DT. But OF_BOARD and OF_PASSAGE are not related to the build itself. IMO OF_BOARD is underspecified. One day I would like to move towards defining these cases better, e.g. - DT is passed in a register (rpi and apple_m1, stm32mp, RISC-V, qemu RISC-V, bcmstb, Octeon, Xen) - DT is at a fixed address (qemu, highbank, socrates, qemu ppc) - DT is in a file (sandbox) IMO many of these could all be handled with standard passage, i.e. in a standard way. > > > > > > > Should we demand better documentation for boards? Yes. But it's still > > > a valid case to have zero device trees for a given platform in-tree. > > > Xen is an example of this. QEMU is an example of this. Platforms need > > > to work without adding special tweaks for us. Maybe that means some > > > features can't be tested in QEMU-as-virtual-platform and only in > > > QEMU-faithfully-emulating-specific-physical-platforms. > > > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > > case, I think. How about we create a special Kconfig for that case? We > > need to make some progress here. > > > > > > > > > > I guess another part of the problem is that historically almost all > > > > > platforms were in the first case I list above, no run time provided > > > > > device tree, so we took the kernel one and added our bindings to it. > > > > > Now we're being bit by the growing number of platforms that are the > > > > > second case, and how do we get our properties in there, and which ones > > > > > even make sense to do that for. > > > > > > > > I think upstreaming the bindings is the solution there. I've made a > > > > start, but we need to make progress with this series and all the other > > > > things in flight. I think a lot of people want U-Boot to not have a > > > > devicetree source files in it for ARMv8 platforms. I am strongly > > > > opposed to that. I've laid out my reasons very clearly in the past. I > > > > think this is a good summary: > > > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > > > > > > Yes, there are some ARMv8 platforms we will have to have the source > > > files to, in tree, because they won't come to us at run time. But > > > others we won't for practical reasons, namely that we can't statically > > > provide something that exists dynamically without massive duplication of > > > code or just taking things from that passed to us tree. > > > > So let's require that the static ones have the Linux DT in our tree > > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If > > that's it then I can agree a special case for them, so long as we sort > > out the docs for Xen. > > > > > > > > > I believe I have been consistent in this although with all the > > > > discussion I'm really not sure anymore. > > > > > > Yes, everyone has been consistent in these discussions. > > > > I'd like to think more people accept that U-Boot is allowed its own > > properties than did at the start. > > > > > > > > > The problem is that various people have various views about how U-Boot > > > > should work with devicetree. I strongly believe that until we have > > > > bindings upstream, a central repo for DTs with easy downloading for > > > > builds, automated validation, among other things, we must maintain the > > > > devicetree in U-Boot. Just from the POV of energy expended, I do not > > > > want to be arguing with the Linaro folks about what U-Boot is allowed > > > > to do every month for the next two years. I'd rather set out the stall > > > > now and then deal with the problems it causes from that perspective. > > > > > > The problems of the last going on 12 years won't be solved instantly. > > > The conflict as I see it is that you're insisting that all platforms > > > must have statically usable device trees, and I (and I believe others) > > > are saying that's unreasonable in cases where the trees are dynamic at > > > heart, lets just ensure we have good enough documentation for them, > > > which we don't today. > > > > > > To be clear and pick an example, I don't want Pi dts files in U-Boot, > > > but, OK, it's an easy enough case to sync them up and so long as we > > > aren't yet at the "now we pick at run time between compiled in or passed > > > to us dtb", I can accept them in tree, but not in the resulting binary > > > for OF_CONTROL=y. But as the Xen folks have also noted, there's no > > > reasonable tree to include there. It does need to be better documented > > > how to fire it up however, in our sources. > > > > I'm OK with us copying in the Linux devicetree and using that. But > > OF_BOARD must be a run-time option and able to be disabled. The > > devicetree must be built, so it is actually real. We can have a > > separate OF_OMIT or something like that to omit the devicetree from > > the output image, perhaps. > > > > All of the other things need to wait until we make progress with > > devicetree bindings, validation, > > > > How can we make progress on this? We have different goals, as I have > > explained, so we are not going to agree on everything. Regards, Simon
Hi Mark, On Sat, 4 Dec 2021 at 09:09, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > From: Simon Glass <sjg@chromium.org> > > Date: Sat, 4 Dec 2021 08:20:55 -0700 > > > > Hi Tom, > > > > On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > > > [huge snip] > > > > > There's things that need to be cleaned up because we have some small > > > > > number of platforms that went off and did their own thing. But largely > > > > > yes, things make sense to me. We have: > > > > > - We embedded the device tree that will configure U-Boot, because there > > > > > is no way for the hardware to have provided us one. > > > > > - We do not embed the device tree that will configure U-Boot, because > > > > > there is already one present in memory for us to use. > > > > > > > > > > Then we have the developer option of: > > > > > - We embedded the device tree that will configure U-Boot, because we're > > > > > developing something. > > > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice. > > > > > > But it's not possible. That's the problem we keep going around and > > > around about. People keep raising real life examples where you cannot > > > make a run time choice between "device tree we're passed at run time" > > > and "device tree we're compiled with". > > > > I haven't seen one. The most extreme case is QEMU and it works fine. I > > even added a test with it. What am I missing? > > Try it on your M1 Mac. I have tested this series on a Mac Mini and it works fine. You cannot run U-Boot by itself, of course, since it needs m1n1. Also m1n1 fixes up the DT. I'm not sure exactly what changes it makes, as I don't even have a serial console on the machine at present. But in any case, I can easily iterate on U-Boot on this platform with U-Boot building the DTs. It certainly meets my requirements at present. > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > > to override the run time device tree with our own, because it's a > > > developer developing things or it's a user / production case where we > > > must use the provided tree. NOT doing that is what leads to madness > > > like we see for example on Pi where if we don't use the passed tree we > > > still need to copy X/Y/Z out of it. > > > > Aren't you talking about the distro DT there, rather than the the one > > on the boot disk? That is my reading of that patch. If we need to do > > that sort of thing, it doesn't matter where the the cointrol DT comes > > from. You are still going to have to do that sort of thing. > > > > It is not ALWAYS the case. I've shown you how easy it is to disable > > OF_BOARD and still boot / iterate. > > You are cheating. If you dump the device tree passed to U-Boot (or > the OS) and don't change anything in the configuration of whatever is > passing U-Boot that device tree this is likely to work fine. But it > won't work in general. I didn't say it would. What are you getting at? Can you please try to test my series so you get the hang of what it is actually doing? > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > > device tree in the binary. There's a growing set of devices where the > > > > > device tree exists with the device. If it's missing, that's a huge > > > > > fatal error we can't do all that much about. If we need to do something > > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > > forward for the developer to do that. But that's not the common case! > > > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > > > I just want to make sure that we always build the devicetrees and that > > > > it is easy for a knowledgeable dev to switch over to use them, without > > > > spelunking through dozens of other projects to discover the secret DT > > > > that no one will tell us about. > > > > > > Should we demand better documentation for boards? Yes. But it's still > > > a valid case to have zero device trees for a given platform in-tree. > > > Xen is an example of this. QEMU is an example of this. Platforms need > > > to work without adding special tweaks for us. Maybe that means some > > > features can't be tested in QEMU-as-virtual-platform and only in > > > QEMU-faithfully-emulating-specific-physical-platforms. > > > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > > case, I think. How about we create a special Kconfig for that case? We > > need to make some progress here. > > No, Apple M1 and Raspberry Pi 4 also fall into that case. And I > suspect at least some of the other boards that currently defined > OF_BOARD fall into this category. So rather than changing the meaning > of OF_BOARD, how about introducing another Kconfig option that > indicates that switching to a device tree built into U-Boot is ok? > You could use that to implement the runtime switching that you desire. > This would prevent confusing users with options that result in making > their systems unusable. Yes Tom and I have already discussed doing that, along with various other measures to avoid people doing the wrong thing. > > > > > > I guess another part of the problem is that historically almost all > > > > > platforms were in the first case I list above, no run time provided > > > > > device tree, so we took the kernel one and added our bindings to it. > > > > > Now we're being bit by the growing number of platforms that are the > > > > > second case, and how do we get our properties in there, and which ones > > > > > even make sense to do that for. > > > > > > > > I think upstreaming the bindings is the solution there. I've made a > > > > start, but we need to make progress with this series and all the other > > > > things in flight. I think a lot of people want U-Boot to not have a > > > > devicetree source files in it for ARMv8 platforms. I am strongly > > > > opposed to that. I've laid out my reasons very clearly in the past. I > > > > think this is a good summary: > > > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > > > > > > Yes, there are some ARMv8 platforms we will have to have the source > > > files to, in tree, because they won't come to us at run time. But > > > others we won't for practical reasons, namely that we can't statically > > > provide something that exists dynamically without massive duplication of > > > code or just taking things from that passed to us tree. > > > > So let's require that the static ones have the Linux DT in our tree > > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If > > that's it then I can agree a special case for them, so long as we sort > > out the docs for Xen. > > No Raspberry Pi (all models) and Apple M1 are also dynamic. And there > are probably a few more that I'm not familliar with. We've explain > how these are dynamic in this thread and earlier discussions many > times already, but I can do it again if you need me to. So long as the DT is available in U-Boot and we can do development there, I am happy. It is when it comes from somewhere else and we need to do investigation just to be able to figure it out, I am not happy. [..] Regards, Simon
Hi François, On Sat, 4 Dec 2021 at 09:55, François Ozog <francois.ozog@linaro.org> wrote: > > Hi Simon > > Le sam. 4 déc. 2021 à 16:21, Simon Glass <sjg@chromium.org> a écrit : >> >> Hi Tom, >> >> On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote: >> > >> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: >> > >> > [huge snip] >> > > > There's things that need to be cleaned up because we have some small >> > > > number of platforms that went off and did their own thing. But largely >> > > > yes, things make sense to me. We have: >> > > > - We embedded the device tree that will configure U-Boot, because there >> > > > is no way for the hardware to have provided us one. >> > > > - We do not embed the device tree that will configure U-Boot, because >> > > > there is already one present in memory for us to use. >> > > > >> > > > Then we have the developer option of: >> > > > - We embedded the device tree that will configure U-Boot, because we're >> > > > developing something. >> > > >> > > Yes, agreed those are the cases. To me this needs to be a run-time choice. >> > >> > But it's not possible. That's the problem we keep going around and >> > around about. People keep raising real life examples where you cannot >> > make a run time choice between "device tree we're passed at run time" >> > and "device tree we're compiled with". >> >> I haven't seen one. The most extreme case is QEMU and it works fine. I >> even added a test with it. What am I missing? >> >> > >> > And it's not helpful. It is ALWAYS the case that we know that we want >> > to override the run time device tree with our own, because it's a >> > developer developing things or it's a user / production case where we >> > must use the provided tree. NOT doing that is what leads to madness >> > like we see for example on Pi where if we don't use the passed tree we >> > still need to copy X/Y/Z out of it. >> >> Aren't you talking about the distro DT there, rather than the the one >> on the boot disk? That is my reading of that patch. If we need to do >> that sort of thing, it doesn't matter where the the cointrol DT comes >> from. You are still going to have to do that sort of thing. >> >> It is not ALWAYS the case. I've shown you how easy it is to disable >> OF_BOARD and still boot / iterate. >> >> > >> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should >> > > > > provide a way to do that? But what is driving that desire? >> > > > >> > > > I'm looking for ways to convince you that we do not need to include a >> > > > device tree in the binary. There's a growing set of devices where the >> > > > device tree exists with the device. If it's missing, that's a huge >> > > > fatal error we can't do all that much about. If we need to do something >> > > > to that device tree for U-Boot, yes, fine, we should make it straight >> > > > forward for the developer to do that. But that's not the common case! >> > > >> > > Well we could add another Kconfig which tells U-Boot not to include a >> > > devicetree in u-boot.bin, if that would resolve this? >> > > >> > > I just want to make sure that we always build the devicetrees and that >> > > it is easy for a knowledgeable dev to switch over to use them, without >> > > spelunking through dozens of other projects to discover the secret DT >> > > that no one will tell us about. >> > >> > Should we demand better documentation for boards? Yes. But it's still >> > a valid case to have zero device trees for a given platform in-tree. >> > Xen is an example of this. QEMU is an example of this. Platforms need >> > to work without adding special tweaks for us. Maybe that means some >> > features can't be tested in QEMU-as-virtual-platform and only in >> > QEMU-faithfully-emulating-specific-physical-platforms. >> >> You mention QEMU (for ARM and RISC-V) and now XEN. They are a special >> case, I think. How about we create a special Kconfig for that case? We >> need to make some progress here. >> >> > >> > > > I guess another part of the problem is that historically almost all >> > > > platforms were in the first case I list above, no run time provided >> > > > device tree, so we took the kernel one and added our bindings to it. >> > > > Now we're being bit by the growing number of platforms that are the >> > > > second case, and how do we get our properties in there, and which ones >> > > > even make sense to do that for. >> > > >> > > I think upstreaming the bindings is the solution there. I've made a >> > > start, but we need to make progress with this series and all the other >> > > things in flight. I think a lot of people want U-Boot to not have a >> > > devicetree source files in it for ARMv8 platforms. I am strongly >> > > opposed to that. I've laid out my reasons very clearly in the past. I >> > > think this is a good summary: >> > > >> > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html >> > >> > Yes, there are some ARMv8 platforms we will have to have the source >> > files to, in tree, because they won't come to us at run time. But >> > others we won't for practical reasons, namely that we can't statically >> > provide something that exists dynamically without massive duplication of >> > code or just taking things from that passed to us tree. >> >> So let's require that the static ones have the Linux DT in our tree >> for now. The dynamic ones are just QEMU for ARM and Xen, I think. If >> that's it then I can agree a special case for them, so long as we sort >> out the docs for Xen. >> >> > >> > > I believe I have been consistent in this although with all the >> > > discussion I'm really not sure anymore. >> > >> > Yes, everyone has been consistent in these discussions. >> >> I'd like to think more people accept that U-Boot is allowed its own >> properties than did at the start. > > there is no question that U-Boot can have its properties specified in Device Tree. I am pretty sure you were on the other side of that fence at some point. I know quite a few others that still are. > What we may not agree in is how those properties make it to U-Boot. Yes but that is just the next step along in my progression in that email ('why can't we just...' to 'this is how U-Boot works'). From memory there are 3 more steps. >> >> >> >> > >> > > The problem is that various people have various views about how U-Boot >> > > should work with devicetree. I strongly believe that until we have >> > > bindings upstream, a central repo for DTs with easy downloading for >> > > builds, automated validation, among other things, we must maintain the >> > > devicetree in U-Boot. Just from the POV of energy expended, I do not >> > > want to be arguing with the Linaro folks about what U-Boot is allowed >> > > to do every month for the next two years. I'd rather set out the stall >> > > now and then deal with the problems it causes from that perspective. >> > >> > The problems of the last going on 12 years won't be solved instantly. >> > The conflict as I see it is that you're insisting that all platforms >> > must have statically usable device trees, and I (and I believe others) >> > are saying that's unreasonable in cases where the trees are dynamic at >> > heart, lets just ensure we have good enough documentation for them, >> > which we don't today. >> > >> > To be clear and pick an example, I don't want Pi dts files in U-Boot, >> > but, OK, it's an easy enough case to sync them up and so long as we >> > aren't yet at the "now we pick at run time between compiled in or passed >> > to us dtb", I can accept them in tree, but not in the resulting binary >> > for OF_CONTROL=y. But as the Xen folks have also noted, there's no >> > reasonable tree to include there. It does need to be better documented >> > how to fire it up however, in our sources. >> >> I'm OK with us copying in the Linux devicetree and using that. But >> OF_BOARD must be a run-time option and able to be disabled. The >> devicetree must be built, so it is actually real. We can have a >> separate OF_OMIT or something like that to omit the devicetree from >> the output image, perhaps. >> >> All of the other things need to wait until we make progress with >> devicetree bindings, validation, >> >> How can we make progress on this? We have different goals, as I have >> explained, so we are not going to agree on everything. > > A V7 with empty device trees (except with comments to explain why they are empty and how to force one for dev purposes) for platforms that provide U-Boot with DT (RPI, Qemu, xen…) seem a good base unless someone can propose a better way forward. If we build consensus on the feature aspect of the patch set I will be able to dedicate some time on the documentation part as I thought it was useless to check those until we agree on the functional part. That's the status quo, so it doesn't resolve any of my concerns, sorry. I suggest: - Check in all the DTs we can get (e.g. from Linux), and build them - Use an empty one if we cannot find it, and ask the maintainer to add docs and deal with it - For QEMU arm and QEMU RISC-V (i.e. the 'virt' case), use a base one that works with the base QEMU config We then have the follow-ons that Tom and I have discussed, e.g. the Kconfig option that Mark mentioned. That will clear up all the confusion and provide a baseline for how DT is dealt with in U-Boot. We should then continue on the path towards upstreaming bindings, syncing DT with Linux, validation, removing them from U-Boot if we can automatically download them all from somewhere, etc. The thing is, I think people are more aligned on the eventual goal than on this series. My concern is that without this series, it will continue to be crazy-town and no one will be able to find anything without manual effort. For those of us who deal with more than one platform, this is an important point. Regards, Simon
On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote: > Hi Tom, > > On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote: > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > [huge snip] > > > > There's things that need to be cleaned up because we have some small > > > > number of platforms that went off and did their own thing. But largely > > > > yes, things make sense to me. We have: > > > > - We embedded the device tree that will configure U-Boot, because there > > > > is no way for the hardware to have provided us one. > > > > - We do not embed the device tree that will configure U-Boot, because > > > > there is already one present in memory for us to use. > > > > > > > > Then we have the developer option of: > > > > - We embedded the device tree that will configure U-Boot, because we're > > > > developing something. > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice. > > > > But it's not possible. That's the problem we keep going around and > > around about. People keep raising real life examples where you cannot > > make a run time choice between "device tree we're passed at run time" > > and "device tree we're compiled with". > > I haven't seen one. The most extreme case is QEMU and it works fine. I > even added a test with it. What am I missing? QEMU and Xen should both never have an in-source-tree dts as they are dynamic. I think you missed the explanation about how U-Boot + Xen works? You're running the same U-Boot under Xen on any arbitrary ARMv8 (with required features...) system. For QEMU virtual machines you're not supposed to do what you're doing, for production. > > And it's not helpful. It is ALWAYS the case that we know that we want > > to override the run time device tree with our own, because it's a > > developer developing things or it's a user / production case where we > > must use the provided tree. NOT doing that is what leads to madness > > like we see for example on Pi where if we don't use the passed tree we > > still need to copy X/Y/Z out of it. > > Aren't you talking about the distro DT there, rather than the the one > on the boot disk? That is my reading of that patch. If we need to do > that sort of thing, it doesn't matter where the the cointrol DT comes > from. You are still going to have to do that sort of thing. > > It is not ALWAYS the case. I've shown you how easy it is to disable > OF_BOARD and still boot / iterate. The DT we're passed in is the DT to pass to the OS. That's the hook for putting a DTB on the device as it ships, the OS will just work. The production case of needing to update that stored DTB is handled. It's always what should be used, again outside of developer doing development. Maybe that's part of the confusion here too. The DTB U-Boot is using is the DTB the OS will consume too, in the passed at run time case. Unless we're instead going to save that DTB aside? Which leaves me with a different set of design questions... > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > device tree in the binary. There's a growing set of devices where the > > > > device tree exists with the device. If it's missing, that's a huge > > > > fatal error we can't do all that much about. If we need to do something > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > forward for the developer to do that. But that's not the common case! > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > I just want to make sure that we always build the devicetrees and that > > > it is easy for a knowledgeable dev to switch over to use them, without > > > spelunking through dozens of other projects to discover the secret DT > > > that no one will tell us about. > > > > Should we demand better documentation for boards? Yes. But it's still > > a valid case to have zero device trees for a given platform in-tree. > > Xen is an example of this. QEMU is an example of this. Platforms need > > to work without adding special tweaks for us. Maybe that means some > > features can't be tested in QEMU-as-virtual-platform and only in > > QEMU-faithfully-emulating-specific-physical-platforms. > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > case, I think. How about we create a special Kconfig for that case? We > need to make some progress here. Yes, because there's a small number of OF_BOARD=y configs in tree right now, most of which are QEMU virtual machines, others of which are Pi (which we've talked to death), highbank (which Andre has explained), and then the octeontx stuff I don't know how works. I keep pushing to say that OF_BOARD=y is the special case we need to not overrule the device tree provided to us on. Unless we start saving off that passed-to-us DTB and then something-something for our own run-time DTB, and letting the OS consume that passed-to-us one with only normal fixups applied. > > > > I guess another part of the problem is that historically almost all > > > > platforms were in the first case I list above, no run time provided > > > > device tree, so we took the kernel one and added our bindings to it. > > > > Now we're being bit by the growing number of platforms that are the > > > > second case, and how do we get our properties in there, and which ones > > > > even make sense to do that for. > > > > > > I think upstreaming the bindings is the solution there. I've made a > > > start, but we need to make progress with this series and all the other > > > things in flight. I think a lot of people want U-Boot to not have a > > > devicetree source files in it for ARMv8 platforms. I am strongly > > > opposed to that. I've laid out my reasons very clearly in the past. I > > > think this is a good summary: > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > > > > Yes, there are some ARMv8 platforms we will have to have the source > > files to, in tree, because they won't come to us at run time. But > > others we won't for practical reasons, namely that we can't statically > > provide something that exists dynamically without massive duplication of > > code or just taking things from that passed to us tree. > > So let's require that the static ones have the Linux DT in our tree > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If > that's it then I can agree a special case for them, so long as we sort > out the docs for Xen. I'm agreeable to saying that if the dts files exist in Linux (or other official source locations) we should have those in-tree, and the board maintainer doesn't object, yes. But I think that might be a slightly different list than what you say here. And that punts the run-time decision down the road. And I'm assuming you're OK with also not including a dtb in the image. > > > I believe I have been consistent in this although with all the > > > discussion I'm really not sure anymore. > > > > Yes, everyone has been consistent in these discussions. > > I'd like to think more people accept that U-Boot is allowed its own > properties than did at the start. > > > > > > The problem is that various people have various views about how U-Boot > > > should work with devicetree. I strongly believe that until we have > > > bindings upstream, a central repo for DTs with easy downloading for > > > builds, automated validation, among other things, we must maintain the > > > devicetree in U-Boot. Just from the POV of energy expended, I do not > > > want to be arguing with the Linaro folks about what U-Boot is allowed > > > to do every month for the next two years. I'd rather set out the stall > > > now and then deal with the problems it causes from that perspective. > > > > The problems of the last going on 12 years won't be solved instantly. > > The conflict as I see it is that you're insisting that all platforms > > must have statically usable device trees, and I (and I believe others) > > are saying that's unreasonable in cases where the trees are dynamic at > > heart, lets just ensure we have good enough documentation for them, > > which we don't today. > > > > To be clear and pick an example, I don't want Pi dts files in U-Boot, > > but, OK, it's an easy enough case to sync them up and so long as we > > aren't yet at the "now we pick at run time between compiled in or passed > > to us dtb", I can accept them in tree, but not in the resulting binary > > for OF_CONTROL=y. But as the Xen folks have also noted, there's no > > reasonable tree to include there. It does need to be better documented > > how to fire it up however, in our sources. > > I'm OK with us copying in the Linux devicetree and using that. But > OF_BOARD must be a run-time option and able to be disabled. The > devicetree must be built, so it is actually real. We can have a > separate OF_OMIT or something like that to omit the devicetree from > the output image, perhaps. You're changing the meaning of CONFIG options. I like the idea Mark suggested (probably after you wrote this..) of introducing something new for what you're talking about. But no, it's unreasonable to say that every U-Boot binary will bundle one or more dtb and make a run time decision about what to use as the normal way the world works. > All of the other things need to wait until we make progress with > devicetree bindings, validation, > > How can we make progress on this? We have different goals, as I have > explained, so we are not going to agree on everything. Replace patches 4 to 14 with syncing platforms dts files from current Linux release, and when OF_BOARD=y don't include a device tree in the resulting image? That might also need adding some documentation for some platforms on where the device tree is and how to extract it.
Hi Simon, On Sat, Dec 04, 2021 at 10:25:29AM -0700, Simon Glass wrote: > Hi Ilias, > > On Sat, 4 Dec 2021 at 08:58, Ilias Apalodimas > <ilias.apalodimas@linaro.org> wrote: > > > > Hi Simon, > > > > [...] > > > > [huge snip] > > > > > > There's things that need to be cleaned up because we have some small > > > > > > number of platforms that went off and did their own thing. But largely > > > > > > yes, things make sense to me. We have: > > > > > > - We embedded the device tree that will configure U-Boot, because there > > > > > > is no way for the hardware to have provided us one. > > > > > > - We do not embed the device tree that will configure U-Boot, because > > > > > > there is already one present in memory for us to use. > > > > > > > > > > > > Then we have the developer option of: > > > > > > - We embedded the device tree that will configure U-Boot, because we're > > > > > > developing something. > > > > > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice. > > > > > > > > I am not convinced the case is "we are developing something". The > > arguments for this are something along the lines of: > > 1. U-Boot will fail to compile if OF_SEPARATE is selected and you provide > > no DT so we need to include it. With which I disagree. The config option > > says "You must provide an external device tree" for a reason. > > Where are you reading that? I'm lost. In the XEN patch commit message [1] > > OF_SEPARATE means it is not embedded in U-Boot but is attached to the end of it. > > > 2. The DT's are hard to find. The 'hard to find' RPI DTs are in fact > > committed in the kernel. I am not sure about the rest, but honestly this > > isn't a convincing argument for me. > > Great, so you've solved that one but even that was confusing for me, > as my patch should make clear. Every single board would be its own > special snowflake if we went that way. > > So if they are in the kernel, we just need to put them in U-Boot too, > so problem solved. The auto-sync thing that I believe Rob is working > on will make things easy. My problem is not usable DTs like the PRI4. My problem is the OF_BOARD being a runtime option and always building that DT, while at the same time introduce a third option to not include it in the binary. Another problem is 'empty' DTs. > > > > > What else are we gaining with it being a run time choice? One of the > > We are requiring a DT to be present in the U-Boot tree for > development, documentation and discoverability purposes. Devs can turn > OF_BOARD on and off as it suits them when iterating on a platform. They can also do the same thing without tangling the 2 options. The *real* problem is that in a month from now we'll get a patch saying "I need to change X on RPI4 DTB because I have this special reason and I want a specific u-boot binding" and then we are back at the start. We also have OF_EMBED for the 'developer' option which is also mentioned explicitly in the Kconfig. > > > things this approach does address, but we keep conveniently ignoring, is > > that it tries to preserve the current status quo. You can go and add the > > special missing U-Boot nodes in those DT's. So that would bypass problems > > if the bindings get NAK'ed. But this is going to work against the > > fragmentation we are trying to resolve. > > Well that's another reason why we need in-tree DTs at the moment. That > reason goes away once we have our bindings upstream and are able to do > what we need with DT there. > Again, that's a huge if. I am honestly not saying this in bad faith, but I have my concerns on if and what gets upstreamed. So what this really does in my head is preserve the current functionality. So what I am trying to avoid here is, in case the bindings get NAK'ed, we go back and say "that's fine we got this covered, look it's in docs and commit messages!" > > > > > > But it's not possible. That's the problem we keep going around and > > > > around about. People keep raising real life examples where you cannot > > > > make a run time choice between "device tree we're passed at run time" > > > > and "device tree we're compiled with". > > > > > > I haven't seen one. The most extreme case is QEMU and it works fine. I > > > even added a test with it. What am I missing? > > (I think my point there is made) > > > > > IMHO 3b595da441cf is the commit that started the problem and tangled those > > 2 options. Note that this support has been removed from the dragonboard > > later in 0204d1b56b2f .... > > Yes it is one of them. There may be cases where we want to patch up > the DT that U-Boot builds. In fact OF_BOARD does not mean it came from > a prior stage. All sorts of things could be going on. We should not > conflate building a DT with OF_BOARD. It says 'board specific way'. To means that means we either create it on the fly or inherit it. In the case you want to fixup the DTB provided by OF_SEPARATE, there are _weak platform functions to patch that up. You don't really need OF_BOARD for that, you can do that fine with OF_SEPARATE and check fdtdec_board_setup(). > > > > > > > > > > > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > > > to override the run time device tree with our own, because it's a > > > > developer developing things or it's a user / production case where we > > > > must use the provided tree. NOT doing that is what leads to madness > > > > like we see for example on Pi where if we don't use the passed tree we > > > > still need to copy X/Y/Z out of it. > > > > > > Aren't you talking about the distro DT there, rather than the the one > > > on the boot disk? That is my reading of that patch. If we need to do > > > that sort of thing, it doesn't matter where the the cointrol DT comes > > > from. You are still going to have to do that sort of thing. > > > > > > It is not ALWAYS the case. I've shown you how easy it is to disable > > > OF_BOARD and still boot / iterate. > > > > > > > > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > > > device tree in the binary. There's a growing set of devices where the > > > > > > device tree exists with the device. If it's missing, that's a huge > > > > > > fatal error we can't do all that much about. If we need to do something > > > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > > > forward for the developer to do that. But that's not the common case! > > > > > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > > > > > I just want to make sure that we always build the devicetrees and that > > > > > it is easy for a knowledgeable dev to switch over to use them, without > > > > > spelunking through dozens of other projects to discover the secret DT > > > > > that no one will tell us about. > > > > So the translation of this for me is: > > We have 2 discrete options (that can be cleaned up further) which choose > > either to embed or receive the DTB. Let's tangle them and introduce a > > *new* third option to separate them if someone needs to. Which makes no > > sense to me. > > Embed is confusing because OF_EMBED means to link it into U-Boot (just > used for debugging) > Which as I said, it's what development should use? > I think this is the core of the problem. There are just lots of ideas > about how all of this should work. Please try out the series and see > if you find any problems. Then we can talk about actual issues rather > than things that might happen. I am pretty sure the patches work. I never doubted that. What I don't love is the architecture and the way it entangles the existing options. > > The two options you refer to are OF_SEPARATE and OF_BOARD. We will > perhaps have OF_PASSAGE at some point. We already have OF_EMBED. > > To me, OF_BOARD and OF_PASSAGE are run-time things because they > indicate what we expect to happen at runtime. If something goes wrong, > we might still be able to print an error message, if we have a backup > DT. I don't see a point saving a developer from a mistake. I'd much rather crash as loudly as possible to indicate "HEY YOU MESSED UP", instead of hiding a problem he might miss under the mat. Maybe I am missing something, but OF_PASSAGE seems superfluous to me. OF_SEPARATE and OF_BOARD cover all the cases I can think of. > > But OF_BOARD and OF_PASSAGE are not related to the build itself. IMO > OF_BOARD is underspecified. One day I would like to move towards > defining these cases better, e.g. > > - DT is passed in a register (rpi and apple_m1, stm32mp, RISC-V, qemu > RISC-V, bcmstb, Octeon, Xen) > - DT is at a fixed address (qemu, highbank, socrates, qemu ppc) > - DT is in a file (sandbox) Again I might be missing something but to me: 1. OF_SEPARATE = provided by u-boot. If someone wants to fix that up we got a number of ways already. 2. OF_BOARD providing with magic somehow at runtime (prior loader, constructed at runtime, read from a flash, whatever). 3. OF_EMBED whatever special developer case we want to use it for. > > IMO many of these could all be handled with standard passage, i.e. in > a standard way. > [...] > > Regards, > Simon [1] https://lore.kernel.org/u-boot/20211204180318.GV1220664@bill-the-cat/T/#m543a10a4b558ccd540fa425d61106ea515393105 Regards /Ilias
Hi Simon Le sam. 4 déc. 2021 à 18:35, Simon Glass <sjg@chromium.org> a écrit : > Hi François, > > On Sat, 4 Dec 2021 at 09:55, François Ozog <francois.ozog@linaro.org> > wrote: > > > > Hi Simon > > > > Le sam. 4 déc. 2021 à 16:21, Simon Glass <sjg@chromium.org> a écrit : > >> > >> Hi Tom, > >> > >> On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote: > >> > > >> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > >> > > >> > [huge snip] > >> > > > There's things that need to be cleaned up because we have some > small > >> > > > number of platforms that went off and did their own thing. But > largely > >> > > > yes, things make sense to me. We have: > >> > > > - We embedded the device tree that will configure U-Boot, because > there > >> > > > is no way for the hardware to have provided us one. > >> > > > - We do not embed the device tree that will configure U-Boot, > because > >> > > > there is already one present in memory for us to use. > >> > > > > >> > > > Then we have the developer option of: > >> > > > - We embedded the device tree that will configure U-Boot, because > we're > >> > > > developing something. > >> > > > >> > > Yes, agreed those are the cases. To me this needs to be a run-time > choice. > >> > > >> > But it's not possible. That's the problem we keep going around and > >> > around about. People keep raising real life examples where you cannot > >> > make a run time choice between "device tree we're passed at run time" > >> > and "device tree we're compiled with". > >> > >> I haven't seen one. The most extreme case is QEMU and it works fine. I > >> even added a test with it. What am I missing? > >> > >> > > >> > And it's not helpful. It is ALWAYS the case that we know that we want > >> > to override the run time device tree with our own, because it's a > >> > developer developing things or it's a user / production case where we > >> > must use the provided tree. NOT doing that is what leads to madness > >> > like we see for example on Pi where if we don't use the passed tree we > >> > still need to copy X/Y/Z out of it. > >> > >> Aren't you talking about the distro DT there, rather than the the one > >> on the boot disk? That is my reading of that patch. If we need to do > >> that sort of thing, it doesn't matter where the the cointrol DT comes > >> from. You are still going to have to do that sort of thing. > >> > >> It is not ALWAYS the case. I've shown you how easy it is to disable > >> OF_BOARD and still boot / iterate. > >> > >> > > >> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we > should > >> > > > > provide a way to do that? But what is driving that desire? > >> > > > > >> > > > I'm looking for ways to convince you that we do not need to > include a > >> > > > device tree in the binary. There's a growing set of devices > where the > >> > > > device tree exists with the device. If it's missing, that's a > huge > >> > > > fatal error we can't do all that much about. If we need to do > something > >> > > > to that device tree for U-Boot, yes, fine, we should make it > straight > >> > > > forward for the developer to do that. But that's not the common > case! > >> > > > >> > > Well we could add another Kconfig which tells U-Boot not to include > a > >> > > devicetree in u-boot.bin, if that would resolve this? > >> > > > >> > > I just want to make sure that we always build the devicetrees and > that > >> > > it is easy for a knowledgeable dev to switch over to use them, > without > >> > > spelunking through dozens of other projects to discover the secret > DT > >> > > that no one will tell us about. > >> > > >> > Should we demand better documentation for boards? Yes. But it's > still > >> > a valid case to have zero device trees for a given platform in-tree. > >> > Xen is an example of this. QEMU is an example of this. Platforms > need > >> > to work without adding special tweaks for us. Maybe that means some > >> > features can't be tested in QEMU-as-virtual-platform and only in > >> > QEMU-faithfully-emulating-specific-physical-platforms. > >> > >> You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > >> case, I think. How about we create a special Kconfig for that case? We > >> need to make some progress here. > >> > >> > > >> > > > I guess another part of the problem is that historically almost > all > >> > > > platforms were in the first case I list above, no run time > provided > >> > > > device tree, so we took the kernel one and added our bindings to > it. > >> > > > Now we're being bit by the growing number of platforms that are > the > >> > > > second case, and how do we get our properties in there, and which > ones > >> > > > even make sense to do that for. > >> > > > >> > > I think upstreaming the bindings is the solution there. I've made a > >> > > start, but we need to make progress with this series and all the > other > >> > > things in flight. I think a lot of people want U-Boot to not have a > >> > > devicetree source files in it for ARMv8 platforms. I am strongly > >> > > opposed to that. I've laid out my reasons very clearly in the past. > I > >> > > think this is a good summary: > >> > > > >> > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > >> > > >> > Yes, there are some ARMv8 platforms we will have to have the source > >> > files to, in tree, because they won't come to us at run time. But > >> > others we won't for practical reasons, namely that we can't statically > >> > provide something that exists dynamically without massive duplication > of > >> > code or just taking things from that passed to us tree. > >> > >> So let's require that the static ones have the Linux DT in our tree > >> for now. The dynamic ones are just QEMU for ARM and Xen, I think. If > >> that's it then I can agree a special case for them, so long as we sort > >> out the docs for Xen. > >> > >> > > >> > > I believe I have been consistent in this although with all the > >> > > discussion I'm really not sure anymore. > >> > > >> > Yes, everyone has been consistent in these discussions. > >> > >> I'd like to think more people accept that U-Boot is allowed its own > >> properties than did at the start. > > > > there is no question that U-Boot can have its properties specified in > Device Tree. > > I am pretty sure you were on the other side of that fence at some > point. I know quite a few others that still are. > > > What we may not agree in is how those properties make it to U-Boot. > > Yes but that is just the next step along in my progression in that > email ('why can't we just...' to 'this is how U-Boot works'). From > memory there are 3 more steps. > > >> > >> > >> > >> > > >> > > The problem is that various people have various views about how > U-Boot > >> > > should work with devicetree. I strongly believe that until we have > >> > > bindings upstream, a central repo for DTs with easy downloading for > >> > > builds, automated validation, among other things, we must maintain > the > >> > > devicetree in U-Boot. Just from the POV of energy expended, I do not > >> > > want to be arguing with the Linaro folks about what U-Boot is > allowed > >> > > to do every month for the next two years. I'd rather set out the > stall > >> > > now and then deal with the problems it causes from that perspective. > >> > > >> > The problems of the last going on 12 years won't be solved instantly. > >> > The conflict as I see it is that you're insisting that all platforms > >> > must have statically usable device trees, and I (and I believe others) > >> > are saying that's unreasonable in cases where the trees are dynamic at > >> > heart, lets just ensure we have good enough documentation for them, > >> > which we don't today. > >> > > >> > To be clear and pick an example, I don't want Pi dts files in U-Boot, > >> > but, OK, it's an easy enough case to sync them up and so long as we > >> > aren't yet at the "now we pick at run time between compiled in or > passed > >> > to us dtb", I can accept them in tree, but not in the resulting binary > >> > for OF_CONTROL=y. But as the Xen folks have also noted, there's no > >> > reasonable tree to include there. It does need to be better > documented > >> > how to fire it up however, in our sources. > >> > >> I'm OK with us copying in the Linux devicetree and using that. But > >> OF_BOARD must be a run-time option and able to be disabled. The > >> devicetree must be built, so it is actually real. We can have a > >> separate OF_OMIT or something like that to omit the devicetree from > >> the output image, perhaps. > >> > >> All of the other things need to wait until we make progress with > >> devicetree bindings, validation, > >> > >> How can we make progress on this? We have different goals, as I have > >> explained, so we are not going to agree on everything. > > > > A V7 with empty device trees (except with comments to explain why they > are empty and how to force one for dev purposes) for platforms that provide > U-Boot with DT (RPI, Qemu, xen…) seem a good base unless someone can > propose a better way forward. If we build consensus on the feature aspect > of the patch set I will be able to dedicate some time on the documentation > part as I thought it was useless to check those until we agree on the > functional part. > > That's the status quo, so it doesn't resolve any of my concerns, > sorry. I suggest: > You make progress on various front that can get consensus in a number of your patches, so it it not status quo. > > - Check in all the DTs we can get (e.g. from Linux), and build them doesn’t change anytime. RPI4 DT in the kernel is not be used anyways. > > - Use an empty one if we cannot find it, and ask the maintainer to add > docs and deal with it > - For QEMU arm and QEMU RISC-V (i.e. the 'virt' case), use a base one > that works with the base QEMU config > > We then have the follow-ons that Tom and I have discussed, e.g. the > Kconfig option that Mark mentioned. > > That will clear up all the confusion and provide a baseline for how DT > is dealt with in U-Boot. > > We should then continue on the path towards upstreaming bindings, > syncing DT with Linux, validation, removing them from U-Boot if we can > automatically download them all from somewhere, etc. > > The thing is, I think people are more aligned on the eventual goal > than on this series. I’d interested to know that. Should we ask +1, -1, -2 for the patches? > My concern is that without this series, it will > continue to be crazy-town and no one will be able to find anything > without manual effort. For those of us who deal with more than one > platform, this is an important point. > > Regards, > Simon >
Hi Tom, On Sat, 4 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > > > [huge snip] > > > > > There's things that need to be cleaned up because we have some small > > > > > number of platforms that went off and did their own thing. But largely > > > > > yes, things make sense to me. We have: > > > > > - We embedded the device tree that will configure U-Boot, because there > > > > > is no way for the hardware to have provided us one. > > > > > - We do not embed the device tree that will configure U-Boot, because > > > > > there is already one present in memory for us to use. > > > > > > > > > > Then we have the developer option of: > > > > > - We embedded the device tree that will configure U-Boot, because we're > > > > > developing something. > > > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice. > > > > > > But it's not possible. That's the problem we keep going around and > > > around about. People keep raising real life examples where you cannot > > > make a run time choice between "device tree we're passed at run time" > > > and "device tree we're compiled with". > > > > I haven't seen one. The most extreme case is QEMU and it works fine. I > > even added a test with it. What am I missing? > > QEMU and Xen should both never have an in-source-tree dts as they are > dynamic. I think you missed the explanation about how U-Boot + Xen > works? You're running the same U-Boot under Xen on any arbitrary ARMv8 > (with required features...) system. For QEMU virtual machines you're > not supposed to do what you're doing, for production. > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > > to override the run time device tree with our own, because it's a > > > developer developing things or it's a user / production case where we > > > must use the provided tree. NOT doing that is what leads to madness > > > like we see for example on Pi where if we don't use the passed tree we > > > still need to copy X/Y/Z out of it. > > > > Aren't you talking about the distro DT there, rather than the the one > > on the boot disk? That is my reading of that patch. If we need to do > > that sort of thing, it doesn't matter where the the cointrol DT comes > > from. You are still going to have to do that sort of thing. > > > > It is not ALWAYS the case. I've shown you how easy it is to disable > > OF_BOARD and still boot / iterate. > > The DT we're passed in is the DT to pass to the OS. That's the hook for > putting a DTB on the device as it ships, the OS will just work. The > production case of needing to update that stored DTB is handled. It's > always what should be used, again outside of developer doing > development. > > Maybe that's part of the confusion here too. The DTB U-Boot is using is > the DTB the OS will consume too, in the passed at run time case. Unless > we're instead going to save that DTB aside? Which leaves me with a > different set of design questions... > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > > device tree in the binary. There's a growing set of devices where the > > > > > device tree exists with the device. If it's missing, that's a huge > > > > > fatal error we can't do all that much about. If we need to do something > > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > > forward for the developer to do that. But that's not the common case! > > > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > > > I just want to make sure that we always build the devicetrees and that > > > > it is easy for a knowledgeable dev to switch over to use them, without > > > > spelunking through dozens of other projects to discover the secret DT > > > > that no one will tell us about. > > > > > > Should we demand better documentation for boards? Yes. But it's still > > > a valid case to have zero device trees for a given platform in-tree. > > > Xen is an example of this. QEMU is an example of this. Platforms need > > > to work without adding special tweaks for us. Maybe that means some > > > features can't be tested in QEMU-as-virtual-platform and only in > > > QEMU-faithfully-emulating-specific-physical-platforms. > > > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > > case, I think. How about we create a special Kconfig for that case? We > > need to make some progress here. > > Yes, because there's a small number of OF_BOARD=y configs in tree right > now, most of which are QEMU virtual machines, others of which are Pi > (which we've talked to death), highbank (which Andre has explained), and > then the octeontx stuff I don't know how works. I keep pushing to say > that OF_BOARD=y is the special case we need to not overrule the device > tree provided to us on. Unless we start saving off that passed-to-us DTB > and then something-something for our own run-time DTB, and letting the > OS consume that passed-to-us one with only normal fixups applied. > > > > > > I guess another part of the problem is that historically almost all > > > > > platforms were in the first case I list above, no run time provided > > > > > device tree, so we took the kernel one and added our bindings to it. > > > > > Now we're being bit by the growing number of platforms that are the > > > > > second case, and how do we get our properties in there, and which ones > > > > > even make sense to do that for. > > > > > > > > I think upstreaming the bindings is the solution there. I've made a > > > > start, but we need to make progress with this series and all the other > > > > things in flight. I think a lot of people want U-Boot to not have a > > > > devicetree source files in it for ARMv8 platforms. I am strongly > > > > opposed to that. I've laid out my reasons very clearly in the past. I > > > > think this is a good summary: > > > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > > > > > > Yes, there are some ARMv8 platforms we will have to have the source > > > files to, in tree, because they won't come to us at run time. But > > > others we won't for practical reasons, namely that we can't statically > > > provide something that exists dynamically without massive duplication of > > > code or just taking things from that passed to us tree. > > > > So let's require that the static ones have the Linux DT in our tree > > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If > > that's it then I can agree a special case for them, so long as we sort > > out the docs for Xen. > > I'm agreeable to saying that if the dts files exist in Linux (or other > official source locations) we should have those in-tree, and the board > maintainer doesn't object, yes. But I think that might be a slightly > different list than what you say here. And that punts the run-time > decision down the road. And I'm assuming you're OK with also not > including a dtb in the image. > > > > > I believe I have been consistent in this although with all the > > > > discussion I'm really not sure anymore. > > > > > > Yes, everyone has been consistent in these discussions. > > > > I'd like to think more people accept that U-Boot is allowed its own > > properties than did at the start. > > > > > > > > > The problem is that various people have various views about how U-Boot > > > > should work with devicetree. I strongly believe that until we have > > > > bindings upstream, a central repo for DTs with easy downloading for > > > > builds, automated validation, among other things, we must maintain the > > > > devicetree in U-Boot. Just from the POV of energy expended, I do not > > > > want to be arguing with the Linaro folks about what U-Boot is allowed > > > > to do every month for the next two years. I'd rather set out the stall > > > > now and then deal with the problems it causes from that perspective. > > > > > > The problems of the last going on 12 years won't be solved instantly. > > > The conflict as I see it is that you're insisting that all platforms > > > must have statically usable device trees, and I (and I believe others) > > > are saying that's unreasonable in cases where the trees are dynamic at > > > heart, lets just ensure we have good enough documentation for them, > > > which we don't today. > > > > > > To be clear and pick an example, I don't want Pi dts files in U-Boot, > > > but, OK, it's an easy enough case to sync them up and so long as we > > > aren't yet at the "now we pick at run time between compiled in or passed > > > to us dtb", I can accept them in tree, but not in the resulting binary > > > for OF_CONTROL=y. But as the Xen folks have also noted, there's no > > > reasonable tree to include there. It does need to be better documented > > > how to fire it up however, in our sources. > > > > I'm OK with us copying in the Linux devicetree and using that. But > > OF_BOARD must be a run-time option and able to be disabled. The > > devicetree must be built, so it is actually real. We can have a > > separate OF_OMIT or something like that to omit the devicetree from > > the output image, perhaps. > > You're changing the meaning of CONFIG options. I like the idea Mark > suggested (probably after you wrote this..) of introducing something new > for what you're talking about. But no, it's unreasonable to say that > every U-Boot binary will bundle one or more dtb and make a run time > decision about what to use as the normal way the world works. > > > All of the other things need to wait until we make progress with > > devicetree bindings, validation, > > > > How can we make progress on this? We have different goals, as I have > > explained, so we are not going to agree on everything. > > Replace patches 4 to 14 with syncing platforms dts files from current > Linux release, and when OF_BOARD=y don't include a device tree in the > resulting image? That might also need adding some documentation for > some platforms on where the device tree is and how to extract it. How about we create a new option for that, as we discussed on IRC a while back? After all, sandbox uses OF_BOARD. It doesn't mean OF_PRIOR_STAGE, just that we call board_fdt_blob_setup(). So something like OF_OMIT_DTB? For U-Boot as a whole this is an uncommon case. We also need to think about the protections again, perhaps we define OF_HAS_PRIOR_STAGE to indicate that the board works this way, then make it hard to disable OF_BOARD if that is set. Regards, Simon
On Sat, Dec 04, 2021 at 03:09:59PM -0700, Simon Glass wrote: > Hi Tom, > > On Sat, 4 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > > > > > [huge snip] > > > > > > There's things that need to be cleaned up because we have some small > > > > > > number of platforms that went off and did their own thing. But largely > > > > > > yes, things make sense to me. We have: > > > > > > - We embedded the device tree that will configure U-Boot, because there > > > > > > is no way for the hardware to have provided us one. > > > > > > - We do not embed the device tree that will configure U-Boot, because > > > > > > there is already one present in memory for us to use. > > > > > > > > > > > > Then we have the developer option of: > > > > > > - We embedded the device tree that will configure U-Boot, because we're > > > > > > developing something. > > > > > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice. > > > > > > > > But it's not possible. That's the problem we keep going around and > > > > around about. People keep raising real life examples where you cannot > > > > make a run time choice between "device tree we're passed at run time" > > > > and "device tree we're compiled with". > > > > > > I haven't seen one. The most extreme case is QEMU and it works fine. I > > > even added a test with it. What am I missing? > > > > QEMU and Xen should both never have an in-source-tree dts as they are > > dynamic. I think you missed the explanation about how U-Boot + Xen > > works? You're running the same U-Boot under Xen on any arbitrary ARMv8 > > (with required features...) system. For QEMU virtual machines you're > > not supposed to do what you're doing, for production. > > > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > > > to override the run time device tree with our own, because it's a > > > > developer developing things or it's a user / production case where we > > > > must use the provided tree. NOT doing that is what leads to madness > > > > like we see for example on Pi where if we don't use the passed tree we > > > > still need to copy X/Y/Z out of it. > > > > > > Aren't you talking about the distro DT there, rather than the the one > > > on the boot disk? That is my reading of that patch. If we need to do > > > that sort of thing, it doesn't matter where the the cointrol DT comes > > > from. You are still going to have to do that sort of thing. > > > > > > It is not ALWAYS the case. I've shown you how easy it is to disable > > > OF_BOARD and still boot / iterate. > > > > The DT we're passed in is the DT to pass to the OS. That's the hook for > > putting a DTB on the device as it ships, the OS will just work. The > > production case of needing to update that stored DTB is handled. It's > > always what should be used, again outside of developer doing > > development. > > > > Maybe that's part of the confusion here too. The DTB U-Boot is using is > > the DTB the OS will consume too, in the passed at run time case. Unless > > we're instead going to save that DTB aside? Which leaves me with a > > different set of design questions... > > > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > > > device tree in the binary. There's a growing set of devices where the > > > > > > device tree exists with the device. If it's missing, that's a huge > > > > > > fatal error we can't do all that much about. If we need to do something > > > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > > > forward for the developer to do that. But that's not the common case! > > > > > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > > > > > I just want to make sure that we always build the devicetrees and that > > > > > it is easy for a knowledgeable dev to switch over to use them, without > > > > > spelunking through dozens of other projects to discover the secret DT > > > > > that no one will tell us about. > > > > > > > > Should we demand better documentation for boards? Yes. But it's still > > > > a valid case to have zero device trees for a given platform in-tree. > > > > Xen is an example of this. QEMU is an example of this. Platforms need > > > > to work without adding special tweaks for us. Maybe that means some > > > > features can't be tested in QEMU-as-virtual-platform and only in > > > > QEMU-faithfully-emulating-specific-physical-platforms. > > > > > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > > > case, I think. How about we create a special Kconfig for that case? We > > > need to make some progress here. > > > > Yes, because there's a small number of OF_BOARD=y configs in tree right > > now, most of which are QEMU virtual machines, others of which are Pi > > (which we've talked to death), highbank (which Andre has explained), and > > then the octeontx stuff I don't know how works. I keep pushing to say > > that OF_BOARD=y is the special case we need to not overrule the device > > tree provided to us on. Unless we start saving off that passed-to-us DTB > > and then something-something for our own run-time DTB, and letting the > > OS consume that passed-to-us one with only normal fixups applied. > > > > > > > > I guess another part of the problem is that historically almost all > > > > > > platforms were in the first case I list above, no run time provided > > > > > > device tree, so we took the kernel one and added our bindings to it. > > > > > > Now we're being bit by the growing number of platforms that are the > > > > > > second case, and how do we get our properties in there, and which ones > > > > > > even make sense to do that for. > > > > > > > > > > I think upstreaming the bindings is the solution there. I've made a > > > > > start, but we need to make progress with this series and all the other > > > > > things in flight. I think a lot of people want U-Boot to not have a > > > > > devicetree source files in it for ARMv8 platforms. I am strongly > > > > > opposed to that. I've laid out my reasons very clearly in the past. I > > > > > think this is a good summary: > > > > > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > > > > > > > > Yes, there are some ARMv8 platforms we will have to have the source > > > > files to, in tree, because they won't come to us at run time. But > > > > others we won't for practical reasons, namely that we can't statically > > > > provide something that exists dynamically without massive duplication of > > > > code or just taking things from that passed to us tree. > > > > > > So let's require that the static ones have the Linux DT in our tree > > > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If > > > that's it then I can agree a special case for them, so long as we sort > > > out the docs for Xen. > > > > I'm agreeable to saying that if the dts files exist in Linux (or other > > official source locations) we should have those in-tree, and the board > > maintainer doesn't object, yes. But I think that might be a slightly > > different list than what you say here. And that punts the run-time > > decision down the road. And I'm assuming you're OK with also not > > including a dtb in the image. > > > > > > > I believe I have been consistent in this although with all the > > > > > discussion I'm really not sure anymore. > > > > > > > > Yes, everyone has been consistent in these discussions. > > > > > > I'd like to think more people accept that U-Boot is allowed its own > > > properties than did at the start. > > > > > > > > > > > > The problem is that various people have various views about how U-Boot > > > > > should work with devicetree. I strongly believe that until we have > > > > > bindings upstream, a central repo for DTs with easy downloading for > > > > > builds, automated validation, among other things, we must maintain the > > > > > devicetree in U-Boot. Just from the POV of energy expended, I do not > > > > > want to be arguing with the Linaro folks about what U-Boot is allowed > > > > > to do every month for the next two years. I'd rather set out the stall > > > > > now and then deal with the problems it causes from that perspective. > > > > > > > > The problems of the last going on 12 years won't be solved instantly. > > > > The conflict as I see it is that you're insisting that all platforms > > > > must have statically usable device trees, and I (and I believe others) > > > > are saying that's unreasonable in cases where the trees are dynamic at > > > > heart, lets just ensure we have good enough documentation for them, > > > > which we don't today. > > > > > > > > To be clear and pick an example, I don't want Pi dts files in U-Boot, > > > > but, OK, it's an easy enough case to sync them up and so long as we > > > > aren't yet at the "now we pick at run time between compiled in or passed > > > > to us dtb", I can accept them in tree, but not in the resulting binary > > > > for OF_CONTROL=y. But as the Xen folks have also noted, there's no > > > > reasonable tree to include there. It does need to be better documented > > > > how to fire it up however, in our sources. > > > > > > I'm OK with us copying in the Linux devicetree and using that. But > > > OF_BOARD must be a run-time option and able to be disabled. The > > > devicetree must be built, so it is actually real. We can have a > > > separate OF_OMIT or something like that to omit the devicetree from > > > the output image, perhaps. > > > > You're changing the meaning of CONFIG options. I like the idea Mark > > suggested (probably after you wrote this..) of introducing something new > > for what you're talking about. But no, it's unreasonable to say that > > every U-Boot binary will bundle one or more dtb and make a run time > > decision about what to use as the normal way the world works. > > > > > All of the other things need to wait until we make progress with > > > devicetree bindings, validation, > > > > > > How can we make progress on this? We have different goals, as I have > > > explained, so we are not going to agree on everything. > > > > Replace patches 4 to 14 with syncing platforms dts files from current > > Linux release, and when OF_BOARD=y don't include a device tree in the > > resulting image? That might also need adding some documentation for > > some platforms on where the device tree is and how to extract it. > > How about we create a new option for that, as we discussed on IRC a > while back? After all, sandbox uses OF_BOARD. It doesn't mean > OF_PRIOR_STAGE, just that we call board_fdt_blob_setup(). > > So something like OF_OMIT_DTB? For U-Boot as a whole this is an uncommon case. > > We also need to think about the protections again, perhaps we define > OF_HAS_PRIOR_STAGE to indicate that the board works this way, then > make it hard to disable OF_BOARD if that is set. I guess my hard sticking point here is I'm still entirely unconvinced that the future step of "now we make run-time choice between built in or provided dtb" makes sense. And I worry the way these CONFIG options keep being presented is setting the ground work for this change that I'm not agreed to conceptually. So, yes, we could add more CONFIG symbols and then maybe even follow up and migrate a few more platforms over to them. I'm unclear why we need more symbols, but, OK, yes, to make progress, lets try it. Sometimes I understand patches better than paragraphs.
On Sat, Dec 04, 2021 at 07:52:46PM +0100, François Ozog wrote: > Hi Simon > > Le sam. 4 déc. 2021 à 18:35, Simon Glass <sjg@chromium.org> a écrit : > > > Hi François, > > > > On Sat, 4 Dec 2021 at 09:55, François Ozog <francois.ozog@linaro.org> > > wrote: > > > > > > Hi Simon > > > > > > Le sam. 4 déc. 2021 à 16:21, Simon Glass <sjg@chromium.org> a écrit : > > >> > > >> Hi Tom, > > >> > > >> On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote: > > >> > > > >> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > >> > > > >> > [huge snip] > > >> > > > There's things that need to be cleaned up because we have some > > small > > >> > > > number of platforms that went off and did their own thing. But > > largely > > >> > > > yes, things make sense to me. We have: > > >> > > > - We embedded the device tree that will configure U-Boot, because > > there > > >> > > > is no way for the hardware to have provided us one. > > >> > > > - We do not embed the device tree that will configure U-Boot, > > because > > >> > > > there is already one present in memory for us to use. > > >> > > > > > >> > > > Then we have the developer option of: > > >> > > > - We embedded the device tree that will configure U-Boot, because > > we're > > >> > > > developing something. > > >> > > > > >> > > Yes, agreed those are the cases. To me this needs to be a run-time > > choice. > > >> > > > >> > But it's not possible. That's the problem we keep going around and > > >> > around about. People keep raising real life examples where you cannot > > >> > make a run time choice between "device tree we're passed at run time" > > >> > and "device tree we're compiled with". > > >> > > >> I haven't seen one. The most extreme case is QEMU and it works fine. I > > >> even added a test with it. What am I missing? > > >> > > >> > > > >> > And it's not helpful. It is ALWAYS the case that we know that we want > > >> > to override the run time device tree with our own, because it's a > > >> > developer developing things or it's a user / production case where we > > >> > must use the provided tree. NOT doing that is what leads to madness > > >> > like we see for example on Pi where if we don't use the passed tree we > > >> > still need to copy X/Y/Z out of it. > > >> > > >> Aren't you talking about the distro DT there, rather than the the one > > >> on the boot disk? That is my reading of that patch. If we need to do > > >> that sort of thing, it doesn't matter where the the cointrol DT comes > > >> from. You are still going to have to do that sort of thing. > > >> > > >> It is not ALWAYS the case. I've shown you how easy it is to disable > > >> OF_BOARD and still boot / iterate. > > >> > > >> > > > >> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we > > should > > >> > > > > provide a way to do that? But what is driving that desire? > > >> > > > > > >> > > > I'm looking for ways to convince you that we do not need to > > include a > > >> > > > device tree in the binary. There's a growing set of devices > > where the > > >> > > > device tree exists with the device. If it's missing, that's a > > huge > > >> > > > fatal error we can't do all that much about. If we need to do > > something > > >> > > > to that device tree for U-Boot, yes, fine, we should make it > > straight > > >> > > > forward for the developer to do that. But that's not the common > > case! > > >> > > > > >> > > Well we could add another Kconfig which tells U-Boot not to include > > a > > >> > > devicetree in u-boot.bin, if that would resolve this? > > >> > > > > >> > > I just want to make sure that we always build the devicetrees and > > that > > >> > > it is easy for a knowledgeable dev to switch over to use them, > > without > > >> > > spelunking through dozens of other projects to discover the secret > > DT > > >> > > that no one will tell us about. > > >> > > > >> > Should we demand better documentation for boards? Yes. But it's > > still > > >> > a valid case to have zero device trees for a given platform in-tree. > > >> > Xen is an example of this. QEMU is an example of this. Platforms > > need > > >> > to work without adding special tweaks for us. Maybe that means some > > >> > features can't be tested in QEMU-as-virtual-platform and only in > > >> > QEMU-faithfully-emulating-specific-physical-platforms. > > >> > > >> You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > > >> case, I think. How about we create a special Kconfig for that case? We > > >> need to make some progress here. > > >> > > >> > > > >> > > > I guess another part of the problem is that historically almost > > all > > >> > > > platforms were in the first case I list above, no run time > > provided > > >> > > > device tree, so we took the kernel one and added our bindings to > > it. > > >> > > > Now we're being bit by the growing number of platforms that are > > the > > >> > > > second case, and how do we get our properties in there, and which > > ones > > >> > > > even make sense to do that for. > > >> > > > > >> > > I think upstreaming the bindings is the solution there. I've made a > > >> > > start, but we need to make progress with this series and all the > > other > > >> > > things in flight. I think a lot of people want U-Boot to not have a > > >> > > devicetree source files in it for ARMv8 platforms. I am strongly > > >> > > opposed to that. I've laid out my reasons very clearly in the past. > > I > > >> > > think this is a good summary: > > >> > > > > >> > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > > >> > > > >> > Yes, there are some ARMv8 platforms we will have to have the source > > >> > files to, in tree, because they won't come to us at run time. But > > >> > others we won't for practical reasons, namely that we can't statically > > >> > provide something that exists dynamically without massive duplication > > of > > >> > code or just taking things from that passed to us tree. > > >> > > >> So let's require that the static ones have the Linux DT in our tree > > >> for now. The dynamic ones are just QEMU for ARM and Xen, I think. If > > >> that's it then I can agree a special case for them, so long as we sort > > >> out the docs for Xen. > > >> > > >> > > > >> > > I believe I have been consistent in this although with all the > > >> > > discussion I'm really not sure anymore. > > >> > > > >> > Yes, everyone has been consistent in these discussions. > > >> > > >> I'd like to think more people accept that U-Boot is allowed its own > > >> properties than did at the start. > > > > > > there is no question that U-Boot can have its properties specified in > > Device Tree. > > > > I am pretty sure you were on the other side of that fence at some > > point. I know quite a few others that still are. > > > > > What we may not agree in is how those properties make it to U-Boot. > > > > Yes but that is just the next step along in my progression in that > > email ('why can't we just...' to 'this is how U-Boot works'). From > > memory there are 3 more steps. > > > > >> > > >> > > >> > > >> > > > >> > > The problem is that various people have various views about how > > U-Boot > > >> > > should work with devicetree. I strongly believe that until we have > > >> > > bindings upstream, a central repo for DTs with easy downloading for > > >> > > builds, automated validation, among other things, we must maintain > > the > > >> > > devicetree in U-Boot. Just from the POV of energy expended, I do not > > >> > > want to be arguing with the Linaro folks about what U-Boot is > > allowed > > >> > > to do every month for the next two years. I'd rather set out the > > stall > > >> > > now and then deal with the problems it causes from that perspective. > > >> > > > >> > The problems of the last going on 12 years won't be solved instantly. > > >> > The conflict as I see it is that you're insisting that all platforms > > >> > must have statically usable device trees, and I (and I believe others) > > >> > are saying that's unreasonable in cases where the trees are dynamic at > > >> > heart, lets just ensure we have good enough documentation for them, > > >> > which we don't today. > > >> > > > >> > To be clear and pick an example, I don't want Pi dts files in U-Boot, > > >> > but, OK, it's an easy enough case to sync them up and so long as we > > >> > aren't yet at the "now we pick at run time between compiled in or > > passed > > >> > to us dtb", I can accept them in tree, but not in the resulting binary > > >> > for OF_CONTROL=y. But as the Xen folks have also noted, there's no > > >> > reasonable tree to include there. It does need to be better > > documented > > >> > how to fire it up however, in our sources. > > >> > > >> I'm OK with us copying in the Linux devicetree and using that. But > > >> OF_BOARD must be a run-time option and able to be disabled. The > > >> devicetree must be built, so it is actually real. We can have a > > >> separate OF_OMIT or something like that to omit the devicetree from > > >> the output image, perhaps. > > >> > > >> All of the other things need to wait until we make progress with > > >> devicetree bindings, validation, > > >> > > >> How can we make progress on this? We have different goals, as I have > > >> explained, so we are not going to agree on everything. > > > > > > A V7 with empty device trees (except with comments to explain why they > > are empty and how to force one for dev purposes) for platforms that provide > > U-Boot with DT (RPI, Qemu, xen…) seem a good base unless someone can > > propose a better way forward. If we build consensus on the feature aspect > > of the patch set I will be able to dedicate some time on the documentation > > part as I thought it was useless to check those until we agree on the > > functional part. > > > > That's the status quo, so it doesn't resolve any of my concerns, > > sorry. I suggest: > > > You make progress on various front that can get consensus in a number of > your patches, so it it not status quo. > > > > > - Check in all the DTs we can get (e.g. from Linux), and build them > > doesn’t change anytime. RPI4 DT in the kernel is not be used anyways. Well, the kernel DTS files for Pi are, and aren't exactly used, yes? The dtbs are built from the kernel, then passed to the Pi firmware and updated based on config.txt and other relevant things, yes?
Hi Heinrich, On Fri, 3 Dec 2021 at 03:04, Heinrich Schuchardt <heinrich.schuchardt@canonical.com> wrote: > > On 12/2/21 17:50, Simon Glass wrote: > > Hi Heinrich, > > > > On Thu, 2 Dec 2021 at 09:47, Heinrich Schuchardt > > <heinrich.schuchardt@canonical.com> wrote: > >> > >> On 12/2/21 16:58, 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 in another patch in this > >>> series: "doc: Add documentation about devicetree usage" > >>> > >>> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > >>> can obtain its devicetree at runtime, even it is has a devicetree built > >>> in U-Boot. This is because U-Boot may be a second-stage bootloader and its > >>> caller may have a better idea about the hardware available in the machine. > >>> This is the case with a few QEMU boards, for example. > >>> > >>> So it makes no sense to have OF_BOARD as a 'choice'. It should be an > >>> option, available with either OF_SEPARATE or OF_EMBED. > >>> > >>> This series makes this change, adding various missing devicetree files > >>> (and placeholders) to make the build work. > >>> > >>> Note: If board maintainers are able to add their own patch to add the > >>> files, some patches in this series can be dropped. > >>> > >>> It also provides a few qemu clean-ups discovered along the way. The > >>> qemu-riscv64_spl problem is fixed. > >> > >> Distros like Ubuntu are provided as preinstalled images using U-Boot to > >> launch Linux for usage with QEMU. A single image must be able to be > >> usable in the future irrespective of the QEMU command line device > >> configuration. > >> > >> This means that the devicetree coming from QEMU must be accurately > >> parsed in U-Boot to setup the UEFI memory map. The number and type of > >> CPUs and the NUMA configuration must be accurate. All devices enabled > >> via the QEMU command line must be visible in the device-tree of Linux. > >> > >> Please, observe that information like number of CPU cores, number and > >> type of block devices, namespace IDs used for NVMe drives, etc. cannot > >> be available at build time. > >> > >> It this all guaranteed with this series? If not, this would > >> unfortunately imply a NAK. > > > > Yes, it is guaranteed and there is no change there. > > Compiling qemu_arm64_defconfig yields dtbdump.efi. I used this to dump > the devicetree exposed to UEFI binaries. The number of CPUs and the > memory size matches the call parameters of QEMU. Emulated devices like > SCSI and NVMe drives and TPMv2 work inside U-Boot. > > I also tested: > > * qemu-riscv64_smode_defconfig as fw_jump payload for OpenSBI > * qemu-riscv64_spl_defconfig > > and found no issues. > > Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canaonical.com> Thank you for testing it. I have added your tag to the three patches for QEMU devicetree (arm/riscv) since I don't have a way to add to the whole series and I'm not sure it applies in any case. Regards, Simon
Hi Tom, On Sun, 5 Dec 2021 at 06:32, Tom Rini <trini@konsulko.com> wrote: > > On Sat, Dec 04, 2021 at 03:09:59PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Sat, 4 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > > > > > > > [huge snip] > > > > > > > There's things that need to be cleaned up because we have some small > > > > > > > number of platforms that went off and did their own thing. But largely > > > > > > > yes, things make sense to me. We have: > > > > > > > - We embedded the device tree that will configure U-Boot, because there > > > > > > > is no way for the hardware to have provided us one. > > > > > > > - We do not embed the device tree that will configure U-Boot, because > > > > > > > there is already one present in memory for us to use. > > > > > > > > > > > > > > Then we have the developer option of: > > > > > > > - We embedded the device tree that will configure U-Boot, because we're > > > > > > > developing something. > > > > > > > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice. > > > > > > > > > > But it's not possible. That's the problem we keep going around and > > > > > around about. People keep raising real life examples where you cannot > > > > > make a run time choice between "device tree we're passed at run time" > > > > > and "device tree we're compiled with". > > > > > > > > I haven't seen one. The most extreme case is QEMU and it works fine. I > > > > even added a test with it. What am I missing? > > > > > > QEMU and Xen should both never have an in-source-tree dts as they are > > > dynamic. I think you missed the explanation about how U-Boot + Xen > > > works? You're running the same U-Boot under Xen on any arbitrary ARMv8 > > > (with required features...) system. For QEMU virtual machines you're > > > not supposed to do what you're doing, for production. > > > > > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > > > > to override the run time device tree with our own, because it's a > > > > > developer developing things or it's a user / production case where we > > > > > must use the provided tree. NOT doing that is what leads to madness > > > > > like we see for example on Pi where if we don't use the passed tree we > > > > > still need to copy X/Y/Z out of it. > > > > > > > > Aren't you talking about the distro DT there, rather than the the one > > > > on the boot disk? That is my reading of that patch. If we need to do > > > > that sort of thing, it doesn't matter where the the cointrol DT comes > > > > from. You are still going to have to do that sort of thing. > > > > > > > > It is not ALWAYS the case. I've shown you how easy it is to disable > > > > OF_BOARD and still boot / iterate. > > > > > > The DT we're passed in is the DT to pass to the OS. That's the hook for > > > putting a DTB on the device as it ships, the OS will just work. The > > > production case of needing to update that stored DTB is handled. It's > > > always what should be used, again outside of developer doing > > > development. > > > > > > Maybe that's part of the confusion here too. The DTB U-Boot is using is > > > the DTB the OS will consume too, in the passed at run time case. Unless > > > we're instead going to save that DTB aside? Which leaves me with a > > > different set of design questions... > > > > > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > > > > device tree in the binary. There's a growing set of devices where the > > > > > > > device tree exists with the device. If it's missing, that's a huge > > > > > > > fatal error we can't do all that much about. If we need to do something > > > > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > > > > forward for the developer to do that. But that's not the common case! > > > > > > > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > > > > > > > I just want to make sure that we always build the devicetrees and that > > > > > > it is easy for a knowledgeable dev to switch over to use them, without > > > > > > spelunking through dozens of other projects to discover the secret DT > > > > > > that no one will tell us about. > > > > > > > > > > Should we demand better documentation for boards? Yes. But it's still > > > > > a valid case to have zero device trees for a given platform in-tree. > > > > > Xen is an example of this. QEMU is an example of this. Platforms need > > > > > to work without adding special tweaks for us. Maybe that means some > > > > > features can't be tested in QEMU-as-virtual-platform and only in > > > > > QEMU-faithfully-emulating-specific-physical-platforms. > > > > > > > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > > > > case, I think. How about we create a special Kconfig for that case? We > > > > need to make some progress here. > > > > > > Yes, because there's a small number of OF_BOARD=y configs in tree right > > > now, most of which are QEMU virtual machines, others of which are Pi > > > (which we've talked to death), highbank (which Andre has explained), and > > > then the octeontx stuff I don't know how works. I keep pushing to say > > > that OF_BOARD=y is the special case we need to not overrule the device > > > tree provided to us on. Unless we start saving off that passed-to-us DTB > > > and then something-something for our own run-time DTB, and letting the > > > OS consume that passed-to-us one with only normal fixups applied. > > > > > > > > > > I guess another part of the problem is that historically almost all > > > > > > > platforms were in the first case I list above, no run time provided > > > > > > > device tree, so we took the kernel one and added our bindings to it. > > > > > > > Now we're being bit by the growing number of platforms that are the > > > > > > > second case, and how do we get our properties in there, and which ones > > > > > > > even make sense to do that for. > > > > > > > > > > > > I think upstreaming the bindings is the solution there. I've made a > > > > > > start, but we need to make progress with this series and all the other > > > > > > things in flight. I think a lot of people want U-Boot to not have a > > > > > > devicetree source files in it for ARMv8 platforms. I am strongly > > > > > > opposed to that. I've laid out my reasons very clearly in the past. I > > > > > > think this is a good summary: > > > > > > > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > > > > > > > > > > Yes, there are some ARMv8 platforms we will have to have the source > > > > > files to, in tree, because they won't come to us at run time. But > > > > > others we won't for practical reasons, namely that we can't statically > > > > > provide something that exists dynamically without massive duplication of > > > > > code or just taking things from that passed to us tree. > > > > > > > > So let's require that the static ones have the Linux DT in our tree > > > > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If > > > > that's it then I can agree a special case for them, so long as we sort > > > > out the docs for Xen. > > > > > > I'm agreeable to saying that if the dts files exist in Linux (or other > > > official source locations) we should have those in-tree, and the board > > > maintainer doesn't object, yes. But I think that might be a slightly > > > different list than what you say here. And that punts the run-time > > > decision down the road. And I'm assuming you're OK with also not > > > including a dtb in the image. > > > > > > > > > I believe I have been consistent in this although with all the > > > > > > discussion I'm really not sure anymore. > > > > > > > > > > Yes, everyone has been consistent in these discussions. > > > > > > > > I'd like to think more people accept that U-Boot is allowed its own > > > > properties than did at the start. > > > > > > > > > > > > > > > The problem is that various people have various views about how U-Boot > > > > > > should work with devicetree. I strongly believe that until we have > > > > > > bindings upstream, a central repo for DTs with easy downloading for > > > > > > builds, automated validation, among other things, we must maintain the > > > > > > devicetree in U-Boot. Just from the POV of energy expended, I do not > > > > > > want to be arguing with the Linaro folks about what U-Boot is allowed > > > > > > to do every month for the next two years. I'd rather set out the stall > > > > > > now and then deal with the problems it causes from that perspective. > > > > > > > > > > The problems of the last going on 12 years won't be solved instantly. > > > > > The conflict as I see it is that you're insisting that all platforms > > > > > must have statically usable device trees, and I (and I believe others) > > > > > are saying that's unreasonable in cases where the trees are dynamic at > > > > > heart, lets just ensure we have good enough documentation for them, > > > > > which we don't today. > > > > > > > > > > To be clear and pick an example, I don't want Pi dts files in U-Boot, > > > > > but, OK, it's an easy enough case to sync them up and so long as we > > > > > aren't yet at the "now we pick at run time between compiled in or passed > > > > > to us dtb", I can accept them in tree, but not in the resulting binary > > > > > for OF_CONTROL=y. But as the Xen folks have also noted, there's no > > > > > reasonable tree to include there. It does need to be better documented > > > > > how to fire it up however, in our sources. > > > > > > > > I'm OK with us copying in the Linux devicetree and using that. But > > > > OF_BOARD must be a run-time option and able to be disabled. The > > > > devicetree must be built, so it is actually real. We can have a > > > > separate OF_OMIT or something like that to omit the devicetree from > > > > the output image, perhaps. > > > > > > You're changing the meaning of CONFIG options. I like the idea Mark > > > suggested (probably after you wrote this..) of introducing something new > > > for what you're talking about. But no, it's unreasonable to say that > > > every U-Boot binary will bundle one or more dtb and make a run time > > > decision about what to use as the normal way the world works. > > > > > > > All of the other things need to wait until we make progress with > > > > devicetree bindings, validation, > > > > > > > > How can we make progress on this? We have different goals, as I have > > > > explained, so we are not going to agree on everything. > > > > > > Replace patches 4 to 14 with syncing platforms dts files from current > > > Linux release, and when OF_BOARD=y don't include a device tree in the > > > resulting image? That might also need adding some documentation for > > > some platforms on where the device tree is and how to extract it. > > > > How about we create a new option for that, as we discussed on IRC a > > while back? After all, sandbox uses OF_BOARD. It doesn't mean > > OF_PRIOR_STAGE, just that we call board_fdt_blob_setup(). > > > > So something like OF_OMIT_DTB? For U-Boot as a whole this is an uncommon case. > > > > We also need to think about the protections again, perhaps we define > > OF_HAS_PRIOR_STAGE to indicate that the board works this way, then > > make it hard to disable OF_BOARD if that is set. > > I guess my hard sticking point here is I'm still entirely unconvinced > that the future step of "now we make run-time choice between built in or > provided dtb" makes sense. And I worry the way these CONFIG options > keep being presented is setting the ground work for this change that I'm > not agreed to conceptually. > > So, yes, we could add more CONFIG symbols and then maybe even follow up > and migrate a few more platforms over to them. I'm unclear why we need > more symbols, but, OK, yes, to make progress, lets try it. Sometimes I > understand patches better than paragraphs. OK I am trying it. I will send v7 soon. I am going to add the warnings we talked about in v7. I think the whole 'confusion' thing is overblown, but hopefully that will help get things moving too. Note that the difference between 'built-in' and 'provided' is just the run-time difference. The build puts the DT in the firmware image anyway, otherwise of course the board cannot boot. The image includes U-Boot and anything else that is needed. E.g. in the case of TF-A doing this, the build includes TF-A, U-Boot and devicetree. TF-A reads the devicetree, fiddles with it and passes it to U-Boot. So the firmware includes a built-in devicetree, one way or another. The question is what happens at runtime. This is related to my 'Binman' point. Regards, Simon
On Mon, Dec 06, 2021 at 08:24:56AM -0700, Simon Glass wrote: > Hi Tom, > > On Sun, 5 Dec 2021 at 06:32, Tom Rini <trini@konsulko.com> wrote: > > > > On Sat, Dec 04, 2021 at 03:09:59PM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Sat, 4 Dec 2021 at 11:03, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > > > > > > > > > [huge snip] > > > > > > > > There's things that need to be cleaned up because we have some small > > > > > > > > number of platforms that went off and did their own thing. But largely > > > > > > > > yes, things make sense to me. We have: > > > > > > > > - We embedded the device tree that will configure U-Boot, because there > > > > > > > > is no way for the hardware to have provided us one. > > > > > > > > - We do not embed the device tree that will configure U-Boot, because > > > > > > > > there is already one present in memory for us to use. > > > > > > > > > > > > > > > > Then we have the developer option of: > > > > > > > > - We embedded the device tree that will configure U-Boot, because we're > > > > > > > > developing something. > > > > > > > > > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice. > > > > > > > > > > > > But it's not possible. That's the problem we keep going around and > > > > > > around about. People keep raising real life examples where you cannot > > > > > > make a run time choice between "device tree we're passed at run time" > > > > > > and "device tree we're compiled with". > > > > > > > > > > I haven't seen one. The most extreme case is QEMU and it works fine. I > > > > > even added a test with it. What am I missing? > > > > > > > > QEMU and Xen should both never have an in-source-tree dts as they are > > > > dynamic. I think you missed the explanation about how U-Boot + Xen > > > > works? You're running the same U-Boot under Xen on any arbitrary ARMv8 > > > > (with required features...) system. For QEMU virtual machines you're > > > > not supposed to do what you're doing, for production. > > > > > > > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > > > > > to override the run time device tree with our own, because it's a > > > > > > developer developing things or it's a user / production case where we > > > > > > must use the provided tree. NOT doing that is what leads to madness > > > > > > like we see for example on Pi where if we don't use the passed tree we > > > > > > still need to copy X/Y/Z out of it. > > > > > > > > > > Aren't you talking about the distro DT there, rather than the the one > > > > > on the boot disk? That is my reading of that patch. If we need to do > > > > > that sort of thing, it doesn't matter where the the cointrol DT comes > > > > > from. You are still going to have to do that sort of thing. > > > > > > > > > > It is not ALWAYS the case. I've shown you how easy it is to disable > > > > > OF_BOARD and still boot / iterate. > > > > > > > > The DT we're passed in is the DT to pass to the OS. That's the hook for > > > > putting a DTB on the device as it ships, the OS will just work. The > > > > production case of needing to update that stored DTB is handled. It's > > > > always what should be used, again outside of developer doing > > > > development. > > > > > > > > Maybe that's part of the confusion here too. The DTB U-Boot is using is > > > > the DTB the OS will consume too, in the passed at run time case. Unless > > > > we're instead going to save that DTB aside? Which leaves me with a > > > > different set of design questions... > > > > > > > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > > > > > device tree in the binary. There's a growing set of devices where the > > > > > > > > device tree exists with the device. If it's missing, that's a huge > > > > > > > > fatal error we can't do all that much about. If we need to do something > > > > > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > > > > > forward for the developer to do that. But that's not the common case! > > > > > > > > > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > > > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > > > > > > > > > I just want to make sure that we always build the devicetrees and that > > > > > > > it is easy for a knowledgeable dev to switch over to use them, without > > > > > > > spelunking through dozens of other projects to discover the secret DT > > > > > > > that no one will tell us about. > > > > > > > > > > > > Should we demand better documentation for boards? Yes. But it's still > > > > > > a valid case to have zero device trees for a given platform in-tree. > > > > > > Xen is an example of this. QEMU is an example of this. Platforms need > > > > > > to work without adding special tweaks for us. Maybe that means some > > > > > > features can't be tested in QEMU-as-virtual-platform and only in > > > > > > QEMU-faithfully-emulating-specific-physical-platforms. > > > > > > > > > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > > > > > case, I think. How about we create a special Kconfig for that case? We > > > > > need to make some progress here. > > > > > > > > Yes, because there's a small number of OF_BOARD=y configs in tree right > > > > now, most of which are QEMU virtual machines, others of which are Pi > > > > (which we've talked to death), highbank (which Andre has explained), and > > > > then the octeontx stuff I don't know how works. I keep pushing to say > > > > that OF_BOARD=y is the special case we need to not overrule the device > > > > tree provided to us on. Unless we start saving off that passed-to-us DTB > > > > and then something-something for our own run-time DTB, and letting the > > > > OS consume that passed-to-us one with only normal fixups applied. > > > > > > > > > > > > I guess another part of the problem is that historically almost all > > > > > > > > platforms were in the first case I list above, no run time provided > > > > > > > > device tree, so we took the kernel one and added our bindings to it. > > > > > > > > Now we're being bit by the growing number of platforms that are the > > > > > > > > second case, and how do we get our properties in there, and which ones > > > > > > > > even make sense to do that for. > > > > > > > > > > > > > > I think upstreaming the bindings is the solution there. I've made a > > > > > > > start, but we need to make progress with this series and all the other > > > > > > > things in flight. I think a lot of people want U-Boot to not have a > > > > > > > devicetree source files in it for ARMv8 platforms. I am strongly > > > > > > > opposed to that. I've laid out my reasons very clearly in the past. I > > > > > > > think this is a good summary: > > > > > > > > > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > > > > > > > > > > > > Yes, there are some ARMv8 platforms we will have to have the source > > > > > > files to, in tree, because they won't come to us at run time. But > > > > > > others we won't for practical reasons, namely that we can't statically > > > > > > provide something that exists dynamically without massive duplication of > > > > > > code or just taking things from that passed to us tree. > > > > > > > > > > So let's require that the static ones have the Linux DT in our tree > > > > > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If > > > > > that's it then I can agree a special case for them, so long as we sort > > > > > out the docs for Xen. > > > > > > > > I'm agreeable to saying that if the dts files exist in Linux (or other > > > > official source locations) we should have those in-tree, and the board > > > > maintainer doesn't object, yes. But I think that might be a slightly > > > > different list than what you say here. And that punts the run-time > > > > decision down the road. And I'm assuming you're OK with also not > > > > including a dtb in the image. > > > > > > > > > > > I believe I have been consistent in this although with all the > > > > > > > discussion I'm really not sure anymore. > > > > > > > > > > > > Yes, everyone has been consistent in these discussions. > > > > > > > > > > I'd like to think more people accept that U-Boot is allowed its own > > > > > properties than did at the start. > > > > > > > > > > > > > > > > > > The problem is that various people have various views about how U-Boot > > > > > > > should work with devicetree. I strongly believe that until we have > > > > > > > bindings upstream, a central repo for DTs with easy downloading for > > > > > > > builds, automated validation, among other things, we must maintain the > > > > > > > devicetree in U-Boot. Just from the POV of energy expended, I do not > > > > > > > want to be arguing with the Linaro folks about what U-Boot is allowed > > > > > > > to do every month for the next two years. I'd rather set out the stall > > > > > > > now and then deal with the problems it causes from that perspective. > > > > > > > > > > > > The problems of the last going on 12 years won't be solved instantly. > > > > > > The conflict as I see it is that you're insisting that all platforms > > > > > > must have statically usable device trees, and I (and I believe others) > > > > > > are saying that's unreasonable in cases where the trees are dynamic at > > > > > > heart, lets just ensure we have good enough documentation for them, > > > > > > which we don't today. > > > > > > > > > > > > To be clear and pick an example, I don't want Pi dts files in U-Boot, > > > > > > but, OK, it's an easy enough case to sync them up and so long as we > > > > > > aren't yet at the "now we pick at run time between compiled in or passed > > > > > > to us dtb", I can accept them in tree, but not in the resulting binary > > > > > > for OF_CONTROL=y. But as the Xen folks have also noted, there's no > > > > > > reasonable tree to include there. It does need to be better documented > > > > > > how to fire it up however, in our sources. > > > > > > > > > > I'm OK with us copying in the Linux devicetree and using that. But > > > > > OF_BOARD must be a run-time option and able to be disabled. The > > > > > devicetree must be built, so it is actually real. We can have a > > > > > separate OF_OMIT or something like that to omit the devicetree from > > > > > the output image, perhaps. > > > > > > > > You're changing the meaning of CONFIG options. I like the idea Mark > > > > suggested (probably after you wrote this..) of introducing something new > > > > for what you're talking about. But no, it's unreasonable to say that > > > > every U-Boot binary will bundle one or more dtb and make a run time > > > > decision about what to use as the normal way the world works. > > > > > > > > > All of the other things need to wait until we make progress with > > > > > devicetree bindings, validation, > > > > > > > > > > How can we make progress on this? We have different goals, as I have > > > > > explained, so we are not going to agree on everything. > > > > > > > > Replace patches 4 to 14 with syncing platforms dts files from current > > > > Linux release, and when OF_BOARD=y don't include a device tree in the > > > > resulting image? That might also need adding some documentation for > > > > some platforms on where the device tree is and how to extract it. > > > > > > How about we create a new option for that, as we discussed on IRC a > > > while back? After all, sandbox uses OF_BOARD. It doesn't mean > > > OF_PRIOR_STAGE, just that we call board_fdt_blob_setup(). > > > > > > So something like OF_OMIT_DTB? For U-Boot as a whole this is an uncommon case. > > > > > > We also need to think about the protections again, perhaps we define > > > OF_HAS_PRIOR_STAGE to indicate that the board works this way, then > > > make it hard to disable OF_BOARD if that is set. > > > > I guess my hard sticking point here is I'm still entirely unconvinced > > that the future step of "now we make run-time choice between built in or > > provided dtb" makes sense. And I worry the way these CONFIG options > > keep being presented is setting the ground work for this change that I'm > > not agreed to conceptually. > > > > So, yes, we could add more CONFIG symbols and then maybe even follow up > > and migrate a few more platforms over to them. I'm unclear why we need > > more symbols, but, OK, yes, to make progress, lets try it. Sometimes I > > understand patches better than paragraphs. > > OK I am trying it. I will send v7 soon. > > I am going to add the warnings we talked about in v7. I think the > whole 'confusion' thing is overblown, but hopefully that will help get > things moving too. > > Note that the difference between 'built-in' and 'provided' is just the > run-time difference. The build puts the DT in the firmware image > anyway, otherwise of course the board cannot boot. The image includes > U-Boot and anything else that is needed. E.g. in the case of TF-A > doing this, the build includes TF-A, U-Boot and devicetree. TF-A reads > the devicetree, fiddles with it and passes it to U-Boot. So the > firmware includes a built-in devicetree, one way or another. The > question is what happens at runtime. This is related to my 'Binman' > point. Thanks. I have questions, but I'll save them for after I've poked at v7. Please note the git branch in the cover letter too.
Hi Simon, On Thu, 2 Dec 2021 at 18:00, Simon Glass <sjg@chromium.org> wrote: > > We only have two choices for obtaining the devicetree. Simplify the code > to make that clear. > > Signed-off-by: Simon Glass <sjg@chromium.org> > --- > > (no changes since v1) > > lib/fdtdec.c | 20 +++++++++++--------- > 1 file changed, 11 insertions(+), 9 deletions(-) > > diff --git a/lib/fdtdec.c b/lib/fdtdec.c > index 5b31064cee2..a7f62123a94 100644 > --- a/lib/fdtdec.c > +++ b/lib/fdtdec.c > @@ -1624,15 +1624,17 @@ static void setup_multi_dtb_fit(void) > int fdtdec_setup(void) > { > int ret; > -#ifdef CONFIG_OF_EMBED > - /* Get a pointer to the FDT */ > - gd->fdt_blob = dtb_dt_embedded(); > -#elif defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE) > - /* Allow the board to override the fdt address. */ > - gd->fdt_blob = board_fdt_blob_setup(&ret); > - if (ret) > - return ret; > -#endif > + > + /* The devicetree is typically appended to U-Boot */ > + if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD)) { > + /* Allow the board to override the fdt address. */ > + gd->fdt_blob = board_fdt_blob_setup(&ret); > + if (ret) > + return ret; > + } else { /* embed dtb in ELF file for testing / development */ > + gd->fdt_blob = dtb_dt_embedded(); > + } > + > if (!IS_ENABLED(CONFIG_SPL_BUILD)) { > /* Allow the early environment to override the fdt address */ > gd->fdt_blob = map_sysmem(env_get_ulong("fdtcontroladdr", 16, > -- > 2.34.0.rc2.393.gf8c9666880-goog > In case you need to resend this can you change the commit message a bit? This doesn't really simplify the logic, just replaces ifdefs with IS_ENABLED Other than that Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so there are only three ways to obtain a devicetree: - OF_SEPARATE - the normal way, where the devicetree is built and appended to U-Boot - OF_EMBED - for development purposes, the devicetree is embedded in the ELF file (also used for EFI) - OF_BOARD - the board figures it out on its own The last one is currently set up so that no devicetree is needed at all in the U-Boot tree. Most boards do provide one, but some don't. Some don't even provide instructions on how to boot on the board. The problems with this approach are documented in another patch in this series: "doc: Add documentation about devicetree usage" In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board can obtain its devicetree at runtime, even it is has a devicetree built in U-Boot. This is because U-Boot may be a second-stage bootloader and its caller may have a better idea about the hardware available in the machine. This is the case with a few QEMU boards, for example. So it makes no sense to have OF_BOARD as a 'choice'. It should be an option, available with either OF_SEPARATE or OF_EMBED. This series makes this change, adding various missing devicetree files (and placeholders) to make the build work. Note: If board maintainers are able to add their own patch to add the files, some patches in this series can be dropped. It also provides a few qemu clean-ups discovered along the way. The qemu-riscv64_spl problem is fixed. [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ Changes in v6: - Fix description of OF_BOARD so it refers just to the current state - Explain that the 'two devicetrees' refers to two *control* devicetrees - Expand the commit message based on comments - Expand the commit message based on comments Changes in v5: - Bring into the OF_BOARD series - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed - Refer to the 'control' DTB in the first paragraph - Use QEMU instead of qemu - Merge RISC-V and ARM patches since they are similar - Add new patches to clean up fdtdec_setup() and surrounds Changes in v3: - Clarify the 'bug' refered to at the top - Reword 'This means that there' paragraph to explain U-Boot-specific things - Move to doc/develop/devicetree now that OF_CONTROL is in the docs Changes in v2: - Fix typos per Sean (thank you!) and a few others - Add a 'Use of U-Boot /config node' section - Drop mention of dm-verity since that actually uses the kernel cmdline - Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph) - Expand a bit on the reason why the 'Current situation' is bad - Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...' - Expand on why we should have rules for other projects in 'Devicetree in another project' - Add a comment as to why devicetree in U-Boot is not 'bad design' - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' - Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1 - Add 'Why does U-Boot have its nodes and properties?' - Add 'Why not have two devicetrees?' Simon Glass (25): doc: Add documentation about devicetree usage arm: qemu: Mention -nographic in the docs arm: riscv: qemu: Explain how to extract the generated dt arm: qemu: Add a devicetree file for qemu_arm arm: qemu: Add a devicetree file for qemu_arm64 riscv: qemu: Add devicetree files for qemu_riscv32/64 arm: rpi: Add a devicetree file for rpi_4 arm: vexpress: Add a devicetree file for juno arm: xenguest_arm64: Add a fake devicetree file arm: octeontx: Add a fake devicetree file arm: xilinx_versal_virt: Add a devicetree file arm: bcm7xxx: Add a devicetree file arm: qemu-ppce500: Add a devicetree file arm: highbank: Add a fake devicetree file fdt: Make OF_BOARD a bool option Drop CONFIG_BINMAN_STANDALONE_FDT doc: Update info on devicetree update fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() fdt: Drop #ifdefs with MULTI_DTB_FIT fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() fdt: Drop #ifdef around board_fdt_blob_setup() fdt: Use if() for fdtcontroladdr check fdt: Drop OF_CONTROL check in fdtdec_setup() fdt: Drop remaining preprocessor macros in fdtdec_setup() fdt: Don't call board_fdt_blob_setup() without OF_BOARD Makefile | 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 | 2 +- configs/xilinx_versal_virt_defconfig | 1 + doc/board/emulation/qemu-arm.rst | 10 +- doc/board/emulation/qemu-riscv.rst | 3 + doc/develop/devicetree/dt_qemu.rst | 48 + doc/develop/devicetree/dt_update.rst | 497 ++++++ doc/develop/devicetree/index.rst | 2 + dts/Kconfig | 30 +- include/asm-generic/global_data.h | 8 + include/fdtdec.h | 21 +- lib/fdtdec.c | 117 +- tools/binman/binman.rst | 20 - 49 files changed, 5538 insertions(+), 124 deletions(-) create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts create mode 100644 arch/arm/dts/bcm7xxx.dts create mode 100644 arch/arm/dts/highbank.dts create mode 100644 arch/arm/dts/juno-r2.dts create mode 100644 arch/arm/dts/octeontx.dts create mode 100644 arch/arm/dts/qemu-arm.dts create mode 100644 arch/arm/dts/qemu-arm64.dts create mode 100644 arch/arm/dts/xenguest-arm64.dts create mode 100644 arch/arm/dts/xilinx-versal-virt.dts create mode 100644 arch/powerpc/dts/qemu-ppce500.dts delete mode 100644 arch/riscv/dts/qemu-virt.dts create mode 100644 arch/riscv/dts/qemu-virt32.dts create mode 100644 arch/riscv/dts/qemu-virt64.dts create mode 100644 doc/develop/devicetree/dt_qemu.rst create mode 100644 doc/develop/devicetree/dt_update.rst