| Message ID | 20211026002344.405160-1-sjg@chromium.org |
|---|---|
| Headers | show |
| Series | fdt: Make OF_BOARD a boolean option | expand |
Hi Simon Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. Cheers FF Le mar. 26 oct. 2021 à 02:24, Simon Glass <sjg@chromium.org> a écrit : > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > there are only three ways to obtain a devicetree: > > - OF_SEPARATE - the normal way, where the devicetree is built and > appended to U-Boot > - OF_EMBED - for development purposes, the devicetree is embedded in > the ELF file (also used for EFI) > - OF_BOARD - the board figures it out on its own > > The last one is currently set up so that no devicetree is needed at all > in the U-Boot tree. Most boards do provide one, but some don't. Some > don't even provide instructions on how to boot on the board. > > The problems with this approach are documented in another patch in this > series: "doc: Add documentation about devicetree usage" > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > can obtain its devicetree at runtime, even it is has a devicetree built > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > caller may have a better idea about the hardware available in the machine. > This is the case with a few QEMU boards, for example. > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > option, available with either OF_SEPARATE or OF_EMBED. > > This series makes this change, adding various missing devicetree files > (and placeholders) to make the build work. > > Note: If board maintainers are able to add their own patch to add the > files, some patches in this series can be dropped. > > It also provides a few qemu clean-ups discovered along the way. > > Note: This breaks the qemu-riscv64_spl test, which still needs > investigation. > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > Changes in v5: > - Bring into the OF_BOARD series > - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > - Refer to the 'control' DTB in the first paragraph > - Use QEMU instead of qemu > - Merge RISC-V and ARM patches since they are similar > - Add new patches to clean up fdtdec_setup() and surrounds > > Changes in v3: > - Clarify the 'bug' refered to at the top > - Reword 'This means that there' paragraph to explain U-Boot-specific > things > - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > > Changes in v2: > - Fix typos per Sean (thank you!) and a few others > - Add a 'Use of U-Boot /config node' section > - Drop mention of dm-verity since that actually uses the kernel cmdline > - Explain that OF_BOARD will still work after these changes (in > 'Once this bug is fixed...' paragraph) > - Expand a bit on the reason why the 'Current situation' is bad > - Clarify in a second place that Linux and U-Boot use the same devicetree > in 'To be clear, while U-Boot...' > - Expand on why we should have rules for other projects in > 'Devicetree in another project' > - Add a comment as to why devicetree in U-Boot is not 'bad design' > - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > - Rewrite 'Devicetree generated on-the-fly in another project' to cover > points raised on v1 > - Add 'Why does U-Boot have its nodes and properties?' > - Add 'Why not have two devicetrees?' > > Ilias Apalodimas (1): > sandbox: Remove OF_HOSTFILE > > Simon Glass (25): > doc: Add documentation about devicetree usage > arm: qemu: Mention -nographic in the docs > arm: riscv: qemu: Explain how to extract the generated dt > arm: qemu: Add a devicetree file for qemu_arm > arm: qemu: Add a devicetree file for qemu_arm64 > riscv: qemu: Add devicetree files for qemu_riscv32/64 > arm: rpi: Add a devicetree file for rpi_4 > arm: vexpress: Add a devicetree file for juno > arm: xenguest_arm64: Add a fake devicetree file > arm: octeontx: Add a fake devicetree file > arm: xilinx_versal_virt: Add a devicetree file > arm: bcm7xxx: Add a devicetree file > arm: qemu-ppce500: Add a devicetree file > arm: highbank: Add a fake devicetree file > fdt: Make OF_BOARD a bool option > Drop CONFIG_BINMAN_STANDALONE_FDT > doc: Update info on devicetree update > fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() > fdt: Drop #ifdefs with MULTI_DTB_FIT > fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() > fdt: Drop #ifdef around board_fdt_blob_setup() > fdt: Use if() for fdtcontroladdr check > fdt: Drop OF_CONTROL check in fdtdec_setup() > fdt: Drop remaining preprocessor macros in fdtdec_setup() > fdt: Don't call board_fdt_blob_setup() without OF_BOARD > > Makefile | 7 +- > arch/arm/dts/Makefile | 20 +- > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 +++++++++++++++++++++ > arch/arm/dts/bcm7xxx.dts | 15 + > arch/arm/dts/highbank.dts | 14 + > arch/arm/dts/juno-r2.dts | 1038 +++++++++++ > arch/arm/dts/octeontx.dts | 14 + > arch/arm/dts/qemu-arm.dts | 402 +++++ > arch/arm/dts/qemu-arm64.dts | 381 ++++ > arch/arm/dts/xenguest-arm64.dts | 15 + > arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ > arch/powerpc/dts/Makefile | 1 + > arch/powerpc/dts/qemu-ppce500.dts | 264 +++ > arch/riscv/dts/Makefile | 2 +- > arch/riscv/dts/qemu-virt.dts | 8 - > arch/riscv/dts/qemu-virt32.dts | 217 +++ > arch/riscv/dts/qemu-virt64.dts | 217 +++ > arch/sandbox/cpu/cpu.c | 21 +- > arch/sandbox/include/asm/u-boot-sandbox.h | 8 - > configs/bcm7260_defconfig | 1 + > configs/bcm7445_defconfig | 1 + > configs/highbank_defconfig | 2 +- > configs/octeontx2_95xx_defconfig | 1 + > configs/octeontx2_96xx_defconfig | 1 + > configs/octeontx_81xx_defconfig | 1 + > configs/octeontx_83xx_defconfig | 1 + > configs/qemu-ppce500_defconfig | 2 + > configs/qemu-riscv32_defconfig | 1 + > configs/qemu-riscv32_smode_defconfig | 1 + > configs/qemu-riscv32_spl_defconfig | 4 +- > configs/qemu-riscv64_defconfig | 1 + > configs/qemu-riscv64_smode_defconfig | 1 + > configs/qemu-riscv64_spl_defconfig | 3 +- > configs/qemu_arm64_defconfig | 1 + > configs/qemu_arm_defconfig | 1 + > configs/rpi_4_32b_defconfig | 1 + > configs/rpi_4_defconfig | 1 + > configs/rpi_arm64_defconfig | 1 + > configs/sandbox64_defconfig | 2 +- > configs/sandbox_defconfig | 2 +- > configs/sandbox_flattree_defconfig | 2 +- > configs/sandbox_noinst_defconfig | 2 +- > configs/sandbox_spl_defconfig | 2 +- > configs/tools-only_defconfig | 2 +- > configs/vexpress_aemv8a_juno_defconfig | 1 + > configs/xenguest_arm64_defconfig | 1 + > configs/xilinx_versal_virt_defconfig | 1 + > doc/board/emulation/qemu-arm.rst | 10 +- > doc/board/emulation/qemu-riscv.rst | 3 + > doc/develop/devicetree/control.rst | 7 +- > doc/develop/devicetree/dt_qemu.rst | 48 + > doc/develop/devicetree/dt_update.rst | 498 ++++++ > doc/develop/devicetree/index.rst | 2 + > dts/Kconfig | 37 +- > include/asm-generic/global_data.h | 8 + > include/fdtdec.h | 21 +- > lib/fdtdec.c | 116 +- > scripts/Makefile.spl | 4 +- > tools/binman/binman.rst | 20 - > 59 files changed, 5560 insertions(+), 164 deletions(-) > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > create mode 100644 arch/arm/dts/bcm7xxx.dts > create mode 100644 arch/arm/dts/highbank.dts > create mode 100644 arch/arm/dts/juno-r2.dts > create mode 100644 arch/arm/dts/octeontx.dts > create mode 100644 arch/arm/dts/qemu-arm.dts > create mode 100644 arch/arm/dts/qemu-arm64.dts > create mode 100644 arch/arm/dts/xenguest-arm64.dts > create mode 100644 arch/arm/dts/xilinx-versal-virt.dts > create mode 100644 arch/powerpc/dts/qemu-ppce500.dts > delete mode 100644 arch/riscv/dts/qemu-virt.dts > create mode 100644 arch/riscv/dts/qemu-virt32.dts > create mode 100644 arch/riscv/dts/qemu-virt64.dts > create mode 100644 doc/develop/devicetree/dt_qemu.rst > create mode 100644 doc/develop/devicetree/dt_update.rst > > -- > 2.33.0.1079.g6e70778dc9-goog > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
Hi François, On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: > > Hi Simon > > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know. But trying to do any driver / core work for a board where you don't have the devicetree is currently not possible. The devicetree is a core component and being unable to modify it is simply not practical. We are talking here about an option that can be enabled or disabled. In my case I am able to disable it locally and do my development work. BTW I've got the bloblist handoff working with a devicetree inside it, for qemu_arm. I need to try it on a real board to figure out what the difference is. Regards, Simon > > > Cheers > > FF > > Le mar. 26 oct. 2021 à 02:24, Simon Glass <sjg@chromium.org> a écrit : >> >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so >> there are only three ways to obtain a devicetree: >> >> - OF_SEPARATE - the normal way, where the devicetree is built and >> appended to U-Boot >> - OF_EMBED - for development purposes, the devicetree is embedded in >> the ELF file (also used for EFI) >> - OF_BOARD - the board figures it out on its own >> >> The last one is currently set up so that no devicetree is needed at all >> in the U-Boot tree. Most boards do provide one, but some don't. Some >> don't even provide instructions on how to boot on the board. >> >> The problems with this approach are documented in another patch in this >> series: "doc: Add documentation about devicetree usage" >> >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board >> can obtain its devicetree at runtime, even it is has a devicetree built >> in U-Boot. This is because U-Boot may be a second-stage bootloader and its >> caller may have a better idea about the hardware available in the machine. >> This is the case with a few QEMU boards, for example. >> >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an >> option, available with either OF_SEPARATE or OF_EMBED. >> >> This series makes this change, adding various missing devicetree files >> (and placeholders) to make the build work. >> >> Note: If board maintainers are able to add their own patch to add the >> files, some patches in this series can be dropped. >> >> It also provides a few qemu clean-ups discovered along the way. >> >> Note: This breaks the qemu-riscv64_spl test, which still needs >> investigation. >> >> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ >> >> Changes in v5: >> - Bring into the OF_BOARD series >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed >> - Refer to the 'control' DTB in the first paragraph >> - Use QEMU instead of qemu >> - Merge RISC-V and ARM patches since they are similar >> - Add new patches to clean up fdtdec_setup() and surrounds >> >> Changes in v3: >> - Clarify the 'bug' refered to at the top >> - Reword 'This means that there' paragraph to explain U-Boot-specific things >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs >> >> Changes in v2: >> - Fix typos per Sean (thank you!) and a few others >> - Add a 'Use of U-Boot /config node' section >> - Drop mention of dm-verity since that actually uses the kernel cmdline >> - Explain that OF_BOARD will still work after these changes (in >> 'Once this bug is fixed...' paragraph) >> - Expand a bit on the reason why the 'Current situation' is bad >> - Clarify in a second place that Linux and U-Boot use the same devicetree >> in 'To be clear, while U-Boot...' >> - Expand on why we should have rules for other projects in >> 'Devicetree in another project' >> - Add a comment as to why devicetree in U-Boot is not 'bad design' >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover >> points raised on v1 >> - Add 'Why does U-Boot have its nodes and properties?' >> - Add 'Why not have two devicetrees?' >> >> Ilias Apalodimas (1): >> sandbox: Remove OF_HOSTFILE >> >> Simon Glass (25): >> doc: Add documentation about devicetree usage >> arm: qemu: Mention -nographic in the docs >> arm: riscv: qemu: Explain how to extract the generated dt >> arm: qemu: Add a devicetree file for qemu_arm >> arm: qemu: Add a devicetree file for qemu_arm64 >> riscv: qemu: Add devicetree files for qemu_riscv32/64 >> arm: rpi: Add a devicetree file for rpi_4 >> arm: vexpress: Add a devicetree file for juno >> arm: xenguest_arm64: Add a fake devicetree file >> arm: octeontx: Add a fake devicetree file >> arm: xilinx_versal_virt: Add a devicetree file >> arm: bcm7xxx: Add a devicetree file >> arm: qemu-ppce500: Add a devicetree file >> arm: highbank: Add a fake devicetree file >> fdt: Make OF_BOARD a bool option >> Drop CONFIG_BINMAN_STANDALONE_FDT >> doc: Update info on devicetree update >> fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() >> fdt: Drop #ifdefs with MULTI_DTB_FIT >> fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() >> fdt: Drop #ifdef around board_fdt_blob_setup() >> fdt: Use if() for fdtcontroladdr check >> fdt: Drop OF_CONTROL check in fdtdec_setup() >> fdt: Drop remaining preprocessor macros in fdtdec_setup() >> fdt: Don't call board_fdt_blob_setup() without OF_BOARD >> >> Makefile | 7 +- >> arch/arm/dts/Makefile | 20 +- >> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 +++++++++++++++++++++ >> arch/arm/dts/bcm7xxx.dts | 15 + >> arch/arm/dts/highbank.dts | 14 + >> arch/arm/dts/juno-r2.dts | 1038 +++++++++++ >> arch/arm/dts/octeontx.dts | 14 + >> arch/arm/dts/qemu-arm.dts | 402 +++++ >> arch/arm/dts/qemu-arm64.dts | 381 ++++ >> arch/arm/dts/xenguest-arm64.dts | 15 + >> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ >> arch/powerpc/dts/Makefile | 1 + >> arch/powerpc/dts/qemu-ppce500.dts | 264 +++ >> arch/riscv/dts/Makefile | 2 +- >> arch/riscv/dts/qemu-virt.dts | 8 - >> arch/riscv/dts/qemu-virt32.dts | 217 +++ >> arch/riscv/dts/qemu-virt64.dts | 217 +++ >> arch/sandbox/cpu/cpu.c | 21 +- >> arch/sandbox/include/asm/u-boot-sandbox.h | 8 - >> configs/bcm7260_defconfig | 1 + >> configs/bcm7445_defconfig | 1 + >> configs/highbank_defconfig | 2 +- >> configs/octeontx2_95xx_defconfig | 1 + >> configs/octeontx2_96xx_defconfig | 1 + >> configs/octeontx_81xx_defconfig | 1 + >> configs/octeontx_83xx_defconfig | 1 + >> configs/qemu-ppce500_defconfig | 2 + >> configs/qemu-riscv32_defconfig | 1 + >> configs/qemu-riscv32_smode_defconfig | 1 + >> configs/qemu-riscv32_spl_defconfig | 4 +- >> configs/qemu-riscv64_defconfig | 1 + >> configs/qemu-riscv64_smode_defconfig | 1 + >> configs/qemu-riscv64_spl_defconfig | 3 +- >> configs/qemu_arm64_defconfig | 1 + >> configs/qemu_arm_defconfig | 1 + >> configs/rpi_4_32b_defconfig | 1 + >> configs/rpi_4_defconfig | 1 + >> configs/rpi_arm64_defconfig | 1 + >> configs/sandbox64_defconfig | 2 +- >> configs/sandbox_defconfig | 2 +- >> configs/sandbox_flattree_defconfig | 2 +- >> configs/sandbox_noinst_defconfig | 2 +- >> configs/sandbox_spl_defconfig | 2 +- >> configs/tools-only_defconfig | 2 +- >> configs/vexpress_aemv8a_juno_defconfig | 1 + >> configs/xenguest_arm64_defconfig | 1 + >> configs/xilinx_versal_virt_defconfig | 1 + >> doc/board/emulation/qemu-arm.rst | 10 +- >> doc/board/emulation/qemu-riscv.rst | 3 + >> doc/develop/devicetree/control.rst | 7 +- >> doc/develop/devicetree/dt_qemu.rst | 48 + >> doc/develop/devicetree/dt_update.rst | 498 ++++++ >> doc/develop/devicetree/index.rst | 2 + >> dts/Kconfig | 37 +- >> include/asm-generic/global_data.h | 8 + >> include/fdtdec.h | 21 +- >> lib/fdtdec.c | 116 +- >> scripts/Makefile.spl | 4 +- >> tools/binman/binman.rst | 20 - >> 59 files changed, 5560 insertions(+), 164 deletions(-) >> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts >> create mode 100644 arch/arm/dts/bcm7xxx.dts >> create mode 100644 arch/arm/dts/highbank.dts >> create mode 100644 arch/arm/dts/juno-r2.dts >> create mode 100644 arch/arm/dts/octeontx.dts >> create mode 100644 arch/arm/dts/qemu-arm.dts >> create mode 100644 arch/arm/dts/qemu-arm64.dts >> create mode 100644 arch/arm/dts/xenguest-arm64.dts >> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts >> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts >> delete mode 100644 arch/riscv/dts/qemu-virt.dts >> create mode 100644 arch/riscv/dts/qemu-virt32.dts >> create mode 100644 arch/riscv/dts/qemu-virt64.dts >> create mode 100644 doc/develop/devicetree/dt_qemu.rst >> create mode 100644 doc/develop/devicetree/dt_update.rst >> >> -- >> 2.33.0.1079.g6e70778dc9-goog >> > -- > François-Frédéric Ozog | Director Business Development > T: +33.67221.6485 > francois.ozog@linaro.org | Skype: ffozog >
On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: > Hi François, > > On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> > wrote: > > > > Hi Simon > > > > Position unchanged on this series: adding fake dts for boards that > generate their device tree in the dts directory is not good. If you have > them in documentation the it is acceptable. > > I think we are going to have to disagree on this one. I actually used > the qemu one in testing/development recently. We have to have a way to > develop in-tree with U-Boot. It does not impinge on any of your use > cases, so far as I know. > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. > > But trying to do any driver / core work for a board where you don't > have the devicetree is currently not possible. The devicetree is a > core component and being unable to modify it is simply not practical. > We are talking here about an option that can be enabled or disabled. > In my case I am able to disable it locally and do my development work. > BTW I've got the bloblist handoff working with a devicetree inside it, > for qemu_arm. I need to try it on a real board to figure out what the > difference is. > > That's great news and much needed for stabilizing the inbound ABI from prior loader to U-Boot. Let's create another thread to discuss this important topic. > Regards, > Simon > > > > > > > > > > > Cheers > > > > FF > > > > Le mar. 26 oct. 2021 à 02:24, Simon Glass <sjg@chromium.org> a écrit : > >> > >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > >> there are only three ways to obtain a devicetree: > >> > >> - OF_SEPARATE - the normal way, where the devicetree is built and > >> appended to U-Boot > >> - OF_EMBED - for development purposes, the devicetree is embedded in > >> the ELF file (also used for EFI) > >> - OF_BOARD - the board figures it out on its own > >> > >> The last one is currently set up so that no devicetree is needed at all > >> in the U-Boot tree. Most boards do provide one, but some don't. Some > >> don't even provide instructions on how to boot on the board. > >> > >> The problems with this approach are documented in another patch in this > >> series: "doc: Add documentation about devicetree usage" > >> > >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > >> can obtain its devicetree at runtime, even it is has a devicetree built > >> in U-Boot. This is because U-Boot may be a second-stage bootloader and > its > >> caller may have a better idea about the hardware available in the > machine. > >> This is the case with a few QEMU boards, for example. > >> > >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an > >> option, available with either OF_SEPARATE or OF_EMBED. > >> > >> This series makes this change, adding various missing devicetree files > >> (and placeholders) to make the build work. > >> > >> Note: If board maintainers are able to add their own patch to add the > >> files, some patches in this series can be dropped. > >> > >> It also provides a few qemu clean-ups discovered along the way. > >> > >> Note: This breaks the qemu-riscv64_spl test, which still needs > >> investigation. > >> > >> [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > >> > >> Changes in v5: > >> - Bring into the OF_BOARD series > >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > >> - Refer to the 'control' DTB in the first paragraph > >> - Use QEMU instead of qemu > >> - Merge RISC-V and ARM patches since they are similar > >> - Add new patches to clean up fdtdec_setup() and surrounds > >> > >> Changes in v3: > >> - Clarify the 'bug' refered to at the top > >> - Reword 'This means that there' paragraph to explain U-Boot-specific > things > >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > >> > >> Changes in v2: > >> - Fix typos per Sean (thank you!) and a few others > >> - Add a 'Use of U-Boot /config node' section > >> - Drop mention of dm-verity since that actually uses the kernel cmdline > >> - Explain that OF_BOARD will still work after these changes (in > >> 'Once this bug is fixed...' paragraph) > >> - Expand a bit on the reason why the 'Current situation' is bad > >> - Clarify in a second place that Linux and U-Boot use the same > devicetree > >> in 'To be clear, while U-Boot...' > >> - Expand on why we should have rules for other projects in > >> 'Devicetree in another project' > >> - Add a comment as to why devicetree in U-Boot is not 'bad design' > >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover > >> points raised on v1 > >> - Add 'Why does U-Boot have its nodes and properties?' > >> - Add 'Why not have two devicetrees?' > >> > >> Ilias Apalodimas (1): > >> sandbox: Remove OF_HOSTFILE > >> > >> Simon Glass (25): > >> doc: Add documentation about devicetree usage > >> arm: qemu: Mention -nographic in the docs > >> arm: riscv: qemu: Explain how to extract the generated dt > >> arm: qemu: Add a devicetree file for qemu_arm > >> arm: qemu: Add a devicetree file for qemu_arm64 > >> riscv: qemu: Add devicetree files for qemu_riscv32/64 > >> arm: rpi: Add a devicetree file for rpi_4 > >> arm: vexpress: Add a devicetree file for juno > >> arm: xenguest_arm64: Add a fake devicetree file > >> arm: octeontx: Add a fake devicetree file > >> arm: xilinx_versal_virt: Add a devicetree file > >> arm: bcm7xxx: Add a devicetree file > >> arm: qemu-ppce500: Add a devicetree file > >> arm: highbank: Add a fake devicetree file > >> fdt: Make OF_BOARD a bool option > >> Drop CONFIG_BINMAN_STANDALONE_FDT > >> doc: Update info on devicetree update > >> fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() > >> fdt: Drop #ifdefs with MULTI_DTB_FIT > >> fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() > >> fdt: Drop #ifdef around board_fdt_blob_setup() > >> fdt: Use if() for fdtcontroladdr check > >> fdt: Drop OF_CONTROL check in fdtdec_setup() > >> fdt: Drop remaining preprocessor macros in fdtdec_setup() > >> fdt: Don't call board_fdt_blob_setup() without OF_BOARD > >> > >> Makefile | 7 +- > >> arch/arm/dts/Makefile | 20 +- > >> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 +++++++++++++++++++++ > >> arch/arm/dts/bcm7xxx.dts | 15 + > >> arch/arm/dts/highbank.dts | 14 + > >> arch/arm/dts/juno-r2.dts | 1038 +++++++++++ > >> arch/arm/dts/octeontx.dts | 14 + > >> arch/arm/dts/qemu-arm.dts | 402 +++++ > >> arch/arm/dts/qemu-arm64.dts | 381 ++++ > >> arch/arm/dts/xenguest-arm64.dts | 15 + > >> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ > >> arch/powerpc/dts/Makefile | 1 + > >> arch/powerpc/dts/qemu-ppce500.dts | 264 +++ > >> arch/riscv/dts/Makefile | 2 +- > >> arch/riscv/dts/qemu-virt.dts | 8 - > >> arch/riscv/dts/qemu-virt32.dts | 217 +++ > >> arch/riscv/dts/qemu-virt64.dts | 217 +++ > >> arch/sandbox/cpu/cpu.c | 21 +- > >> arch/sandbox/include/asm/u-boot-sandbox.h | 8 - > >> configs/bcm7260_defconfig | 1 + > >> configs/bcm7445_defconfig | 1 + > >> configs/highbank_defconfig | 2 +- > >> configs/octeontx2_95xx_defconfig | 1 + > >> configs/octeontx2_96xx_defconfig | 1 + > >> configs/octeontx_81xx_defconfig | 1 + > >> configs/octeontx_83xx_defconfig | 1 + > >> configs/qemu-ppce500_defconfig | 2 + > >> configs/qemu-riscv32_defconfig | 1 + > >> configs/qemu-riscv32_smode_defconfig | 1 + > >> configs/qemu-riscv32_spl_defconfig | 4 +- > >> configs/qemu-riscv64_defconfig | 1 + > >> configs/qemu-riscv64_smode_defconfig | 1 + > >> configs/qemu-riscv64_spl_defconfig | 3 +- > >> configs/qemu_arm64_defconfig | 1 + > >> configs/qemu_arm_defconfig | 1 + > >> configs/rpi_4_32b_defconfig | 1 + > >> configs/rpi_4_defconfig | 1 + > >> configs/rpi_arm64_defconfig | 1 + > >> configs/sandbox64_defconfig | 2 +- > >> configs/sandbox_defconfig | 2 +- > >> configs/sandbox_flattree_defconfig | 2 +- > >> configs/sandbox_noinst_defconfig | 2 +- > >> configs/sandbox_spl_defconfig | 2 +- > >> configs/tools-only_defconfig | 2 +- > >> configs/vexpress_aemv8a_juno_defconfig | 1 + > >> configs/xenguest_arm64_defconfig | 1 + > >> configs/xilinx_versal_virt_defconfig | 1 + > >> doc/board/emulation/qemu-arm.rst | 10 +- > >> doc/board/emulation/qemu-riscv.rst | 3 + > >> doc/develop/devicetree/control.rst | 7 +- > >> doc/develop/devicetree/dt_qemu.rst | 48 + > >> doc/develop/devicetree/dt_update.rst | 498 ++++++ > >> doc/develop/devicetree/index.rst | 2 + > >> dts/Kconfig | 37 +- > >> include/asm-generic/global_data.h | 8 + > >> include/fdtdec.h | 21 +- > >> lib/fdtdec.c | 116 +- > >> scripts/Makefile.spl | 4 +- > >> tools/binman/binman.rst | 20 - > >> 59 files changed, 5560 insertions(+), 164 deletions(-) > >> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > >> create mode 100644 arch/arm/dts/bcm7xxx.dts > >> create mode 100644 arch/arm/dts/highbank.dts > >> create mode 100644 arch/arm/dts/juno-r2.dts > >> create mode 100644 arch/arm/dts/octeontx.dts > >> create mode 100644 arch/arm/dts/qemu-arm.dts > >> create mode 100644 arch/arm/dts/qemu-arm64.dts > >> create mode 100644 arch/arm/dts/xenguest-arm64.dts > >> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts > >> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts > >> delete mode 100644 arch/riscv/dts/qemu-virt.dts > >> create mode 100644 arch/riscv/dts/qemu-virt32.dts > >> create mode 100644 arch/riscv/dts/qemu-virt64.dts > >> create mode 100644 doc/develop/devicetree/dt_qemu.rst > >> create mode 100644 doc/develop/devicetree/dt_update.rst > >> > >> -- > >> 2.33.0.1079.g6e70778dc9-goog > >> > > -- > > François-Frédéric Ozog | Director Business Development > > T: +33.67221.6485 > > francois.ozog@linaro.org | Skype: ffozog > > >
Hi, On 27.10.2021 17.08, Simon Glass wrote: > Hi François, > > On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: >> >> Hi Simon >> >> Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. > > I think we are going to have to disagree on this one. I actually used > the qemu one in testing/development recently. We have to have a way to > develop in-tree with U-Boot. It does not impinge on any of your use > cases, so far as I know. > How about having the file just contain a single line #include <generated-qemu-arm.dts> ... where this generated-*.dts is not checked to the source tree. Then of course comments on how to generate it via qemu -dumpdtb + dtc, with appropriate precautions (ie. must be regenerated if qemu command line is changed or qemu is upgraded), intended use case, and so forth.
On Wed, Oct 27, 2021 at 08:08:19AM -0600, Simon Glass wrote: > Hi François, > > On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: > > > > Hi Simon > > > > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. > > I think we are going to have to disagree on this one. I'm not convinced either that we want or should have checked in device trees for all of the platforms where the source of truth is elsewhere. > I actually used > the qemu one in testing/development recently. We have to have a way to > develop in-tree with U-Boot. It does not impinge on any of your use > cases, so far as I know. It's certainly true that the "edit, rebuild, re-pass the dtb" cycle has been sub-optimal since inception. It's not even U-Boot related. I can count a number of times recently working with customers and just for Linux, having to spend a number of hours on the edit, rebuild, really make sure it gets populated where it's supposed to go, verify that yes really our modified dtb is the one present cycle. It's a very generic problem.
Hi François, On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog@linaro.org> wrote: > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: >> >> Hi François, >> >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: >> > >> > Hi Simon >> > >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. >> >> I think we are going to have to disagree on this one. I actually used >> the qemu one in testing/development recently. We have to have a way to >> develop in-tree with U-Boot. It does not impinge on any of your use >> cases, so far as I know. > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. > I understand the advanced debug/development scenario you mention. > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on. We can add a message to U-Boot indicating where the devicetree came from, perhaps? That might be useful given everything that is going on. As in this case, quite often in these discussions I struggle to understand what is behind the objection. Is it that your customers are demanding that devicetrees become private, secret data, not included in open-source projects? Or is it just the strange case of QEMU that is informing your thinking? I know of at least one project where the first-stage bootloader produces a devicetree and no one has the source for it. I believe TF-A was created for licensing reasons...so can you be a bit clearer about what the problem actually is? If a board is in-tree in U-Boot I would like it to have a devicetree there, at least until we have a better option. At the very least, it MUST be discoverable and it must be possible to undertake U-Boot development easily without a lot of messing around. >> >> >> But trying to do any driver / core work for a board where you don't >> have the devicetree is currently not possible. The devicetree is a >> core component and being unable to modify it is simply not practical. >> We are talking here about an option that can be enabled or disabled. >> In my case I am able to disable it locally and do my development work. >> >> >> BTW I've got the bloblist handoff working with a devicetree inside it, >> for qemu_arm. I need to try it on a real board to figure out what the >> difference is. >> > That's great news and much needed for stabilizing the inbound ABI from prior loader to U-Boot. Let's create another thread to discuss this important topic. >> My scenario is not all that advanced and I am using qemu_arm to test the bloblist handoff stuff and include it in CI, with a suitable devicetree and a binman node. Regards, Simon >> > >> > Cheers >> > >> > FF >> > >> > Le mar. 26 oct. 2021 à 02:24, Simon Glass <sjg@chromium.org> a écrit : >> >> >> >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so >> >> there are only three ways to obtain a devicetree: >> >> >> >> - OF_SEPARATE - the normal way, where the devicetree is built and >> >> appended to U-Boot >> >> - OF_EMBED - for development purposes, the devicetree is embedded in >> >> the ELF file (also used for EFI) >> >> - OF_BOARD - the board figures it out on its own >> >> >> >> The last one is currently set up so that no devicetree is needed at all >> >> in the U-Boot tree. Most boards do provide one, but some don't. Some >> >> don't even provide instructions on how to boot on the board. >> >> >> >> The problems with this approach are documented in another patch in this >> >> series: "doc: Add documentation about devicetree usage" >> >> >> >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board >> >> can obtain its devicetree at runtime, even it is has a devicetree built >> >> in U-Boot. This is because U-Boot may be a second-stage bootloader and its >> >> caller may have a better idea about the hardware available in the machine. >> >> This is the case with a few QEMU boards, for example. >> >> >> >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an >> >> option, available with either OF_SEPARATE or OF_EMBED. >> >> >> >> This series makes this change, adding various missing devicetree files >> >> (and placeholders) to make the build work. >> >> >> >> Note: If board maintainers are able to add their own patch to add the >> >> files, some patches in this series can be dropped. >> >> >> >> It also provides a few qemu clean-ups discovered along the way. >> >> >> >> Note: This breaks the qemu-riscv64_spl test, which still needs >> >> investigation. >> >> >> >> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ >> >> >> >> Changes in v5: >> >> - Bring into the OF_BOARD series >> >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed >> >> - Refer to the 'control' DTB in the first paragraph >> >> - Use QEMU instead of qemu >> >> - Merge RISC-V and ARM patches since they are similar >> >> - Add new patches to clean up fdtdec_setup() and surrounds >> >> >> >> Changes in v3: >> >> - Clarify the 'bug' refered to at the top >> >> - Reword 'This means that there' paragraph to explain U-Boot-specific things >> >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs >> >> >> >> Changes in v2: >> >> - Fix typos per Sean (thank you!) and a few others >> >> - Add a 'Use of U-Boot /config node' section >> >> - Drop mention of dm-verity since that actually uses the kernel cmdline >> >> - Explain that OF_BOARD will still work after these changes (in >> >> 'Once this bug is fixed...' paragraph) >> >> - Expand a bit on the reason why the 'Current situation' is bad >> >> - Clarify in a second place that Linux and U-Boot use the same devicetree >> >> in 'To be clear, while U-Boot...' >> >> - Expand on why we should have rules for other projects in >> >> 'Devicetree in another project' >> >> - Add a comment as to why devicetree in U-Boot is not 'bad design' >> >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' >> >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover >> >> points raised on v1 >> >> - Add 'Why does U-Boot have its nodes and properties?' >> >> - Add 'Why not have two devicetrees?' >> >> >> >> Ilias Apalodimas (1): >> >> sandbox: Remove OF_HOSTFILE >> >> >> >> Simon Glass (25): >> >> doc: Add documentation about devicetree usage >> >> arm: qemu: Mention -nographic in the docs >> >> arm: riscv: qemu: Explain how to extract the generated dt >> >> arm: qemu: Add a devicetree file for qemu_arm >> >> arm: qemu: Add a devicetree file for qemu_arm64 >> >> riscv: qemu: Add devicetree files for qemu_riscv32/64 >> >> arm: rpi: Add a devicetree file for rpi_4 >> >> arm: vexpress: Add a devicetree file for juno >> >> arm: xenguest_arm64: Add a fake devicetree file >> >> arm: octeontx: Add a fake devicetree file >> >> arm: xilinx_versal_virt: Add a devicetree file >> >> arm: bcm7xxx: Add a devicetree file >> >> arm: qemu-ppce500: Add a devicetree file >> >> arm: highbank: Add a fake devicetree file >> >> fdt: Make OF_BOARD a bool option >> >> Drop CONFIG_BINMAN_STANDALONE_FDT >> >> doc: Update info on devicetree update >> >> fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() >> >> fdt: Drop #ifdefs with MULTI_DTB_FIT >> >> fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() >> >> fdt: Drop #ifdef around board_fdt_blob_setup() >> >> fdt: Use if() for fdtcontroladdr check >> >> fdt: Drop OF_CONTROL check in fdtdec_setup() >> >> fdt: Drop remaining preprocessor macros in fdtdec_setup() >> >> fdt: Don't call board_fdt_blob_setup() without OF_BOARD >> >> >> >> Makefile | 7 +- >> >> arch/arm/dts/Makefile | 20 +- >> >> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 +++++++++++++++++++++ >> >> arch/arm/dts/bcm7xxx.dts | 15 + >> >> arch/arm/dts/highbank.dts | 14 + >> >> arch/arm/dts/juno-r2.dts | 1038 +++++++++++ >> >> arch/arm/dts/octeontx.dts | 14 + >> >> arch/arm/dts/qemu-arm.dts | 402 +++++ >> >> arch/arm/dts/qemu-arm64.dts | 381 ++++ >> >> arch/arm/dts/xenguest-arm64.dts | 15 + >> >> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ >> >> arch/powerpc/dts/Makefile | 1 + >> >> arch/powerpc/dts/qemu-ppce500.dts | 264 +++ >> >> arch/riscv/dts/Makefile | 2 +- >> >> arch/riscv/dts/qemu-virt.dts | 8 - >> >> arch/riscv/dts/qemu-virt32.dts | 217 +++ >> >> arch/riscv/dts/qemu-virt64.dts | 217 +++ >> >> arch/sandbox/cpu/cpu.c | 21 +- >> >> arch/sandbox/include/asm/u-boot-sandbox.h | 8 - >> >> configs/bcm7260_defconfig | 1 + >> >> configs/bcm7445_defconfig | 1 + >> >> configs/highbank_defconfig | 2 +- >> >> configs/octeontx2_95xx_defconfig | 1 + >> >> configs/octeontx2_96xx_defconfig | 1 + >> >> configs/octeontx_81xx_defconfig | 1 + >> >> configs/octeontx_83xx_defconfig | 1 + >> >> configs/qemu-ppce500_defconfig | 2 + >> >> configs/qemu-riscv32_defconfig | 1 + >> >> configs/qemu-riscv32_smode_defconfig | 1 + >> >> configs/qemu-riscv32_spl_defconfig | 4 +- >> >> configs/qemu-riscv64_defconfig | 1 + >> >> configs/qemu-riscv64_smode_defconfig | 1 + >> >> configs/qemu-riscv64_spl_defconfig | 3 +- >> >> configs/qemu_arm64_defconfig | 1 + >> >> configs/qemu_arm_defconfig | 1 + >> >> configs/rpi_4_32b_defconfig | 1 + >> >> configs/rpi_4_defconfig | 1 + >> >> configs/rpi_arm64_defconfig | 1 + >> >> configs/sandbox64_defconfig | 2 +- >> >> configs/sandbox_defconfig | 2 +- >> >> configs/sandbox_flattree_defconfig | 2 +- >> >> configs/sandbox_noinst_defconfig | 2 +- >> >> configs/sandbox_spl_defconfig | 2 +- >> >> configs/tools-only_defconfig | 2 +- >> >> configs/vexpress_aemv8a_juno_defconfig | 1 + >> >> configs/xenguest_arm64_defconfig | 1 + >> >> configs/xilinx_versal_virt_defconfig | 1 + >> >> doc/board/emulation/qemu-arm.rst | 10 +- >> >> doc/board/emulation/qemu-riscv.rst | 3 + >> >> doc/develop/devicetree/control.rst | 7 +- >> >> doc/develop/devicetree/dt_qemu.rst | 48 + >> >> doc/develop/devicetree/dt_update.rst | 498 ++++++ >> >> doc/develop/devicetree/index.rst | 2 + >> >> dts/Kconfig | 37 +- >> >> include/asm-generic/global_data.h | 8 + >> >> include/fdtdec.h | 21 +- >> >> lib/fdtdec.c | 116 +- >> >> scripts/Makefile.spl | 4 +- >> >> tools/binman/binman.rst | 20 - >> >> 59 files changed, 5560 insertions(+), 164 deletions(-) >> >> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts >> >> create mode 100644 arch/arm/dts/bcm7xxx.dts >> >> create mode 100644 arch/arm/dts/highbank.dts >> >> create mode 100644 arch/arm/dts/juno-r2.dts >> >> create mode 100644 arch/arm/dts/octeontx.dts >> >> create mode 100644 arch/arm/dts/qemu-arm.dts >> >> create mode 100644 arch/arm/dts/qemu-arm64.dts >> >> create mode 100644 arch/arm/dts/xenguest-arm64.dts >> >> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts >> >> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts >> >> delete mode 100644 arch/riscv/dts/qemu-virt.dts >> >> create mode 100644 arch/riscv/dts/qemu-virt32.dts >> >> create mode 100644 arch/riscv/dts/qemu-virt64.dts >> >> create mode 100644 doc/develop/devicetree/dt_qemu.rst >> >> create mode 100644 doc/develop/devicetree/dt_update.rst >> >> >> >> -- >> >> 2.33.0.1079.g6e70778dc9-goog >> >> >> > -- >> > François-Frédéric Ozog | Director Business Development >> > T: +33.67221.6485 >> > francois.ozog@linaro.org | Skype: ffozog >> > > > > > -- > François-Frédéric Ozog | Director Business Development > T: +33.67221.6485 > francois.ozog@linaro.org | Skype: ffozog >
On Wed, Oct 27, 2021 at 08:08:19AM -0600, Simon Glass wrote: [snip] > But trying to do any driver / core work for a board where you don't > have the devicetree is currently not possible. The devicetree is a > core component and being unable to modify it is simply not practical. > We are talking here about an option that can be enabled or disabled. > In my case I am able to disable it locally and do my development work. This certainly is an area where it's easier to work on arm32 platforms, where we aren't getting the DT passed in, than arm64, where we almost certainly are.
On Wed, Oct 27, 2021 at 06:36:12PM +0300, Tuomas Tynkkynen wrote: > Hi, > > On 27.10.2021 17.08, Simon Glass wrote: > > Hi François, > > > > On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > Hi Simon > > > > > > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. > > > > I think we are going to have to disagree on this one. I actually used > > the qemu one in testing/development recently. We have to have a way to > > develop in-tree with U-Boot. It does not impinge on any of your use > > cases, so far as I know. > > > > How about having the file just contain a single line > > #include <generated-qemu-arm.dts> > > ... where this generated-*.dts is not checked to the source tree. Then of > course comments on how to generate it via qemu -dumpdtb + dtc, with > appropriate precautions (ie. must be regenerated if qemu command line is > changed or qemu is upgraded), intended use case, and so forth. That seems like it would help the development workflow, yes.
On Wed, Oct 27, 2021 at 12:23:21PM -0600, Simon Glass wrote: > Hi François, > > On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: > >> > >> Hi François, > >> > >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: > >> > > >> > Hi Simon > >> > > >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. > >> > >> I think we are going to have to disagree on this one. I actually used > >> the qemu one in testing/development recently. We have to have a way to > >> develop in-tree with U-Boot. It does not impinge on any of your use > >> cases, so far as I know. > > > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. > > I understand the advanced debug/development scenario you mention. > > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. > > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > has noticed. U-Boot handles the build automatically. If you turn off > OF_BOARD, it will use the U-Boot devicetree always so you know what is > going on. That we have to have so many separate rpi build targets, and can't just use rpm_arm64 and add rpi_arm32 is not a good feature. The various rpi configs that use CONFIG_OF_EMBED are on your list of things that need to be cleaned up, yes? > We can add a message to U-Boot indicating where the devicetree came > from, perhaps? That might be useful given everything that is going on. > > As in this case, quite often in these discussions I struggle to > understand what is behind the objection. Is it that your customers are > demanding that devicetrees become private, secret data, not included > in open-source projects? Or is it just the strange case of QEMU that > is informing your thinking? I know of at least one project where the > first-stage bootloader produces a devicetree and no one has the source > for it. I believe TF-A was created for licensing reasons...so can you > be a bit clearer about what the problem actually is? If a board is > in-tree in U-Boot I would like it to have a devicetree there, at least > until we have a better option. At the very least, it MUST be > discoverable and it must be possible to undertake U-Boot development > easily without a lot of messing around. What I don't understand here is why or how U-Boot is supposed to become the source of truth for device trees. The general goal is that the device tree be something that actually comes along on the hardware, because it's stable enough and correct enough that it's not going to be changed from one OS kernel release to the next. That should be where the correct and true tree comes from, the device itself.
Hi Simon Le mer. 27 oct. 2021 à 20:23, Simon Glass <sjg@chromium.org> a écrit : > Hi François, > > On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog@linaro.org> > wrote: > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: > >> > >> Hi François, > >> > >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> > wrote: > >> > > >> > Hi Simon > >> > > >> > Position unchanged on this series: adding fake dts for boards that > generate their device tree in the dts directory is not good. If you have > them in documentation the it is acceptable. > >> > >> I think we are going to have to disagree on this one. I actually used > >> the qemu one in testing/development recently. We have to have a way to > >> develop in-tree with U-Boot. It does not impinge on any of your use > >> cases, so far as I know. > > > > I am not the only one in disagreement... You just saw Alex Bénée from > Qemu saying the same thing. > > I understand the advanced debug/development scenario you mention. > > But locating the DT files in the dts directory is mis-leading the > contributors to think that they need to compile the DT for the targeted > platforms. > > For your advanced scenario, you can still have the dts in the > documentation area, or whatever directory (except dts). compile it and > supply to U-Boot. > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > has noticed. U-Boot handles the build automatically. If you turn off > OF_BOARD, it will use the U-Boot devicetree always so you know what is > going on. > > We can add a message to U-Boot indicating where the devicetree came > from, perhaps? That might be useful given everything that is going on. > > As in this case, quite often in these discussions I struggle to > understand what is behind the objection. Is it that your customers are > demanding that devicetrees become private, secret data, not included > in open-source projects? Or is it just the strange case of QEMU that > is informing your thinking? I know of at least one project where the > first-stage bootloader produces a devicetree and no one has the source > for it. I believe TF-A was created for licensing reasons...so can you > be a bit clearer about what the problem actually is? there are situations where U-Boot must have a dtb. Then those dTB sources are logically found in the dts directory. There are situations where U-Boot should not have a dtb. In that case there should be no element in the dts directory. Otherwise it creates confusion. Now as you point out, we need “playgrounds” to deal with some situation. So having examples in an ad-hoc directory, different from dts is fine. I proposed documentation but you may find a better place. In other words, dts shall host only dt source when U-Boot cannot do but make a dTB for a platform. As you have seen in different mail thread (firmware sustainability and OCP checklist) freedom is important to Linaro and there are no hidden Trojan horse for licensing. If a board is > in-tree in U-Boot I would like it to have a devicetree there, at least > until we have a better option. At the very least, it MUST be > discoverable and it must be possible to undertake U-Boot development > easily without a lot of messing around. You can if you keep two dts directories separate: dts for boards for which U-Boot must have one debug-dts for boards for which U-Boot get the DT at runtime but for which you want a playground for debug/easier development. > > >> > >> > >> But trying to do any driver / core work for a board where you don't > >> have the devicetree is currently not possible. The devicetree is a > >> core component and being unable to modify it is simply not practical. > >> We are talking here about an option that can be enabled or disabled. > >> In my case I am able to disable it locally and do my development work. > >> > >> > >> BTW I've got the bloblist handoff working with a devicetree inside it, > >> for qemu_arm. I need to try it on a real board to figure out what the > >> difference is. > >> > > That's great news and much needed for stabilizing the inbound ABI from > prior loader to U-Boot. Let's create another thread to discuss this > important topic. > >> > > My scenario is not all that advanced and I am using qemu_arm to test > the bloblist handoff stuff and include it in CI, with a suitable > devicetree and a binman node. > > Regards, > Simon > > >> > > >> > Cheers > >> > > >> > FF > >> > > >> > Le mar. 26 oct. 2021 à 02:24, Simon Glass <sjg@chromium.org> a écrit > : > >> >> > >> >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > >> >> there are only three ways to obtain a devicetree: > >> >> > >> >> - OF_SEPARATE - the normal way, where the devicetree is built and > >> >> appended to U-Boot > >> >> - OF_EMBED - for development purposes, the devicetree is embedded > in > >> >> the ELF file (also used for EFI) > >> >> - OF_BOARD - the board figures it out on its own > >> >> > >> >> The last one is currently set up so that no devicetree is needed at > all > >> >> in the U-Boot tree. Most boards do provide one, but some don't. Some > >> >> don't even provide instructions on how to boot on the board. > >> >> > >> >> The problems with this approach are documented in another patch in > this > >> >> series: "doc: Add documentation about devicetree usage" > >> >> > >> >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > board > >> >> can obtain its devicetree at runtime, even it is has a devicetree > built > >> >> in U-Boot. This is because U-Boot may be a second-stage bootloader > and its > >> >> caller may have a better idea about the hardware available in the > machine. > >> >> This is the case with a few QEMU boards, for example. > >> >> > >> >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an > >> >> option, available with either OF_SEPARATE or OF_EMBED. > >> >> > >> >> This series makes this change, adding various missing devicetree > files > >> >> (and placeholders) to make the build work. > >> >> > >> >> Note: If board maintainers are able to add their own patch to add the > >> >> files, some patches in this series can be dropped. > >> >> > >> >> It also provides a few qemu clean-ups discovered along the way. > >> >> > >> >> Note: This breaks the qemu-riscv64_spl test, which still needs > >> >> investigation. > >> >> > >> >> [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > >> >> > >> >> Changes in v5: > >> >> - Bring into the OF_BOARD series > >> >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > >> >> - Refer to the 'control' DTB in the first paragraph > >> >> - Use QEMU instead of qemu > >> >> - Merge RISC-V and ARM patches since they are similar > >> >> - Add new patches to clean up fdtdec_setup() and surrounds > >> >> > >> >> Changes in v3: > >> >> - Clarify the 'bug' refered to at the top > >> >> - Reword 'This means that there' paragraph to explain > U-Boot-specific things > >> >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > >> >> > >> >> Changes in v2: > >> >> - Fix typos per Sean (thank you!) and a few others > >> >> - Add a 'Use of U-Boot /config node' section > >> >> - Drop mention of dm-verity since that actually uses the kernel > cmdline > >> >> - Explain that OF_BOARD will still work after these changes (in > >> >> 'Once this bug is fixed...' paragraph) > >> >> - Expand a bit on the reason why the 'Current situation' is bad > >> >> - Clarify in a second place that Linux and U-Boot use the same > devicetree > >> >> in 'To be clear, while U-Boot...' > >> >> - Expand on why we should have rules for other projects in > >> >> 'Devicetree in another project' > >> >> - Add a comment as to why devicetree in U-Boot is not 'bad design' > >> >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > >> >> - Rewrite 'Devicetree generated on-the-fly in another project' to > cover > >> >> points raised on v1 > >> >> - Add 'Why does U-Boot have its nodes and properties?' > >> >> - Add 'Why not have two devicetrees?' > >> >> > >> >> Ilias Apalodimas (1): > >> >> sandbox: Remove OF_HOSTFILE > >> >> > >> >> Simon Glass (25): > >> >> doc: Add documentation about devicetree usage > >> >> arm: qemu: Mention -nographic in the docs > >> >> arm: riscv: qemu: Explain how to extract the generated dt > >> >> arm: qemu: Add a devicetree file for qemu_arm > >> >> arm: qemu: Add a devicetree file for qemu_arm64 > >> >> riscv: qemu: Add devicetree files for qemu_riscv32/64 > >> >> arm: rpi: Add a devicetree file for rpi_4 > >> >> arm: vexpress: Add a devicetree file for juno > >> >> arm: xenguest_arm64: Add a fake devicetree file > >> >> arm: octeontx: Add a fake devicetree file > >> >> arm: xilinx_versal_virt: Add a devicetree file > >> >> arm: bcm7xxx: Add a devicetree file > >> >> arm: qemu-ppce500: Add a devicetree file > >> >> arm: highbank: Add a fake devicetree file > >> >> fdt: Make OF_BOARD a bool option > >> >> Drop CONFIG_BINMAN_STANDALONE_FDT > >> >> doc: Update info on devicetree update > >> >> fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() > >> >> fdt: Drop #ifdefs with MULTI_DTB_FIT > >> >> fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() > >> >> fdt: Drop #ifdef around board_fdt_blob_setup() > >> >> fdt: Use if() for fdtcontroladdr check > >> >> fdt: Drop OF_CONTROL check in fdtdec_setup() > >> >> fdt: Drop remaining preprocessor macros in fdtdec_setup() > >> >> fdt: Don't call board_fdt_blob_setup() without OF_BOARD > >> >> > >> >> Makefile | 7 +- > >> >> arch/arm/dts/Makefile | 20 +- > >> >> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 > +++++++++++++++++++++ > >> >> arch/arm/dts/bcm7xxx.dts | 15 + > >> >> arch/arm/dts/highbank.dts | 14 + > >> >> arch/arm/dts/juno-r2.dts | 1038 +++++++++++ > >> >> arch/arm/dts/octeontx.dts | 14 + > >> >> arch/arm/dts/qemu-arm.dts | 402 +++++ > >> >> arch/arm/dts/qemu-arm64.dts | 381 ++++ > >> >> arch/arm/dts/xenguest-arm64.dts | 15 + > >> >> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ > >> >> arch/powerpc/dts/Makefile | 1 + > >> >> arch/powerpc/dts/qemu-ppce500.dts | 264 +++ > >> >> arch/riscv/dts/Makefile | 2 +- > >> >> arch/riscv/dts/qemu-virt.dts | 8 - > >> >> arch/riscv/dts/qemu-virt32.dts | 217 +++ > >> >> arch/riscv/dts/qemu-virt64.dts | 217 +++ > >> >> arch/sandbox/cpu/cpu.c | 21 +- > >> >> arch/sandbox/include/asm/u-boot-sandbox.h | 8 - > >> >> configs/bcm7260_defconfig | 1 + > >> >> configs/bcm7445_defconfig | 1 + > >> >> configs/highbank_defconfig | 2 +- > >> >> configs/octeontx2_95xx_defconfig | 1 + > >> >> configs/octeontx2_96xx_defconfig | 1 + > >> >> configs/octeontx_81xx_defconfig | 1 + > >> >> configs/octeontx_83xx_defconfig | 1 + > >> >> configs/qemu-ppce500_defconfig | 2 + > >> >> configs/qemu-riscv32_defconfig | 1 + > >> >> configs/qemu-riscv32_smode_defconfig | 1 + > >> >> configs/qemu-riscv32_spl_defconfig | 4 +- > >> >> configs/qemu-riscv64_defconfig | 1 + > >> >> configs/qemu-riscv64_smode_defconfig | 1 + > >> >> configs/qemu-riscv64_spl_defconfig | 3 +- > >> >> configs/qemu_arm64_defconfig | 1 + > >> >> configs/qemu_arm_defconfig | 1 + > >> >> configs/rpi_4_32b_defconfig | 1 + > >> >> configs/rpi_4_defconfig | 1 + > >> >> configs/rpi_arm64_defconfig | 1 + > >> >> configs/sandbox64_defconfig | 2 +- > >> >> configs/sandbox_defconfig | 2 +- > >> >> configs/sandbox_flattree_defconfig | 2 +- > >> >> configs/sandbox_noinst_defconfig | 2 +- > >> >> configs/sandbox_spl_defconfig | 2 +- > >> >> configs/tools-only_defconfig | 2 +- > >> >> configs/vexpress_aemv8a_juno_defconfig | 1 + > >> >> configs/xenguest_arm64_defconfig | 1 + > >> >> configs/xilinx_versal_virt_defconfig | 1 + > >> >> doc/board/emulation/qemu-arm.rst | 10 +- > >> >> doc/board/emulation/qemu-riscv.rst | 3 + > >> >> doc/develop/devicetree/control.rst | 7 +- > >> >> doc/develop/devicetree/dt_qemu.rst | 48 + > >> >> doc/develop/devicetree/dt_update.rst | 498 ++++++ > >> >> doc/develop/devicetree/index.rst | 2 + > >> >> dts/Kconfig | 37 +- > >> >> include/asm-generic/global_data.h | 8 + > >> >> include/fdtdec.h | 21 +- > >> >> lib/fdtdec.c | 116 +- > >> >> scripts/Makefile.spl | 4 +- > >> >> tools/binman/binman.rst | 20 - > >> >> 59 files changed, 5560 insertions(+), 164 deletions(-) > >> >> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > >> >> create mode 100644 arch/arm/dts/bcm7xxx.dts > >> >> create mode 100644 arch/arm/dts/highbank.dts > >> >> create mode 100644 arch/arm/dts/juno-r2.dts > >> >> create mode 100644 arch/arm/dts/octeontx.dts > >> >> create mode 100644 arch/arm/dts/qemu-arm.dts > >> >> create mode 100644 arch/arm/dts/qemu-arm64.dts > >> >> create mode 100644 arch/arm/dts/xenguest-arm64.dts > >> >> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts > >> >> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts > >> >> delete mode 100644 arch/riscv/dts/qemu-virt.dts > >> >> create mode 100644 arch/riscv/dts/qemu-virt32.dts > >> >> create mode 100644 arch/riscv/dts/qemu-virt64.dts > >> >> create mode 100644 doc/develop/devicetree/dt_qemu.rst > >> >> create mode 100644 doc/develop/devicetree/dt_update.rst > >> >> > >> >> -- > >> >> 2.33.0.1079.g6e70778dc9-goog > >> >> > >> > -- > >> > François-Frédéric Ozog | Director Business Development > >> > T: +33.67221.6485 > >> > francois.ozog@linaro.org | Skype: ffozog > >> > > > > > > > > > -- > > François-Frédéric Ozog | Director Business Development > > T: +33.67221.6485 > > francois.ozog@linaro.org | Skype: ffozog > > >
> From: Simon Glass <sjg@chromium.org> > Date: Wed, 27 Oct 2021 12:23:21 -0600 > > Hi François, > > On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: > >> > >> Hi François, > >> > >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: > >> > > >> > Hi Simon > >> > > >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. > >> > >> I think we are going to have to disagree on this one. I actually used > >> the qemu one in testing/development recently. We have to have a way to > >> develop in-tree with U-Boot. It does not impinge on any of your use > >> cases, so far as I know. > > > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. > > I understand the advanced debug/development scenario you mention. > > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. > > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > has noticed. U-Boot handles the build automatically. If you turn off > OF_BOARD, it will use the U-Boot devicetree always so you know what is > going on. Until. The Raspberry Pi foundation releases a new firmware that configures the hardware differently such that the addresses in the U-Boot devicetree are wrong and nothing works anymore. Can't speak for the rpi 1, but this has happened in the past for the rpi 2 and 3 as well as more recently on the rpi 4. > We can add a message to U-Boot indicating where the devicetree came > from, perhaps? That might be useful given everything that is going on. > > As in this case, quite often in these discussions I struggle to > understand what is behind the objection. Is it that your customers are > demanding that devicetrees become private, secret data, not included > in open-source projects? Or is it just the strange case of QEMU that > is informing your thinking? I know of at least one project where the > first-stage bootloader produces a devicetree and no one has the source > for it. I believe TF-A was created for licensing reasons...so can you > be a bit clearer about what the problem actually is? If a board is > in-tree in U-Boot I would like it to have a devicetree there, at least > until we have a better option. At the very least, it MUST be > discoverable and it must be possible to undertake U-Boot development > easily without a lot of messing around. How many people are there out there that work on U-Boot that don't have a Linux source tree checked out? Even I have several of those lying around on my development systems and I am an OpenBSD developer ;).
Hi François, On Wed, 27 Oct 2021 at 14:07, François Ozog <francois.ozog@linaro.org> wrote: > > Hi Simon > > Le mer. 27 oct. 2021 à 20:23, Simon Glass <sjg@chromium.org> a écrit : >> >> Hi François, >> >> On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog@linaro.org> wrote: >> > >> > >> > >> > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: >> >> >> >> Hi François, >> >> >> >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: >> >> > >> >> > Hi Simon >> >> > >> >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. >> >> >> >> I think we are going to have to disagree on this one. I actually used >> >> the qemu one in testing/development recently. We have to have a way to >> >> develop in-tree with U-Boot. It does not impinge on any of your use >> >> cases, so far as I know. >> > >> > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. >> > I understand the advanced debug/development scenario you mention. >> > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. >> > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. >> >> We have this situation with rpi 1, 2 and 3 and I don't believe anyone >> has noticed. U-Boot handles the build automatically. If you turn off >> OF_BOARD, it will use the U-Boot devicetree always so you know what is >> going on. >> >> We can add a message to U-Boot indicating where the devicetree came >> from, perhaps? That might be useful given everything that is going on. >> >> As in this case, quite often in these discussions I struggle to >> understand what is behind the objection. Is it that your customers are >> demanding that devicetrees become private, secret data, not included >> in open-source projects? Or is it just the strange case of QEMU that >> is informing your thinking? I know of at least one project where the >> first-stage bootloader produces a devicetree and no one has the source >> for it. I believe TF-A was created for licensing reasons...so can you >> be a bit clearer about what the problem actually is? > > there are situations where U-Boot must have a dtb. Then those dTB sources are logically found in the dts directory. > There are situations where U-Boot should not have a dtb. In that case there should be no element in the dts directory. Otherwise it creates confusion. > Now as you point out, we need “playgrounds” to deal with some situation. So having examples in an ad-hoc directory, different from dts is fine. I proposed documentation but you may find a better place. > In other words, dts shall host only dt source when U-Boot cannot do but make a dTB for a platform. > As you have seen in different mail thread (firmware sustainability and OCP checklist) freedom is important to Linaro and there are no hidden Trojan horse for licensing. I don't understand what you are getting at with the Trojan horse. But you have no objection to requiring boards to supply a DT (whether in documentation or arch/arm/dts) to be in U-Boot? > > >> If a board is >> in-tree in U-Boot I would like it to have a devicetree there, at least >> until we have a better option. At the very least, it MUST be >> discoverable and it must be possible to undertake U-Boot development >> easily without a lot of messing around. > > You can if you keep two dts directories separate: > dts for boards for which U-Boot must have one > debug-dts for boards for which U-Boot get the DT at runtime but for which you want a playground for debug/easier development. >> >> >> >> >> >> >> >> But trying to do any driver / core work for a board where you don't >> >> have the devicetree is currently not possible. The devicetree is a >> >> core component and being unable to modify it is simply not practical. >> >> We are talking here about an option that can be enabled or disabled. >> >> In my case I am able to disable it locally and do my development work. >> >> >> >> >> >> BTW I've got the bloblist handoff working with a devicetree inside it, >> >> for qemu_arm. I need to try it on a real board to figure out what the >> >> difference is. >> >> >> > That's great news and much needed for stabilizing the inbound ABI from prior loader to U-Boot. Let's create another thread to discuss this important topic. >> >> >> >> My scenario is not all that advanced and I am using qemu_arm to test >> the bloblist handoff stuff and include it in CI, with a suitable >> devicetree and a binman node. >> >> Regards, >> Simon >> >> >> > >> >> > Cheers >> >> > >> >> > FF >> >> > >> >> > Le mar. 26 oct. 2021 à 02:24, Simon Glass <sjg@chromium.org> a écrit : >> >> >> >> >> >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so >> >> >> there are only three ways to obtain a devicetree: >> >> >> >> >> >> - OF_SEPARATE - the normal way, where the devicetree is built and >> >> >> appended to U-Boot >> >> >> - OF_EMBED - for development purposes, the devicetree is embedded in >> >> >> the ELF file (also used for EFI) >> >> >> - OF_BOARD - the board figures it out on its own >> >> >> >> >> >> The last one is currently set up so that no devicetree is needed at all >> >> >> in the U-Boot tree. Most boards do provide one, but some don't. Some >> >> >> don't even provide instructions on how to boot on the board. >> >> >> >> >> >> The problems with this approach are documented in another patch in this >> >> >> series: "doc: Add documentation about devicetree usage" >> >> >> >> >> >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board >> >> >> can obtain its devicetree at runtime, even it is has a devicetree built >> >> >> in U-Boot. This is because U-Boot may be a second-stage bootloader and its >> >> >> caller may have a better idea about the hardware available in the machine. >> >> >> This is the case with a few QEMU boards, for example. >> >> >> >> >> >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an >> >> >> option, available with either OF_SEPARATE or OF_EMBED. >> >> >> >> >> >> This series makes this change, adding various missing devicetree files >> >> >> (and placeholders) to make the build work. >> >> >> >> >> >> Note: If board maintainers are able to add their own patch to add the >> >> >> files, some patches in this series can be dropped. >> >> >> >> >> >> It also provides a few qemu clean-ups discovered along the way. >> >> >> >> >> >> Note: This breaks the qemu-riscv64_spl test, which still needs >> >> >> investigation. >> >> >> >> >> >> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ >> >> >> >> >> >> Changes in v5: >> >> >> - Bring into the OF_BOARD series >> >> >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed >> >> >> - Refer to the 'control' DTB in the first paragraph >> >> >> - Use QEMU instead of qemu >> >> >> - Merge RISC-V and ARM patches since they are similar >> >> >> - Add new patches to clean up fdtdec_setup() and surrounds >> >> >> >> >> >> Changes in v3: >> >> >> - Clarify the 'bug' refered to at the top >> >> >> - Reword 'This means that there' paragraph to explain U-Boot-specific things >> >> >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs >> >> >> >> >> >> Changes in v2: >> >> >> - Fix typos per Sean (thank you!) and a few others >> >> >> - Add a 'Use of U-Boot /config node' section >> >> >> - Drop mention of dm-verity since that actually uses the kernel cmdline >> >> >> - Explain that OF_BOARD will still work after these changes (in >> >> >> 'Once this bug is fixed...' paragraph) >> >> >> - Expand a bit on the reason why the 'Current situation' is bad >> >> >> - Clarify in a second place that Linux and U-Boot use the same devicetree >> >> >> in 'To be clear, while U-Boot...' >> >> >> - Expand on why we should have rules for other projects in >> >> >> 'Devicetree in another project' >> >> >> - Add a comment as to why devicetree in U-Boot is not 'bad design' >> >> >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' >> >> >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover >> >> >> points raised on v1 >> >> >> - Add 'Why does U-Boot have its nodes and properties?' >> >> >> - Add 'Why not have two devicetrees?' >> >> >> >> >> >> Ilias Apalodimas (1): >> >> >> sandbox: Remove OF_HOSTFILE >> >> >> >> >> >> Simon Glass (25): >> >> >> doc: Add documentation about devicetree usage >> >> >> arm: qemu: Mention -nographic in the docs >> >> >> arm: riscv: qemu: Explain how to extract the generated dt >> >> >> arm: qemu: Add a devicetree file for qemu_arm >> >> >> arm: qemu: Add a devicetree file for qemu_arm64 >> >> >> riscv: qemu: Add devicetree files for qemu_riscv32/64 >> >> >> arm: rpi: Add a devicetree file for rpi_4 >> >> >> arm: vexpress: Add a devicetree file for juno >> >> >> arm: xenguest_arm64: Add a fake devicetree file >> >> >> arm: octeontx: Add a fake devicetree file >> >> >> arm: xilinx_versal_virt: Add a devicetree file >> >> >> arm: bcm7xxx: Add a devicetree file >> >> >> arm: qemu-ppce500: Add a devicetree file >> >> >> arm: highbank: Add a fake devicetree file >> >> >> fdt: Make OF_BOARD a bool option >> >> >> Drop CONFIG_BINMAN_STANDALONE_FDT >> >> >> doc: Update info on devicetree update >> >> >> fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() >> >> >> fdt: Drop #ifdefs with MULTI_DTB_FIT >> >> >> fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() >> >> >> fdt: Drop #ifdef around board_fdt_blob_setup() >> >> >> fdt: Use if() for fdtcontroladdr check >> >> >> fdt: Drop OF_CONTROL check in fdtdec_setup() >> >> >> fdt: Drop remaining preprocessor macros in fdtdec_setup() >> >> >> fdt: Don't call board_fdt_blob_setup() without OF_BOARD >> >> >> >> >> >> Makefile | 7 +- >> >> >> arch/arm/dts/Makefile | 20 +- >> >> >> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 +++++++++++++++++++++ >> >> >> arch/arm/dts/bcm7xxx.dts | 15 + >> >> >> arch/arm/dts/highbank.dts | 14 + >> >> >> arch/arm/dts/juno-r2.dts | 1038 +++++++++++ >> >> >> arch/arm/dts/octeontx.dts | 14 + >> >> >> arch/arm/dts/qemu-arm.dts | 402 +++++ >> >> >> arch/arm/dts/qemu-arm64.dts | 381 ++++ >> >> >> arch/arm/dts/xenguest-arm64.dts | 15 + >> >> >> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ >> >> >> arch/powerpc/dts/Makefile | 1 + >> >> >> arch/powerpc/dts/qemu-ppce500.dts | 264 +++ >> >> >> arch/riscv/dts/Makefile | 2 +- >> >> >> arch/riscv/dts/qemu-virt.dts | 8 - >> >> >> arch/riscv/dts/qemu-virt32.dts | 217 +++ >> >> >> arch/riscv/dts/qemu-virt64.dts | 217 +++ >> >> >> arch/sandbox/cpu/cpu.c | 21 +- >> >> >> arch/sandbox/include/asm/u-boot-sandbox.h | 8 - >> >> >> configs/bcm7260_defconfig | 1 + >> >> >> configs/bcm7445_defconfig | 1 + >> >> >> configs/highbank_defconfig | 2 +- >> >> >> configs/octeontx2_95xx_defconfig | 1 + >> >> >> configs/octeontx2_96xx_defconfig | 1 + >> >> >> configs/octeontx_81xx_defconfig | 1 + >> >> >> configs/octeontx_83xx_defconfig | 1 + >> >> >> configs/qemu-ppce500_defconfig | 2 + >> >> >> configs/qemu-riscv32_defconfig | 1 + >> >> >> configs/qemu-riscv32_smode_defconfig | 1 + >> >> >> configs/qemu-riscv32_spl_defconfig | 4 +- >> >> >> configs/qemu-riscv64_defconfig | 1 + >> >> >> configs/qemu-riscv64_smode_defconfig | 1 + >> >> >> configs/qemu-riscv64_spl_defconfig | 3 +- >> >> >> configs/qemu_arm64_defconfig | 1 + >> >> >> configs/qemu_arm_defconfig | 1 + >> >> >> configs/rpi_4_32b_defconfig | 1 + >> >> >> configs/rpi_4_defconfig | 1 + >> >> >> configs/rpi_arm64_defconfig | 1 + >> >> >> configs/sandbox64_defconfig | 2 +- >> >> >> configs/sandbox_defconfig | 2 +- >> >> >> configs/sandbox_flattree_defconfig | 2 +- >> >> >> configs/sandbox_noinst_defconfig | 2 +- >> >> >> configs/sandbox_spl_defconfig | 2 +- >> >> >> configs/tools-only_defconfig | 2 +- >> >> >> configs/vexpress_aemv8a_juno_defconfig | 1 + >> >> >> configs/xenguest_arm64_defconfig | 1 + >> >> >> configs/xilinx_versal_virt_defconfig | 1 + >> >> >> doc/board/emulation/qemu-arm.rst | 10 +- >> >> >> doc/board/emulation/qemu-riscv.rst | 3 + >> >> >> doc/develop/devicetree/control.rst | 7 +- >> >> >> doc/develop/devicetree/dt_qemu.rst | 48 + >> >> >> doc/develop/devicetree/dt_update.rst | 498 ++++++ >> >> >> doc/develop/devicetree/index.rst | 2 + >> >> >> dts/Kconfig | 37 +- >> >> >> include/asm-generic/global_data.h | 8 + >> >> >> include/fdtdec.h | 21 +- >> >> >> lib/fdtdec.c | 116 +- >> >> >> scripts/Makefile.spl | 4 +- >> >> >> tools/binman/binman.rst | 20 - >> >> >> 59 files changed, 5560 insertions(+), 164 deletions(-) >> >> >> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts >> >> >> create mode 100644 arch/arm/dts/bcm7xxx.dts >> >> >> create mode 100644 arch/arm/dts/highbank.dts >> >> >> create mode 100644 arch/arm/dts/juno-r2.dts >> >> >> create mode 100644 arch/arm/dts/octeontx.dts >> >> >> create mode 100644 arch/arm/dts/qemu-arm.dts >> >> >> create mode 100644 arch/arm/dts/qemu-arm64.dts >> >> >> create mode 100644 arch/arm/dts/xenguest-arm64.dts >> >> >> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts >> >> >> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts >> >> >> delete mode 100644 arch/riscv/dts/qemu-virt.dts >> >> >> create mode 100644 arch/riscv/dts/qemu-virt32.dts >> >> >> create mode 100644 arch/riscv/dts/qemu-virt64.dts >> >> >> create mode 100644 doc/develop/devicetree/dt_qemu.rst >> >> >> create mode 100644 doc/develop/devicetree/dt_update.rst >> >> >> >> >> >> -- >> >> >> 2.33.0.1079.g6e70778dc9-goog >> >> >> >> >> > -- >> >> > François-Frédéric Ozog | Director Business Development >> >> > T: +33.67221.6485 >> >> > francois.ozog@linaro.org | Skype: ffozog >> >> > >> > >> > >> > >> > -- >> > François-Frédéric Ozog | Director Business Development >> > T: +33.67221.6485 >> > francois.ozog@linaro.org | Skype: ffozog >> > > > -- > François-Frédéric Ozog | Director Business Development > T: +33.67221.6485 > francois.ozog@linaro.org | Skype: ffozog >
Hi Mark, On Wed, 27 Oct 2021 at 16:30, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > From: Simon Glass <sjg@chromium.org> > > Date: Wed, 27 Oct 2021 12:23:21 -0600 > > > > Hi François, > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: > > >> > > >> Hi François, > > >> > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: > > >> > > > >> > Hi Simon > > >> > > > >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. > > >> > > >> I think we are going to have to disagree on this one. I actually used > > >> the qemu one in testing/development recently. We have to have a way to > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > >> cases, so far as I know. > > > > > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. > > > I understand the advanced debug/development scenario you mention. > > > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. > > > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > has noticed. U-Boot handles the build automatically. If you turn off > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > going on. > > Until. The Raspberry Pi foundation releases a new firmware that > configures the hardware differently such that the addresses in the > U-Boot devicetree are wrong and nothing works anymore. Can't speak > for the rpi 1, but this has happened in the past for the rpi 2 and 3 > as well as more recently on the rpi 4. So I update my SD card with a new private-binary bootloader and things stop working? I think I can narrow that one down :-) > > > We can add a message to U-Boot indicating where the devicetree came > > from, perhaps? That might be useful given everything that is going on. > > > > As in this case, quite often in these discussions I struggle to > > understand what is behind the objection. Is it that your customers are > > demanding that devicetrees become private, secret data, not included > > in open-source projects? Or is it just the strange case of QEMU that > > is informing your thinking? I know of at least one project where the > > first-stage bootloader produces a devicetree and no one has the source > > for it. I believe TF-A was created for licensing reasons...so can you > > be a bit clearer about what the problem actually is? If a board is > > in-tree in U-Boot I would like it to have a devicetree there, at least > > until we have a better option. At the very least, it MUST be > > discoverable and it must be possible to undertake U-Boot development > > easily without a lot of messing around. > > How many people are there out there that work on U-Boot that don't > have a Linux source tree checked out? Even I have several of those > lying around on my development systems and I am an OpenBSD developer ;). So it is OK to have the DT in Linux but not in U-Boot? I don't even know what to say that. How does that square with your point above? I am not talking about disabling OF_BOARD, just making it *possible* to do so. Regards, Simon
Hi Simon Le mer. 3 nov. 2021 à 02:21, Simon Glass <sjg@chromium.org> a écrit : > Hi François, > > On Wed, 27 Oct 2021 at 14:07, François Ozog <francois.ozog@linaro.org> > wrote: > > > > Hi Simon > > > > Le mer. 27 oct. 2021 à 20:23, Simon Glass <sjg@chromium.org> a écrit : > >> > >> Hi François, > >> > >> On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog@linaro.org> > wrote: > >> > > >> > > >> > > >> > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: > >> >> > >> >> Hi François, > >> >> > >> >> On Tue, 26 Oct 2021 at 00:07, François Ozog < > francois.ozog@linaro.org> wrote: > >> >> > > >> >> > Hi Simon > >> >> > > >> >> > Position unchanged on this series: adding fake dts for boards that > generate their device tree in the dts directory is not good. If you have > them in documentation the it is acceptable. > >> >> > >> >> I think we are going to have to disagree on this one. I actually used > >> >> the qemu one in testing/development recently. We have to have a way > to > >> >> develop in-tree with U-Boot. It does not impinge on any of your use > >> >> cases, so far as I know. > >> > > >> > I am not the only one in disagreement... You just saw Alex Bénée from > Qemu saying the same thing. > >> > I understand the advanced debug/development scenario you mention. > >> > But locating the DT files in the dts directory is mis-leading the > contributors to think that they need to compile the DT for the targeted > platforms. > >> > For your advanced scenario, you can still have the dts in the > documentation area, or whatever directory (except dts). compile it and > supply to U-Boot. > >> > >> We have this situation with rpi 1, 2 and 3 and I don't believe anyone > >> has noticed. U-Boot handles the build automatically. If you turn off > >> OF_BOARD, it will use the U-Boot devicetree always so you know what is > >> going on. > >> > >> We can add a message to U-Boot indicating where the devicetree came > >> from, perhaps? That might be useful given everything that is going on. > >> > >> As in this case, quite often in these discussions I struggle to > >> understand what is behind the objection. Is it that your customers are > >> demanding that devicetrees become private, secret data, not included > >> in open-source projects? Or is it just the strange case of QEMU that > >> is informing your thinking? I know of at least one project where the > >> first-stage bootloader produces a devicetree and no one has the source > >> for it. I believe TF-A was created for licensing reasons...so can you > >> be a bit clearer about what the problem actually is? > > > > there are situations where U-Boot must have a dtb. Then those dTB > sources are logically found in the dts directory. > > There are situations where U-Boot should not have a dtb. In that case > there should be no element in the dts directory. Otherwise it creates > confusion. > > Now as you point out, we need “playgrounds” to deal with some situation. > So having examples in an ad-hoc directory, different from dts is fine. I > proposed documentation but you may find a better place. > > In other words, dts shall host only dt source when U-Boot cannot do but > make a dTB for a platform. > > As you have seen in different mail thread (firmware sustainability and > OCP checklist) freedom is important to Linaro and there are no hidden > Trojan horse for licensing. > > I don't understand what you are getting at with the Trojan horse. I was referring to your statement that “TFA was created for licensing “ reasons. That’s not the case. It was created to address fragmentation in the secure firmware for which there was no open source at all. SPL is definitely not architected to be the basis of Arm secure firmware { TFA/BL31 (secure monitor), TFA/BL32 (OP-TEE), TFA/SEL2(Hafnium), TFA/SCMI server, SCP…}. That said SPL and TFA/BL2 have similar roles from a 10,000ft perspective. I felt your comment was alluding to TFA was created to promote binary components integration, which is also not the case. Hence my reference to Trojan Horse. > But > you have no objection to requiring boards to supply a DT (whether in > documentation or arch/arm/dts) to be in U-Boot? I agree that boards need to properly document their DT. For (a) boards that have defined their standard boot flow to assume U-Boot will only do fix ups and overlays, the DT shall be in the U-Boot documentation part (either in full or pointing to their project documentation), in all other cases (b) it shall be in dts. Boards in the (a) case (may not be exhaustive): Qemu, SystemReady, RPI (it actually assumes it boot a Linux kernel but U-Boot smartly interposes). There may be RISCV boards that comply to EBBR too but I let Heinrich/Atish comment. > > > > > > > >> If a board is > >> in-tree in U-Boot I would like it to have a devicetree there, at least > >> until we have a better option. At the very least, it MUST be > >> discoverable and it must be possible to undertake U-Boot development > >> easily without a lot of messing around. > > > > You can if you keep two dts directories separate: > > dts for boards for which U-Boot must have one > > debug-dts for boards for which U-Boot get the DT at runtime but for > which you want a playground for debug/easier development. > >> > >> > >> >> > >> >> > >> >> But trying to do any driver / core work for a board where you don't > >> >> have the devicetree is currently not possible. The devicetree is a > >> >> core component and being unable to modify it is simply not practical. > >> >> We are talking here about an option that can be enabled or disabled. > >> >> In my case I am able to disable it locally and do my development > work. > >> >> > >> >> > >> >> BTW I've got the bloblist handoff working with a devicetree inside > it, > >> >> for qemu_arm. I need to try it on a real board to figure out what the > >> >> difference is. > >> >> > >> > That's great news and much needed for stabilizing the inbound ABI > from prior loader to U-Boot. Let's create another thread to discuss this > important topic. > >> >> > >> > >> My scenario is not all that advanced and I am using qemu_arm to test > >> the bloblist handoff stuff and include it in CI, with a suitable > >> devicetree and a binman node. > >> > >> Regards, > >> Simon > >> > >> >> > > >> >> > Cheers > >> >> > > >> >> > FF > >> >> > > >> >> > Le mar. 26 oct. 2021 à 02:24, Simon Glass <sjg@chromium.org> a > écrit : > >> >> >> > >> >> >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and > OF_HOSTFILE so > >> >> >> there are only three ways to obtain a devicetree: > >> >> >> > >> >> >> - OF_SEPARATE - the normal way, where the devicetree is built > and > >> >> >> appended to U-Boot > >> >> >> - OF_EMBED - for development purposes, the devicetree is > embedded in > >> >> >> the ELF file (also used for EFI) > >> >> >> - OF_BOARD - the board figures it out on its own > >> >> >> > >> >> >> The last one is currently set up so that no devicetree is needed > at all > >> >> >> in the U-Boot tree. Most boards do provide one, but some don't. > Some > >> >> >> don't even provide instructions on how to boot on the board. > >> >> >> > >> >> >> The problems with this approach are documented in another patch > in this > >> >> >> series: "doc: Add documentation about devicetree usage" > >> >> >> > >> >> >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. > Any board > >> >> >> can obtain its devicetree at runtime, even it is has a devicetree > built > >> >> >> in U-Boot. This is because U-Boot may be a second-stage > bootloader and its > >> >> >> caller may have a better idea about the hardware available in the > machine. > >> >> >> This is the case with a few QEMU boards, for example. > >> >> >> > >> >> >> So it makes no sense to have OF_BOARD as a 'choice'. It should be > an > >> >> >> option, available with either OF_SEPARATE or OF_EMBED. > >> >> >> > >> >> >> This series makes this change, adding various missing devicetree > files > >> >> >> (and placeholders) to make the build work. > >> >> >> > >> >> >> Note: If board maintainers are able to add their own patch to add > the > >> >> >> files, some patches in this series can be dropped. > >> >> >> > >> >> >> It also provides a few qemu clean-ups discovered along the way. > >> >> >> > >> >> >> Note: This breaks the qemu-riscv64_spl test, which still needs > >> >> >> investigation. > >> >> >> > >> >> >> [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > >> >> >> > >> >> >> Changes in v5: > >> >> >> - Bring into the OF_BOARD series > >> >> >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since > removed > >> >> >> - Refer to the 'control' DTB in the first paragraph > >> >> >> - Use QEMU instead of qemu > >> >> >> - Merge RISC-V and ARM patches since they are similar > >> >> >> - Add new patches to clean up fdtdec_setup() and surrounds > >> >> >> > >> >> >> Changes in v3: > >> >> >> - Clarify the 'bug' refered to at the top > >> >> >> - Reword 'This means that there' paragraph to explain > U-Boot-specific things > >> >> >> - Move to doc/develop/devicetree now that OF_CONTROL is in the > docs > >> >> >> > >> >> >> Changes in v2: > >> >> >> - Fix typos per Sean (thank you!) and a few others > >> >> >> - Add a 'Use of U-Boot /config node' section > >> >> >> - Drop mention of dm-verity since that actually uses the kernel > cmdline > >> >> >> - Explain that OF_BOARD will still work after these changes (in > >> >> >> 'Once this bug is fixed...' paragraph) > >> >> >> - Expand a bit on the reason why the 'Current situation' is bad > >> >> >> - Clarify in a second place that Linux and U-Boot use the same > devicetree > >> >> >> in 'To be clear, while U-Boot...' > >> >> >> - Expand on why we should have rules for other projects in > >> >> >> 'Devicetree in another project' > >> >> >> - Add a comment as to why devicetree in U-Boot is not 'bad design' > >> >> >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in > U-Boot' > >> >> >> - Rewrite 'Devicetree generated on-the-fly in another project' to > cover > >> >> >> points raised on v1 > >> >> >> - Add 'Why does U-Boot have its nodes and properties?' > >> >> >> - Add 'Why not have two devicetrees?' > >> >> >> > >> >> >> Ilias Apalodimas (1): > >> >> >> sandbox: Remove OF_HOSTFILE > >> >> >> > >> >> >> Simon Glass (25): > >> >> >> doc: Add documentation about devicetree usage > >> >> >> arm: qemu: Mention -nographic in the docs > >> >> >> arm: riscv: qemu: Explain how to extract the generated dt > >> >> >> arm: qemu: Add a devicetree file for qemu_arm > >> >> >> arm: qemu: Add a devicetree file for qemu_arm64 > >> >> >> riscv: qemu: Add devicetree files for qemu_riscv32/64 > >> >> >> arm: rpi: Add a devicetree file for rpi_4 > >> >> >> arm: vexpress: Add a devicetree file for juno > >> >> >> arm: xenguest_arm64: Add a fake devicetree file > >> >> >> arm: octeontx: Add a fake devicetree file > >> >> >> arm: xilinx_versal_virt: Add a devicetree file > >> >> >> arm: bcm7xxx: Add a devicetree file > >> >> >> arm: qemu-ppce500: Add a devicetree file > >> >> >> arm: highbank: Add a fake devicetree file > >> >> >> fdt: Make OF_BOARD a bool option > >> >> >> Drop CONFIG_BINMAN_STANDALONE_FDT > >> >> >> doc: Update info on devicetree update > >> >> >> fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() > >> >> >> fdt: Drop #ifdefs with MULTI_DTB_FIT > >> >> >> fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() > >> >> >> fdt: Drop #ifdef around board_fdt_blob_setup() > >> >> >> fdt: Use if() for fdtcontroladdr check > >> >> >> fdt: Drop OF_CONTROL check in fdtdec_setup() > >> >> >> fdt: Drop remaining preprocessor macros in fdtdec_setup() > >> >> >> fdt: Don't call board_fdt_blob_setup() without OF_BOARD > >> >> >> > >> >> >> Makefile | 7 +- > >> >> >> arch/arm/dts/Makefile | 20 +- > >> >> >> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 > +++++++++++++++++++++ > >> >> >> arch/arm/dts/bcm7xxx.dts | 15 + > >> >> >> arch/arm/dts/highbank.dts | 14 + > >> >> >> arch/arm/dts/juno-r2.dts | 1038 +++++++++++ > >> >> >> arch/arm/dts/octeontx.dts | 14 + > >> >> >> arch/arm/dts/qemu-arm.dts | 402 +++++ > >> >> >> arch/arm/dts/qemu-arm64.dts | 381 ++++ > >> >> >> arch/arm/dts/xenguest-arm64.dts | 15 + > >> >> >> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ > >> >> >> arch/powerpc/dts/Makefile | 1 + > >> >> >> arch/powerpc/dts/qemu-ppce500.dts | 264 +++ > >> >> >> arch/riscv/dts/Makefile | 2 +- > >> >> >> arch/riscv/dts/qemu-virt.dts | 8 - > >> >> >> arch/riscv/dts/qemu-virt32.dts | 217 +++ > >> >> >> arch/riscv/dts/qemu-virt64.dts | 217 +++ > >> >> >> arch/sandbox/cpu/cpu.c | 21 +- > >> >> >> arch/sandbox/include/asm/u-boot-sandbox.h | 8 - > >> >> >> configs/bcm7260_defconfig | 1 + > >> >> >> configs/bcm7445_defconfig | 1 + > >> >> >> configs/highbank_defconfig | 2 +- > >> >> >> configs/octeontx2_95xx_defconfig | 1 + > >> >> >> configs/octeontx2_96xx_defconfig | 1 + > >> >> >> configs/octeontx_81xx_defconfig | 1 + > >> >> >> configs/octeontx_83xx_defconfig | 1 + > >> >> >> configs/qemu-ppce500_defconfig | 2 + > >> >> >> configs/qemu-riscv32_defconfig | 1 + > >> >> >> configs/qemu-riscv32_smode_defconfig | 1 + > >> >> >> configs/qemu-riscv32_spl_defconfig | 4 +- > >> >> >> configs/qemu-riscv64_defconfig | 1 + > >> >> >> configs/qemu-riscv64_smode_defconfig | 1 + > >> >> >> configs/qemu-riscv64_spl_defconfig | 3 +- > >> >> >> configs/qemu_arm64_defconfig | 1 + > >> >> >> configs/qemu_arm_defconfig | 1 + > >> >> >> configs/rpi_4_32b_defconfig | 1 + > >> >> >> configs/rpi_4_defconfig | 1 + > >> >> >> configs/rpi_arm64_defconfig | 1 + > >> >> >> configs/sandbox64_defconfig | 2 +- > >> >> >> configs/sandbox_defconfig | 2 +- > >> >> >> configs/sandbox_flattree_defconfig | 2 +- > >> >> >> configs/sandbox_noinst_defconfig | 2 +- > >> >> >> configs/sandbox_spl_defconfig | 2 +- > >> >> >> configs/tools-only_defconfig | 2 +- > >> >> >> configs/vexpress_aemv8a_juno_defconfig | 1 + > >> >> >> configs/xenguest_arm64_defconfig | 1 + > >> >> >> configs/xilinx_versal_virt_defconfig | 1 + > >> >> >> doc/board/emulation/qemu-arm.rst | 10 +- > >> >> >> doc/board/emulation/qemu-riscv.rst | 3 + > >> >> >> doc/develop/devicetree/control.rst | 7 +- > >> >> >> doc/develop/devicetree/dt_qemu.rst | 48 + > >> >> >> doc/develop/devicetree/dt_update.rst | 498 ++++++ > >> >> >> doc/develop/devicetree/index.rst | 2 + > >> >> >> dts/Kconfig | 37 +- > >> >> >> include/asm-generic/global_data.h | 8 + > >> >> >> include/fdtdec.h | 21 +- > >> >> >> lib/fdtdec.c | 116 +- > >> >> >> scripts/Makefile.spl | 4 +- > >> >> >> tools/binman/binman.rst | 20 - > >> >> >> 59 files changed, 5560 insertions(+), 164 deletions(-) > >> >> >> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > >> >> >> create mode 100644 arch/arm/dts/bcm7xxx.dts > >> >> >> create mode 100644 arch/arm/dts/highbank.dts > >> >> >> create mode 100644 arch/arm/dts/juno-r2.dts > >> >> >> create mode 100644 arch/arm/dts/octeontx.dts > >> >> >> create mode 100644 arch/arm/dts/qemu-arm.dts > >> >> >> create mode 100644 arch/arm/dts/qemu-arm64.dts > >> >> >> create mode 100644 arch/arm/dts/xenguest-arm64.dts > >> >> >> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts > >> >> >> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts > >> >> >> delete mode 100644 arch/riscv/dts/qemu-virt.dts > >> >> >> create mode 100644 arch/riscv/dts/qemu-virt32.dts > >> >> >> create mode 100644 arch/riscv/dts/qemu-virt64.dts > >> >> >> create mode 100644 doc/develop/devicetree/dt_qemu.rst > >> >> >> create mode 100644 doc/develop/devicetree/dt_update.rst > >> >> >> > >> >> >> -- > >> >> >> 2.33.0.1079.g6e70778dc9-goog > >> >> >> > >> >> > -- > >> >> > François-Frédéric Ozog | Director Business Development > >> >> > T: +33.67221.6485 > >> >> > francois.ozog@linaro.org | Skype: ffozog > >> >> > > >> > > >> > > >> > > >> > -- > >> > François-Frédéric Ozog | Director Business Development > >> > T: +33.67221.6485 > >> > francois.ozog@linaro.org | Skype: ffozog > >> > > > > > -- > > François-Frédéric Ozog | Director Business Development > > T: +33.67221.6485 > > francois.ozog@linaro.org | Skype: ffozog > > >
> From: Simon Glass <sjg@chromium.org> > Date: Tue, 2 Nov 2021 19:20:51 -0600 > > Hi Mark, > > On Wed, 27 Oct 2021 at 16:30, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > From: Simon Glass <sjg@chromium.org> > > > Date: Wed, 27 Oct 2021 12:23:21 -0600 > > > > > > Hi François, > > > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: > > > >> > > > >> Hi François, > > > >> > > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: > > > >> > > > > >> > Hi Simon > > > >> > > > > >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. > > > >> > > > >> I think we are going to have to disagree on this one. I actually used > > > >> the qemu one in testing/development recently. We have to have a way to > > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > > >> cases, so far as I know. > > > > > > > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. > > > > I understand the advanced debug/development scenario you mention. > > > > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. > > > > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. > > > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > > has noticed. U-Boot handles the build automatically. If you turn off > > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > > going on. > > > > Until. The Raspberry Pi foundation releases a new firmware that > > configures the hardware differently such that the addresses in the > > U-Boot devicetree are wrong and nothing works anymore. Can't speak > > for the rpi 1, but this has happened in the past for the rpi 2 and 3 > > as well as more recently on the rpi 4. > > So I update my SD card with a new private-binary bootloader and things > stop working? I think I can narrow that one down :-) > > > > We can add a message to U-Boot indicating where the devicetree came > > > from, perhaps? That might be useful given everything that is going on. > > > > > > As in this case, quite often in these discussions I struggle to > > > understand what is behind the objection. Is it that your customers are > > > demanding that devicetrees become private, secret data, not included > > > in open-source projects? Or is it just the strange case of QEMU that > > > is informing your thinking? I know of at least one project where the > > > first-stage bootloader produces a devicetree and no one has the source > > > for it. I believe TF-A was created for licensing reasons...so can you > > > be a bit clearer about what the problem actually is? If a board is > > > in-tree in U-Boot I would like it to have a devicetree there, at least > > > until we have a better option. At the very least, it MUST be > > > discoverable and it must be possible to undertake U-Boot development > > > easily without a lot of messing around. > > > > How many people are there out there that work on U-Boot that don't > > have a Linux source tree checked out? Even I have several of those > > lying around on my development systems and I am an OpenBSD developer ;). > > So it is OK to have the DT in Linux but not in U-Boot? I don't even > know what to say that. How does that square with your point above? Ideally the DT's and DT binding would move out of the Linux tree and into a repository of their own. But until that is the case, the Linux tree is the source of truth. > I am not talking about disabling OF_BOARD, just making it *possible* > to do so. And I don't think it makes sense to do so on most boards that have OF_BOARD in their config.
On Tue, Nov 02, 2021 at 07:20:51PM -0600, Simon Glass wrote: > Hi Mark, > > On Wed, 27 Oct 2021 at 16:30, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > From: Simon Glass <sjg@chromium.org> > > > Date: Wed, 27 Oct 2021 12:23:21 -0600 > > > > > > Hi François, > > > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: > > > >> > > > >> Hi François, > > > >> > > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: > > > >> > > > > >> > Hi Simon > > > >> > > > > >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. > > > >> > > > >> I think we are going to have to disagree on this one. I actually used > > > >> the qemu one in testing/development recently. We have to have a way to > > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > > >> cases, so far as I know. > > > > > > > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. > > > > I understand the advanced debug/development scenario you mention. > > > > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. > > > > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. > > > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > > has noticed. U-Boot handles the build automatically. If you turn off > > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > > going on. > > > > Until. The Raspberry Pi foundation releases a new firmware that > > configures the hardware differently such that the addresses in the > > U-Boot devicetree are wrong and nothing works anymore. Can't speak > > for the rpi 1, but this has happened in the past for the rpi 2 and 3 > > as well as more recently on the rpi 4. > > So I update my SD card with a new private-binary bootloader and things > stop working? I think I can narrow that one down :-) Well, wait, no, this is the point. You can just not update your board. But that all of the users running a more recent release are now broken is the problem. It's already an opt-in thing to use U-Boot on Pis and if we make it even more annoying to be recent, there'll be even less reason to use U-Boot over over the Pi+TianoCore if you want anything more fancy that direct-to-Linux booting.
On Wed, Nov 03, 2021 at 09:22:58AM +0100, Mark Kettenis wrote: > > From: Simon Glass <sjg@chromium.org> > > Date: Tue, 2 Nov 2021 19:20:51 -0600 > > > > Hi Mark, > > > > On Wed, 27 Oct 2021 at 16:30, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > From: Simon Glass <sjg@chromium.org> > > > > Date: Wed, 27 Oct 2021 12:23:21 -0600 > > > > > > > > Hi François, > > > > > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: > > > > >> > > > > >> Hi François, > > > > >> > > > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: > > > > >> > > > > > >> > Hi Simon > > > > >> > > > > > >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. > > > > >> > > > > >> I think we are going to have to disagree on this one. I actually used > > > > >> the qemu one in testing/development recently. We have to have a way to > > > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > > > >> cases, so far as I know. > > > > > > > > > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. > > > > > I understand the advanced debug/development scenario you mention. > > > > > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. > > > > > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. > > > > > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > > > has noticed. U-Boot handles the build automatically. If you turn off > > > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > > > going on. > > > > > > Until. The Raspberry Pi foundation releases a new firmware that > > > configures the hardware differently such that the addresses in the > > > U-Boot devicetree are wrong and nothing works anymore. Can't speak > > > for the rpi 1, but this has happened in the past for the rpi 2 and 3 > > > as well as more recently on the rpi 4. > > > > So I update my SD card with a new private-binary bootloader and things > > stop working? I think I can narrow that one down :-) > > > > > > We can add a message to U-Boot indicating where the devicetree came > > > > from, perhaps? That might be useful given everything that is going on. > > > > > > > > As in this case, quite often in these discussions I struggle to > > > > understand what is behind the objection. Is it that your customers are > > > > demanding that devicetrees become private, secret data, not included > > > > in open-source projects? Or is it just the strange case of QEMU that > > > > is informing your thinking? I know of at least one project where the > > > > first-stage bootloader produces a devicetree and no one has the source > > > > for it. I believe TF-A was created for licensing reasons...so can you > > > > be a bit clearer about what the problem actually is? If a board is > > > > in-tree in U-Boot I would like it to have a devicetree there, at least > > > > until we have a better option. At the very least, it MUST be > > > > discoverable and it must be possible to undertake U-Boot development > > > > easily without a lot of messing around. > > > > > > How many people are there out there that work on U-Boot that don't > > > have a Linux source tree checked out? Even I have several of those > > > lying around on my development systems and I am an OpenBSD developer ;). > > > > So it is OK to have the DT in Linux but not in U-Boot? I don't even > > know what to say that. How does that square with your point above? > > Ideally the DT's and DT binding would move out of the Linux tree and > into a repository of their own. But until that is the case, the Linux > tree is the source of truth. Yes, and this is a long known and slowly in progress kinda-sorta thing. A few more people helping to review things, etc, are always appreciated by upstream. > > I am not talking about disabling OF_BOARD, just making it *possible* > > to do so. > > And I don't think it makes sense to do so on most boards that have > OF_BOARD in their config. It should probably close to never be done, unless it's some case where it's crazy-hard to update the device tree correctly for the platform. So it's not a problem on Pi as it's just on the FAT32 partition right there, it's not a problem on Apple M1 as ..however you do it.., and so on. I can almost hear the argument from here about "but I'm doing some work for U-Boot and need to add..." and that's where we need to figure out what to do next. Yes, we likely need to have some bindings of our own, and developing those AND pushing them upstream will require iterating here. So the developer point of view of how do I whack things to supply my own is valid. But it's not the default use case. The default use case is building the firmware that users rarely see, because their system boots to the OS and they get down to using their system.
Hi Tom, On Wed, 27 Oct 2021 at 13:25, Tom Rini <trini@konsulko.com> wrote: > > On Wed, Oct 27, 2021 at 12:23:21PM -0600, Simon Glass wrote: > > Hi François, > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: > > >> > > >> Hi François, > > >> > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: > > >> > > > >> > Hi Simon > > >> > > > >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. > > >> > > >> I think we are going to have to disagree on this one. I actually used > > >> the qemu one in testing/development recently. We have to have a way to > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > >> cases, so far as I know. > > > > > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. > > > I understand the advanced debug/development scenario you mention. > > > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. > > > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > has noticed. U-Boot handles the build automatically. If you turn off > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > going on. > > That we have to have so many separate rpi build targets, and can't just > use rpm_arm64 and add rpi_arm32 is not a good feature. The various rpi > configs that use CONFIG_OF_EMBED are on your list of things that need to > be cleaned up, yes? Yes, it should use CONFIG_OF_SEPARATE. It think it didn't for historical reasons, but not sure why. > > > We can add a message to U-Boot indicating where the devicetree came > > from, perhaps? That might be useful given everything that is going on. > > > > As in this case, quite often in these discussions I struggle to > > understand what is behind the objection. Is it that your customers are > > demanding that devicetrees become private, secret data, not included > > in open-source projects? Or is it just the strange case of QEMU that > > is informing your thinking? I know of at least one project where the > > first-stage bootloader produces a devicetree and no one has the source > > for it. I believe TF-A was created for licensing reasons...so can you > > be a bit clearer about what the problem actually is? If a board is > > in-tree in U-Boot I would like it to have a devicetree there, at least > > until we have a better option. At the very least, it MUST be > > discoverable and it must be possible to undertake U-Boot development > > easily without a lot of messing around. > > What I don't understand here is why or how U-Boot is supposed to become > the source of truth for device trees. The general goal is that the > device tree be something that actually comes along on the hardware, > because it's stable enough and correct enough that it's not going to be > changed from one OS kernel release to the next. That should be where > the correct and true tree comes from, the device itself. Is that the confusion here? I am not saying that U-Boot becomes the 'source of truth' (horrible term). Where did that idea come from? By hardware you mean firmware, I think. If you are developing firmware, you need control of the devicetree. It is part of the firmware. Regards, Simon
Hi Tom, On Wed, 3 Nov 2021 at 09:56, Tom Rini <trini@konsulko.com> wrote: > > On Tue, Nov 02, 2021 at 07:20:51PM -0600, Simon Glass wrote: > > Hi Mark, > > > > On Wed, 27 Oct 2021 at 16:30, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > From: Simon Glass <sjg@chromium.org> > > > > Date: Wed, 27 Oct 2021 12:23:21 -0600 > > > > > > > > Hi François, > > > > > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: > > > > >> > > > > >> Hi François, > > > > >> > > > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: > > > > >> > > > > > >> > Hi Simon > > > > >> > > > > > >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. > > > > >> > > > > >> I think we are going to have to disagree on this one. I actually used > > > > >> the qemu one in testing/development recently. We have to have a way to > > > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > > > >> cases, so far as I know. > > > > > > > > > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. > > > > > I understand the advanced debug/development scenario you mention. > > > > > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. > > > > > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. > > > > > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > > > has noticed. U-Boot handles the build automatically. If you turn off > > > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > > > going on. > > > > > > Until. The Raspberry Pi foundation releases a new firmware that > > > configures the hardware differently such that the addresses in the > > > U-Boot devicetree are wrong and nothing works anymore. Can't speak > > > for the rpi 1, but this has happened in the past for the rpi 2 and 3 > > > as well as more recently on the rpi 4. > > > > So I update my SD card with a new private-binary bootloader and things > > stop working? I think I can narrow that one down :-) > > Well, wait, no, this is the point. You can just not update your board. > But that all of the users running a more recent release are now broken > is the problem. It's already an opt-in thing to use U-Boot on Pis and > if we make it even more annoying to be recent, there'll be even less > reason to use U-Boot over over the Pi+TianoCore if you want anything > more fancy that direct-to-Linux booting. This is all totally in the weeds at this point. What are you referring to? I'm talking about turning off OF_BOARD in my private build of U-Boot so that it picks up the devicetree built with U-Boot. I thought that was what Mark was saying...? Regards, Simon
Hi Tom, On Wed, 3 Nov 2021 at 10:02, Tom Rini <trini@konsulko.com> wrote: > > On Wed, Nov 03, 2021 at 09:22:58AM +0100, Mark Kettenis wrote: > > > From: Simon Glass <sjg@chromium.org> > > > Date: Tue, 2 Nov 2021 19:20:51 -0600 > > > > > > Hi Mark, > > > > > > On Wed, 27 Oct 2021 at 16:30, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > From: Simon Glass <sjg@chromium.org> > > > > > Date: Wed, 27 Oct 2021 12:23:21 -0600 > > > > > > > > > > Hi François, > > > > > > > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: > > > > > >> > > > > > >> Hi François, > > > > > >> > > > > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: > > > > > >> > > > > > > >> > Hi Simon > > > > > >> > > > > > > >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. > > > > > >> > > > > > >> I think we are going to have to disagree on this one. I actually used > > > > > >> the qemu one in testing/development recently. We have to have a way to > > > > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > > > > >> cases, so far as I know. > > > > > > > > > > > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. > > > > > > I understand the advanced debug/development scenario you mention. > > > > > > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. > > > > > > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. > > > > > > > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > > > > has noticed. U-Boot handles the build automatically. If you turn off > > > > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > > > > going on. > > > > > > > > Until. The Raspberry Pi foundation releases a new firmware that > > > > configures the hardware differently such that the addresses in the > > > > U-Boot devicetree are wrong and nothing works anymore. Can't speak > > > > for the rpi 1, but this has happened in the past for the rpi 2 and 3 > > > > as well as more recently on the rpi 4. > > > > > > So I update my SD card with a new private-binary bootloader and things > > > stop working? I think I can narrow that one down :-) > > > > > > > > We can add a message to U-Boot indicating where the devicetree came > > > > > from, perhaps? That might be useful given everything that is going on. > > > > > > > > > > As in this case, quite often in these discussions I struggle to > > > > > understand what is behind the objection. Is it that your customers are > > > > > demanding that devicetrees become private, secret data, not included > > > > > in open-source projects? Or is it just the strange case of QEMU that > > > > > is informing your thinking? I know of at least one project where the > > > > > first-stage bootloader produces a devicetree and no one has the source > > > > > for it. I believe TF-A was created for licensing reasons...so can you > > > > > be a bit clearer about what the problem actually is? If a board is > > > > > in-tree in U-Boot I would like it to have a devicetree there, at least > > > > > until we have a better option. At the very least, it MUST be > > > > > discoverable and it must be possible to undertake U-Boot development > > > > > easily without a lot of messing around. > > > > > > > > How many people are there out there that work on U-Boot that don't > > > > have a Linux source tree checked out? Even I have several of those > > > > lying around on my development systems and I am an OpenBSD developer ;). > > > > > > So it is OK to have the DT in Linux but not in U-Boot? I don't even > > > know what to say that. How does that square with your point above? > > > > Ideally the DT's and DT binding would move out of the Linux tree and > > into a repository of their own. But until that is the case, the Linux > > tree is the source of truth. > > Yes, and this is a long known and slowly in progress kinda-sorta thing. > A few more people helping to review things, etc, are always appreciated > by upstream. > > > > I am not talking about disabling OF_BOARD, just making it *possible* > > > to do so. > > > > And I don't think it makes sense to do so on most boards that have > > OF_BOARD in their config. > > It should probably close to never be done, unless it's some case where > it's crazy-hard to update the device tree correctly for the platform. > So it's not a problem on Pi as it's just on the FAT32 partition right > there, it's not a problem on Apple M1 as ..however you do it.., and so > on. > > I can almost hear the argument from here about "but I'm doing some work > for U-Boot and need to add..." and that's where we need to figure out > what to do next. Yes, we likely need to have some bindings of our own, > and developing those AND pushing them upstream will require iterating > here. So the developer point of view of how do I whack things to supply > my own is valid. But it's not the default use case. The default use > case is building the firmware that users rarely see, because their > system boots to the OS and they get down to using their system. I believe that OF_BOARD needs to become a runtime option. If not, there is no way to use the U-Boot deivcetree. I cannot build it in-tree. I cannot make U-Boot use it. It's just a mess. So we are supposed to run dtc manually to ge tthe DT, then copy it manually, then deal with the include files it needs and the C preprocessing it needs for the bindings? Why make this so hard? It just makes no sense to me. We are making this 'odd' case into the main case. It isn't. If it becomes it one day, I hope we are in a better place with devicetree. Upstreaming bindings is one thing, but we need to develop and test, first. I really don't understand why this is generating so much discussion. How can we get this moving? What is so wrong with having a devicetree in U-Boot for building? Why are these boards so special? And what problem does it cause? The only one I have heard is confusion, which I think I have addressed. Regards, SImon
Hi Simon I don't know if this is correct etiquette but at this moment it feels just right to do this: The problem is not confusion it is that the patch set goes in a direction that makes no sense. On Tue, 26 Oct 2021 at 02:24, Simon Glass <sjg@chromium.org> wrote: > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > there are only three ways to obtain a devicetree: > > - OF_SEPARATE - the normal way, where the devicetree is built and > appended to U-Boot > - OF_EMBED - for development purposes, the devicetree is embedded in > the ELF file (also used for EFI) > - OF_BOARD - the board figures it out on its own > > YES! perfect! Default config for boards like RPI4, Qemu and SystemReady ones should be OF_BOARD. There may be an override for the advanced developer that need a playground for those boards; with a warning: "for debug purposes, turning on this option for this platform assumes you know exactly what you are doing." The last one is currently set up so that no devicetree is needed at all > in the U-Boot tree. Rightfully as you write below "it comes from an entity that "have a better idea about the hardware". > Most boards do provide one, but some don't. Some > don't even provide instructions on how to boot on the board. > > That is a documentation problem. > The problems with this approach are documented in another patch in this > series: "doc: Add documentation about devicetree usage" > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > can obtain its devicetree at runtime, even it is has a devicetree built > in U-Boot. That statement is I think the start of problems. > This is because U-Boot may be a second-stage bootloader and its > caller may have a better idea about the hardware available in the machine. > This is the case with a few QEMU boards, for example. > > YES! exactly. Why would you ever embed a DT in U-Boot if it comes from an entity that "have a better idea about the hardware"? For advanced debugging yes. Otherwise no reasons. > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > option, available with either OF_SEPARATE or OF_EMBED. > > Problem starts to grow. > This series makes this change, adding various missing devicetree files > (and placeholders) to make the build work. > > Note: If board maintainers are able to add their own patch to add the > files, some patches in this series can be dropped. > > It also provides a few qemu clean-ups discovered along the way. > > Note: This breaks the qemu-riscv64_spl test, which still needs > investigation. > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > Changes in v5: > - Bring into the OF_BOARD series > - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > - Refer to the 'control' DTB in the first paragraph > - Use QEMU instead of qemu > - Merge RISC-V and ARM patches since they are similar > - Add new patches to clean up fdtdec_setup() and surrounds > > Changes in v3: > - Clarify the 'bug' refered to at the top > - Reword 'This means that there' paragraph to explain U-Boot-specific > things > - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > > Changes in v2: > - Fix typos per Sean (thank you!) and a few others > - Add a 'Use of U-Boot /config node' section > - Drop mention of dm-verity since that actually uses the kernel cmdline > - Explain that OF_BOARD will still work after these changes (in > 'Once this bug is fixed...' paragraph) > - Expand a bit on the reason why the 'Current situation' is bad > - Clarify in a second place that Linux and U-Boot use the same devicetree > in 'To be clear, while U-Boot...' > - Expand on why we should have rules for other projects in > 'Devicetree in another project' > - Add a comment as to why devicetree in U-Boot is not 'bad design' > - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > - Rewrite 'Devicetree generated on-the-fly in another project' to cover > points raised on v1 > - Add 'Why does U-Boot have its nodes and properties?' > - Add 'Why not have two devicetrees?' > > Ilias Apalodimas (1): > sandbox: Remove OF_HOSTFILE > > Simon Glass (25): > doc: Add documentation about devicetree usage > arm: qemu: Mention -nographic in the docs > arm: riscv: qemu: Explain how to extract the generated dt > arm: qemu: Add a devicetree file for qemu_arm > arm: qemu: Add a devicetree file for qemu_arm64 > riscv: qemu: Add devicetree files for qemu_riscv32/64 > arm: rpi: Add a devicetree file for rpi_4 > arm: vexpress: Add a devicetree file for juno > arm: xenguest_arm64: Add a fake devicetree file > arm: octeontx: Add a fake devicetree file > arm: xilinx_versal_virt: Add a devicetree file > arm: bcm7xxx: Add a devicetree file > arm: qemu-ppce500: Add a devicetree file > arm: highbank: Add a fake devicetree file > fdt: Make OF_BOARD a bool option > Drop CONFIG_BINMAN_STANDALONE_FDT > doc: Update info on devicetree update > fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() > fdt: Drop #ifdefs with MULTI_DTB_FIT > fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() > fdt: Drop #ifdef around board_fdt_blob_setup() > fdt: Use if() for fdtcontroladdr check > fdt: Drop OF_CONTROL check in fdtdec_setup() > fdt: Drop remaining preprocessor macros in fdtdec_setup() > fdt: Don't call board_fdt_blob_setup() without OF_BOARD > > Makefile | 7 +- > arch/arm/dts/Makefile | 20 +- > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 +++++++++++++++++++++ > arch/arm/dts/bcm7xxx.dts | 15 + > arch/arm/dts/highbank.dts | 14 + > arch/arm/dts/juno-r2.dts | 1038 +++++++++++ > arch/arm/dts/octeontx.dts | 14 + > arch/arm/dts/qemu-arm.dts | 402 +++++ > arch/arm/dts/qemu-arm64.dts | 381 ++++ > arch/arm/dts/xenguest-arm64.dts | 15 + > arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ > arch/powerpc/dts/Makefile | 1 + > arch/powerpc/dts/qemu-ppce500.dts | 264 +++ > arch/riscv/dts/Makefile | 2 +- > arch/riscv/dts/qemu-virt.dts | 8 - > arch/riscv/dts/qemu-virt32.dts | 217 +++ > arch/riscv/dts/qemu-virt64.dts | 217 +++ > arch/sandbox/cpu/cpu.c | 21 +- > arch/sandbox/include/asm/u-boot-sandbox.h | 8 - > configs/bcm7260_defconfig | 1 + > configs/bcm7445_defconfig | 1 + > configs/highbank_defconfig | 2 +- > configs/octeontx2_95xx_defconfig | 1 + > configs/octeontx2_96xx_defconfig | 1 + > configs/octeontx_81xx_defconfig | 1 + > configs/octeontx_83xx_defconfig | 1 + > configs/qemu-ppce500_defconfig | 2 + > configs/qemu-riscv32_defconfig | 1 + > configs/qemu-riscv32_smode_defconfig | 1 + > configs/qemu-riscv32_spl_defconfig | 4 +- > configs/qemu-riscv64_defconfig | 1 + > configs/qemu-riscv64_smode_defconfig | 1 + > configs/qemu-riscv64_spl_defconfig | 3 +- > configs/qemu_arm64_defconfig | 1 + > configs/qemu_arm_defconfig | 1 + > configs/rpi_4_32b_defconfig | 1 + > configs/rpi_4_defconfig | 1 + > configs/rpi_arm64_defconfig | 1 + > configs/sandbox64_defconfig | 2 +- > configs/sandbox_defconfig | 2 +- > configs/sandbox_flattree_defconfig | 2 +- > configs/sandbox_noinst_defconfig | 2 +- > configs/sandbox_spl_defconfig | 2 +- > configs/tools-only_defconfig | 2 +- > configs/vexpress_aemv8a_juno_defconfig | 1 + > configs/xenguest_arm64_defconfig | 1 + > configs/xilinx_versal_virt_defconfig | 1 + > doc/board/emulation/qemu-arm.rst | 10 +- > doc/board/emulation/qemu-riscv.rst | 3 + > doc/develop/devicetree/control.rst | 7 +- > doc/develop/devicetree/dt_qemu.rst | 48 + > doc/develop/devicetree/dt_update.rst | 498 ++++++ > doc/develop/devicetree/index.rst | 2 + > dts/Kconfig | 37 +- > include/asm-generic/global_data.h | 8 + > include/fdtdec.h | 21 +- > lib/fdtdec.c | 116 +- > scripts/Makefile.spl | 4 +- > tools/binman/binman.rst | 20 - > 59 files changed, 5560 insertions(+), 164 deletions(-) > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > create mode 100644 arch/arm/dts/bcm7xxx.dts > create mode 100644 arch/arm/dts/highbank.dts > create mode 100644 arch/arm/dts/juno-r2.dts > create mode 100644 arch/arm/dts/octeontx.dts > create mode 100644 arch/arm/dts/qemu-arm.dts > create mode 100644 arch/arm/dts/qemu-arm64.dts > create mode 100644 arch/arm/dts/xenguest-arm64.dts > create mode 100644 arch/arm/dts/xilinx-versal-virt.dts > create mode 100644 arch/powerpc/dts/qemu-ppce500.dts > delete mode 100644 arch/riscv/dts/qemu-virt.dts > create mode 100644 arch/riscv/dts/qemu-virt32.dts > create mode 100644 arch/riscv/dts/qemu-virt64.dts > create mode 100644 doc/develop/devicetree/dt_qemu.rst > create mode 100644 doc/develop/devicetree/dt_update.rst > > -- > 2.33.0.1079.g6e70778dc9-goog > >
On Wed, Nov 03, 2021 at 10:45:11AM -0600, Simon Glass wrote: > Hi Tom, > > On Wed, 27 Oct 2021 at 13:25, Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Oct 27, 2021 at 12:23:21PM -0600, Simon Glass wrote: > > > Hi François, > > > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: > > > >> > > > >> Hi François, > > > >> > > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: > > > >> > > > > >> > Hi Simon > > > >> > > > > >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. > > > >> > > > >> I think we are going to have to disagree on this one. I actually used > > > >> the qemu one in testing/development recently. We have to have a way to > > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > > >> cases, so far as I know. > > > > > > > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. > > > > I understand the advanced debug/development scenario you mention. > > > > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. > > > > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. > > > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > > has noticed. U-Boot handles the build automatically. If you turn off > > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > > going on. > > > > That we have to have so many separate rpi build targets, and can't just > > use rpm_arm64 and add rpi_arm32 is not a good feature. The various rpi > > configs that use CONFIG_OF_EMBED are on your list of things that need to > > be cleaned up, yes? > > Yes, it should use CONFIG_OF_SEPARATE. It think it didn't for > historical reasons, but not sure why. I think because it wasn't clear enough at the time how to say "just use the dtb given to us as-is". > > > We can add a message to U-Boot indicating where the devicetree came > > > from, perhaps? That might be useful given everything that is going on. > > > > > > As in this case, quite often in these discussions I struggle to > > > understand what is behind the objection. Is it that your customers are > > > demanding that devicetrees become private, secret data, not included > > > in open-source projects? Or is it just the strange case of QEMU that > > > is informing your thinking? I know of at least one project where the > > > first-stage bootloader produces a devicetree and no one has the source > > > for it. I believe TF-A was created for licensing reasons...so can you > > > be a bit clearer about what the problem actually is? If a board is > > > in-tree in U-Boot I would like it to have a devicetree there, at least > > > until we have a better option. At the very least, it MUST be > > > discoverable and it must be possible to undertake U-Boot development > > > easily without a lot of messing around. > > > > What I don't understand here is why or how U-Boot is supposed to become > > the source of truth for device trees. The general goal is that the > > device tree be something that actually comes along on the hardware, > > because it's stable enough and correct enough that it's not going to be > > changed from one OS kernel release to the next. That should be where > > the correct and true tree comes from, the device itself. > > Is that the confusion here? I am not saying that U-Boot becomes the > 'source of truth' (horrible term). Where did that idea come from? > > By hardware you mean firmware, I think. If you are developing > firmware, you need control of the devicetree. It is part of the > firmware. I mean the case where U-Boot is provided the device tree to use, by whatever external and non-U-Boot means. I keep saying "source of truth" as a way to clarify that the correct and only required device tree is given to us at run time. If U-Boot needs to know something, it's already provided there. If it's not there, we don't need to know it. This is also why there's not a reason to normally build a device tree in U-Boot since it will not be used. And if we aren't building it, we don't need it in the source tree either since it's going to introduce confusion. Quoted in part or referenced under doc/ ? OK, that can make sense in some cases.
> From: Simon Glass <sjg@chromium.org> > Date: Wed, 3 Nov 2021 10:45:42 -0600 > > Hi Tom, > > On Wed, 3 Nov 2021 at 10:02, Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Nov 03, 2021 at 09:22:58AM +0100, Mark Kettenis wrote: > > > > From: Simon Glass <sjg@chromium.org> > > > > Date: Tue, 2 Nov 2021 19:20:51 -0600 > > > > > > > > Hi Mark, > > > > > > > > On Wed, 27 Oct 2021 at 16:30, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > > > From: Simon Glass <sjg@chromium.org> > > > > > > Date: Wed, 27 Oct 2021 12:23:21 -0600 > > > > > > > > > > > > Hi François, > > > > > > > > > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg@chromium.org> wrote: > > > > > > >> > > > > > > >> Hi François, > > > > > > >> > > > > > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > >> > > > > > > > >> > Hi Simon > > > > > > >> > > > > > > > >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. > > > > > > >> > > > > > > >> I think we are going to have to disagree on this one. I actually used > > > > > > >> the qemu one in testing/development recently. We have to have a way to > > > > > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > > > > > >> cases, so far as I know. > > > > > > > > > > > > > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. > > > > > > > I understand the advanced debug/development scenario you mention. > > > > > > > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. > > > > > > > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. > > > > > > > > > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > > > > > has noticed. U-Boot handles the build automatically. If you turn off > > > > > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > > > > > going on. > > > > > > > > > > Until. The Raspberry Pi foundation releases a new firmware that > > > > > configures the hardware differently such that the addresses in the > > > > > U-Boot devicetree are wrong and nothing works anymore. Can't speak > > > > > for the rpi 1, but this has happened in the past for the rpi 2 and 3 > > > > > as well as more recently on the rpi 4. > > > > > > > > So I update my SD card with a new private-binary bootloader and things > > > > stop working? I think I can narrow that one down :-) > > > > > > > > > > We can add a message to U-Boot indicating where the devicetree came > > > > > > from, perhaps? That might be useful given everything that is going on. > > > > > > > > > > > > As in this case, quite often in these discussions I struggle to > > > > > > understand what is behind the objection. Is it that your customers are > > > > > > demanding that devicetrees become private, secret data, not included > > > > > > in open-source projects? Or is it just the strange case of QEMU that > > > > > > is informing your thinking? I know of at least one project where the > > > > > > first-stage bootloader produces a devicetree and no one has the source > > > > > > for it. I believe TF-A was created for licensing reasons...so can you > > > > > > be a bit clearer about what the problem actually is? If a board is > > > > > > in-tree in U-Boot I would like it to have a devicetree there, at least > > > > > > until we have a better option. At the very least, it MUST be > > > > > > discoverable and it must be possible to undertake U-Boot development > > > > > > easily without a lot of messing around. > > > > > > > > > > How many people are there out there that work on U-Boot that don't > > > > > have a Linux source tree checked out? Even I have several of those > > > > > lying around on my development systems and I am an OpenBSD developer ;). > > > > > > > > So it is OK to have the DT in Linux but not in U-Boot? I don't even > > > > know what to say that. How does that square with your point above? > > > > > > Ideally the DT's and DT binding would move out of the Linux tree and > > > into a repository of their own. But until that is the case, the Linux > > > tree is the source of truth. > > > > Yes, and this is a long known and slowly in progress kinda-sorta thing. > > A few more people helping to review things, etc, are always appreciated > > by upstream. > > > > > > I am not talking about disabling OF_BOARD, just making it *possible* > > > > to do so. > > > > > > And I don't think it makes sense to do so on most boards that have > > > OF_BOARD in their config. > > > > It should probably close to never be done, unless it's some case where > > it's crazy-hard to update the device tree correctly for the platform. > > So it's not a problem on Pi as it's just on the FAT32 partition right > > there, it's not a problem on Apple M1 as ..however you do it.., and so > > on. > > > > I can almost hear the argument from here about "but I'm doing some work > > for U-Boot and need to add..." and that's where we need to figure out > > what to do next. Yes, we likely need to have some bindings of our own, > > and developing those AND pushing them upstream will require iterating > > here. So the developer point of view of how do I whack things to supply > > my own is valid. But it's not the default use case. The default use > > case is building the firmware that users rarely see, because their > > system boots to the OS and they get down to using their system. > > I believe that OF_BOARD needs to become a runtime option. I'm looking at this from the perspective of the Apple M1. But please no. That would only tempt users to flip the switch resulting in a non-bootable system. > If not, there is no way to use the U-Boot deivcetree. There is no way to use the U-Boot devicetree on these boards, because it is incomplete. And the code to fill in the missing bits lives somewhere else. > I cannot build it in-tree. I cannot make U-Boot use it. It's just a mess. Correct. So putting the device tree in the U-Boot repository makes no sense. > So we are supposed to run dtc manually to ge tthe DT, then copy it > manually, then deal with the include files it needs and the C > preprocessing it needs for the bindings? Of course not. The repository that contains the DT sources will have the infrastructure to do that for you. > We are making this 'odd' case into the main case. It isn't. If it > becomes it one day, I hope we are in a better place with devicetree. > Upstreaming bindings is one thing, but we need to develop and test, > first. And the way I test things is that I build the device tree, load it together with the U-Boot binary into m1n1 over serial or USB and run it. > I really don't understand why this is generating so much discussion. > How can we get this moving? Maybe because you're continuously telling is we're doing it wrong and must do it your way? > What is so wrong with having a devicetree in U-Boot for building? This sounds like you want to make having a devicetree in the actual U-Boot a hard requirement. And that makes no sense to me for the Apple M1 systems. > Why are these boards so special? And what problem does it cause? The > only one I have heard is confusion, which I think I have addressed. They're not special; just different.
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so there are only three ways to obtain a devicetree: - OF_SEPARATE - the normal way, where the devicetree is built and appended to U-Boot - OF_EMBED - for development purposes, the devicetree is embedded in the ELF file (also used for EFI) - OF_BOARD - the board figures it out on its own The last one is currently set up so that no devicetree is needed at all in the U-Boot tree. Most boards do provide one, but some don't. Some don't even provide instructions on how to boot on the board. The problems with this approach are documented in another patch in this series: "doc: Add documentation about devicetree usage" In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board can obtain its devicetree at runtime, even it is has a devicetree built in U-Boot. This is because U-Boot may be a second-stage bootloader and its caller may have a better idea about the hardware available in the machine. This is the case with a few QEMU boards, for example. So it makes no sense to have OF_BOARD as a 'choice'. It should be an option, available with either OF_SEPARATE or OF_EMBED. This series makes this change, adding various missing devicetree files (and placeholders) to make the build work. Note: If board maintainers are able to add their own patch to add the files, some patches in this series can be dropped. It also provides a few qemu clean-ups discovered along the way. Note: This breaks the qemu-riscv64_spl test, which still needs investigation. [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ Changes in v5: - Bring into the OF_BOARD series - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed - Refer to the 'control' DTB in the first paragraph - Use QEMU instead of qemu - Merge RISC-V and ARM patches since they are similar - Add new patches to clean up fdtdec_setup() and surrounds Changes in v3: - Clarify the 'bug' refered to at the top - Reword 'This means that there' paragraph to explain U-Boot-specific things - Move to doc/develop/devicetree now that OF_CONTROL is in the docs Changes in v2: - Fix typos per Sean (thank you!) and a few others - Add a 'Use of U-Boot /config node' section - Drop mention of dm-verity since that actually uses the kernel cmdline - Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph) - Expand a bit on the reason why the 'Current situation' is bad - Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...' - Expand on why we should have rules for other projects in 'Devicetree in another project' - Add a comment as to why devicetree in U-Boot is not 'bad design' - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' - Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1 - Add 'Why does U-Boot have its nodes and properties?' - Add 'Why not have two devicetrees?' Ilias Apalodimas (1): sandbox: Remove OF_HOSTFILE Simon Glass (25): doc: Add documentation about devicetree usage arm: qemu: Mention -nographic in the docs arm: riscv: qemu: Explain how to extract the generated dt arm: qemu: Add a devicetree file for qemu_arm arm: qemu: Add a devicetree file for qemu_arm64 riscv: qemu: Add devicetree files for qemu_riscv32/64 arm: rpi: Add a devicetree file for rpi_4 arm: vexpress: Add a devicetree file for juno arm: xenguest_arm64: Add a fake devicetree file arm: octeontx: Add a fake devicetree file arm: xilinx_versal_virt: Add a devicetree file arm: bcm7xxx: Add a devicetree file arm: qemu-ppce500: Add a devicetree file arm: highbank: Add a fake devicetree file fdt: Make OF_BOARD a bool option Drop CONFIG_BINMAN_STANDALONE_FDT doc: Update info on devicetree update fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() fdt: Drop #ifdefs with MULTI_DTB_FIT fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() fdt: Drop #ifdef around board_fdt_blob_setup() fdt: Use if() for fdtcontroladdr check fdt: Drop OF_CONTROL check in fdtdec_setup() fdt: Drop remaining preprocessor macros in fdtdec_setup() fdt: Don't call board_fdt_blob_setup() without OF_BOARD Makefile | 7 +- arch/arm/dts/Makefile | 20 +- arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 +++++++++++++++++++++ arch/arm/dts/bcm7xxx.dts | 15 + arch/arm/dts/highbank.dts | 14 + arch/arm/dts/juno-r2.dts | 1038 +++++++++++ arch/arm/dts/octeontx.dts | 14 + arch/arm/dts/qemu-arm.dts | 402 +++++ arch/arm/dts/qemu-arm64.dts | 381 ++++ arch/arm/dts/xenguest-arm64.dts | 15 + arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/qemu-ppce500.dts | 264 +++ arch/riscv/dts/Makefile | 2 +- arch/riscv/dts/qemu-virt.dts | 8 - arch/riscv/dts/qemu-virt32.dts | 217 +++ arch/riscv/dts/qemu-virt64.dts | 217 +++ arch/sandbox/cpu/cpu.c | 21 +- arch/sandbox/include/asm/u-boot-sandbox.h | 8 - configs/bcm7260_defconfig | 1 + configs/bcm7445_defconfig | 1 + configs/highbank_defconfig | 2 +- configs/octeontx2_95xx_defconfig | 1 + configs/octeontx2_96xx_defconfig | 1 + configs/octeontx_81xx_defconfig | 1 + configs/octeontx_83xx_defconfig | 1 + configs/qemu-ppce500_defconfig | 2 + configs/qemu-riscv32_defconfig | 1 + configs/qemu-riscv32_smode_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 4 +- configs/qemu-riscv64_defconfig | 1 + configs/qemu-riscv64_smode_defconfig | 1 + configs/qemu-riscv64_spl_defconfig | 3 +- configs/qemu_arm64_defconfig | 1 + configs/qemu_arm_defconfig | 1 + configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + configs/sandbox64_defconfig | 2 +- configs/sandbox_defconfig | 2 +- configs/sandbox_flattree_defconfig | 2 +- configs/sandbox_noinst_defconfig | 2 +- configs/sandbox_spl_defconfig | 2 +- configs/tools-only_defconfig | 2 +- configs/vexpress_aemv8a_juno_defconfig | 1 + configs/xenguest_arm64_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + doc/board/emulation/qemu-arm.rst | 10 +- doc/board/emulation/qemu-riscv.rst | 3 + doc/develop/devicetree/control.rst | 7 +- doc/develop/devicetree/dt_qemu.rst | 48 + doc/develop/devicetree/dt_update.rst | 498 ++++++ doc/develop/devicetree/index.rst | 2 + dts/Kconfig | 37 +- include/asm-generic/global_data.h | 8 + include/fdtdec.h | 21 +- lib/fdtdec.c | 116 +- scripts/Makefile.spl | 4 +- tools/binman/binman.rst | 20 - 59 files changed, 5560 insertions(+), 164 deletions(-) create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts create mode 100644 arch/arm/dts/bcm7xxx.dts create mode 100644 arch/arm/dts/highbank.dts create mode 100644 arch/arm/dts/juno-r2.dts create mode 100644 arch/arm/dts/octeontx.dts create mode 100644 arch/arm/dts/qemu-arm.dts create mode 100644 arch/arm/dts/qemu-arm64.dts create mode 100644 arch/arm/dts/xenguest-arm64.dts create mode 100644 arch/arm/dts/xilinx-versal-virt.dts create mode 100644 arch/powerpc/dts/qemu-ppce500.dts delete mode 100644 arch/riscv/dts/qemu-virt.dts create mode 100644 arch/riscv/dts/qemu-virt32.dts create mode 100644 arch/riscv/dts/qemu-virt64.dts create mode 100644 doc/develop/devicetree/dt_qemu.rst create mode 100644 doc/develop/devicetree/dt_update.rst