Message ID | 20211013010120.96851-1-sjg@chromium.org |
---|---|
Headers | show |
Series | fdt: Make OF_BOARD a boolean option | expand |
Hi Simon, On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote: > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > there are only three ways to obtain a devicetree: > > - OF_SEPARATE - the normal way, where the devicetree is built and > appended to U-Boot > - OF_EMBED - for development purposes, the devicetree is embedded in > the ELF file (also used for EFI) > - OF_BOARD - the board figures it out on its own > > The last one is currently set up so that no devicetree is needed at all > in the U-Boot tree. Most boards do provide one, but some don't. Some > don't even provide instructions on how to boot on the board. > > The problems with this approach are documented at [1]. > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > can obtain its devicetree at runtime, even it is has a devicetree built > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > caller may have a better idea about the hardware available in the machine. > This is the case with a few QEMU boards, for example. > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > option, available with either OF_SEPARATE or OF_EMBED. > > This series makes this change, adding various missing devicetree files > (and placeholders) to make the build work. Adding device trees that are never used sounds like a hack to me. For QEMU, device tree is dynamically generated on the fly based on command line parameters, and the device tree you put in this series has various hardcoded <phandle> values which normally do not show up in hand-written dts files. I am not sure I understand the whole point of this. > > It also provides a few qemu clean-ups discovered along the way. > > This series is based on Ilias' two series for OF_HOSTFILE and > OF_PRIOR_STAGE removal. > > It is available at u-boot-dm/ofb-working > > [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > Regards, Bin
On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > Hi Simon, > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote: > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > there are only three ways to obtain a devicetree: > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > appended to U-Boot > > - OF_EMBED - for development purposes, the devicetree is embedded in > > the ELF file (also used for EFI) > > - OF_BOARD - the board figures it out on its own > > > > The last one is currently set up so that no devicetree is needed at all > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > don't even provide instructions on how to boot on the board. > > > > The problems with this approach are documented at [1]. > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > can obtain its devicetree at runtime, even it is has a devicetree built > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > caller may have a better idea about the hardware available in the machine. > > This is the case with a few QEMU boards, for example. > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > option, available with either OF_SEPARATE or OF_EMBED. > > > > This series makes this change, adding various missing devicetree files > > (and placeholders) to make the build work. > > Adding device trees that are never used sounds like a hack to me. > > For QEMU, device tree is dynamically generated on the fly based on > command line parameters, and the device tree you put in this series > has various hardcoded <phandle> values which normally do not show up > in hand-written dts files. > > I am not sure I understand the whole point of this. I am also confused and do not like the idea of adding device trees for platforms that are capable of and can / do have a device tree to give us at run time.
On 10/13/21 03:01, Simon Glass wrote: > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > there are only three ways to obtain a devicetree: > > - OF_SEPARATE - the normal way, where the devicetree is built and > appended to U-Boot > - OF_EMBED - for development purposes, the devicetree is embedded in > the ELF file (also used for EFI) > - OF_BOARD - the board figures it out on its own > > The last one is currently set up so that no devicetree is needed at all > in the U-Boot tree. Most boards do provide one, but some don't. Some > don't even provide instructions on how to boot on the board. > > The problems with this approach are documented at [1]. > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > can obtain its devicetree at runtime, even it is has a devicetree built > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > caller may have a better idea about the hardware available in the machine. > This is the case with a few QEMU boards, for example. > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > option, available with either OF_SEPARATE or OF_EMBED. > > This series makes this change, adding various missing devicetree files > (and placeholders) to make the build work. Why should we add dummy files with irrelevant content (see patch 06/16) to make the build work? Why don't you fix the Makefile instead? Best regards Heinrich > > It also provides a few qemu clean-ups discovered along the way. > > This series is based on Ilias' two series for OF_HOSTFILE and > OF_PRIOR_STAGE removal. > > It is available at u-boot-dm/ofb-working > > [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > Simon Glass (16): > arm: qemu: Mention -nographic in the docs > arm: qemu: Explain how to extract the generate devicetree > riscv: qemu: Explain how to extract the generate devicetree > arm: qemu: Add a devicetree file for qemu_arm > arm: qemu: Add a devicetree file for qemu_arm64 > riscv: qemu: Add devicetree files for qemu_riscv32/64 > arm: rpi: Add a devicetree file for rpi_4 > arm: vexpress: Add a devicetree file for juno > arm: xenguest_arm64: Add a fake devicetree file > arm: octeontx: Add a fake devicetree file > arm: xilinx_versal_virt: Add a devicetree file > arm: bcm7xxx: Add a devicetree file > arm: qemu-ppce500: Add a devicetree file > arm: highbank: Add a fake devicetree file > fdt: Make OF_BOARD a bool option > Drop CONFIG_BINMAN_STANDALONE_FDT > > Makefile | 3 +- > arch/arm/dts/Makefile | 20 +- > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++ > arch/arm/dts/bcm7xxx.dts | 15 + > arch/arm/dts/highbank.dts | 14 + > arch/arm/dts/juno-r2.dts | 1038 +++++++++++++ > arch/arm/dts/octeontx.dts | 14 + > arch/arm/dts/qemu-arm.dts | 402 +++++ > arch/arm/dts/qemu-arm64.dts | 381 +++++ > arch/arm/dts/xenguest-arm64.dts | 15 + > arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ > arch/powerpc/dts/Makefile | 1 + > arch/powerpc/dts/qemu-ppce500.dts | 264 ++++ > arch/riscv/dts/Makefile | 2 +- > arch/riscv/dts/qemu-virt.dts | 8 - > arch/riscv/dts/qemu-virt32.dts | 217 +++ > arch/riscv/dts/qemu-virt64.dts | 217 +++ > configs/bcm7260_defconfig | 1 + > configs/bcm7445_defconfig | 1 + > configs/highbank_defconfig | 2 +- > configs/octeontx2_95xx_defconfig | 1 + > configs/octeontx2_96xx_defconfig | 1 + > configs/octeontx_81xx_defconfig | 1 + > configs/octeontx_83xx_defconfig | 1 + > configs/qemu-ppce500_defconfig | 2 + > configs/qemu-riscv32_defconfig | 1 + > configs/qemu-riscv32_smode_defconfig | 1 + > configs/qemu-riscv32_spl_defconfig | 4 +- > configs/qemu-riscv64_defconfig | 1 + > configs/qemu-riscv64_smode_defconfig | 1 + > configs/qemu-riscv64_spl_defconfig | 3 +- > configs/qemu_arm64_defconfig | 1 + > configs/qemu_arm_defconfig | 1 + > configs/rpi_4_32b_defconfig | 1 + > configs/rpi_4_defconfig | 1 + > configs/rpi_arm64_defconfig | 1 + > configs/vexpress_aemv8a_juno_defconfig | 1 + > configs/xenguest_arm64_defconfig | 1 + > configs/xilinx_versal_virt_defconfig | 1 + > doc/board/emulation/qemu-arm.rst | 19 +- > doc/board/emulation/qemu-riscv.rst | 12 + > dts/Kconfig | 27 +- > tools/binman/binman.rst | 20 - > 43 files changed, 4922 insertions(+), 61 deletions(-) > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > create mode 100644 arch/arm/dts/bcm7xxx.dts > create mode 100644 arch/arm/dts/highbank.dts > create mode 100644 arch/arm/dts/juno-r2.dts > create mode 100644 arch/arm/dts/octeontx.dts > create mode 100644 arch/arm/dts/qemu-arm.dts > create mode 100644 arch/arm/dts/qemu-arm64.dts > create mode 100644 arch/arm/dts/xenguest-arm64.dts > create mode 100644 arch/arm/dts/xilinx-versal-virt.dts > create mode 100644 arch/powerpc/dts/qemu-ppce500.dts > delete mode 100644 arch/riscv/dts/qemu-virt.dts > create mode 100644 arch/riscv/dts/qemu-virt32.dts > create mode 100644 arch/riscv/dts/qemu-virt64.dts >
Hi Simon Le mer. 13 oct. 2021 à 03:35, Tom Rini <trini@konsulko.com> a écrit : > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > Hi Simon, > > > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote: > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > there are only three ways to obtain a devicetree: > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > appended to U-Boot > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > the ELF file (also used for EFI) > > > - OF_BOARD - the board figures it out on its own > > > > > > The last one is currently set up so that no devicetree is needed at all > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > don't even provide instructions on how to boot on the board. > > > > > > The problems with this approach are documented at [1]. > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > board > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and > its > > > caller may have a better idea about the hardware available in the > machine. > > > This is the case with a few QEMU boards, for example. > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > This series makes this change, adding various missing devicetree files > > > (and placeholders) to make the build work. > > > > Adding device trees that are never used sounds like a hack to me. > > > > For QEMU, device tree is dynamically generated on the fly based on > > command line parameters, and the device tree you put in this series > > has various hardcoded <phandle> values which normally do not show up > > in hand-written dts files. > > > > I am not sure I understand the whole point of this. > > I am also confused and do not like the idea of adding device trees for > platforms that are capable of and can / do have a device tree to give us > at run time. > > -- > Tom +1 While the cleanup go get three options, including OF_BOARD is nice, the build solution you propose does not sound the right approach: U-Boot should be buildable without any DT. Getting the DT you produced as sample information can be useful and kept out of build path in documentation with ad-hoc warnings though as I explained in other mails of the series. OF_BOARD is a choice to say “I don’t override the legitimate DT with either OF_SEPARATE or OF_EMBED” (which I see in this case as debug facility for U-Boot maintainer of the platform). > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
On Tue, 12 Oct 2021 19:01:04 -0600 Simon Glass <sjg@chromium.org> wrote: Hi, > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > there are only three ways to obtain a devicetree: > > - OF_SEPARATE - the normal way, where the devicetree is built and > appended to U-Boot > - OF_EMBED - for development purposes, the devicetree is embedded in > the ELF file (also used for EFI) > - OF_BOARD - the board figures it out on its own > > The last one is currently set up so that no devicetree is needed at all > in the U-Boot tree. Most boards do provide one, but some don't. Some > don't even provide instructions on how to boot on the board. > > The problems with this approach are documented at [1]. > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > can obtain its devicetree at runtime, even it is has a devicetree built > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > caller may have a better idea about the hardware available in the machine. > This is the case with a few QEMU boards, for example. > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > option, available with either OF_SEPARATE or OF_EMBED. So I am possibly fine with that, but: > This series makes this change, adding various missing devicetree files > (and placeholders) to make the build work. If we just need it to make the build work, we not just have pure stub DTs, as you do for highbank, everywhere? Adding *some* DT files for those platforms that actually do the right thing seems like the wrong direction to me. Providing DTs in the source repositories of the actual consumers is more of a bad habit that dragged on since Linux started this around 10 years ago (for practical reasons). For *some* platforms U-Boot is the firmware component that is in the best situation to provide the DTB (because it's more than a mere bootloader), but for other it's just not. And this is not even looking at really dynamic platforms like QEMU, where providing some kind of fixed DT is just not working. I don't get the argument that people would need to see the DT in the tree to develop code. The DT spec and binding documentation (currently living in the Linux kernel source tree) provide the specification to code against, and the platform specific selection of drivers in Kconfig and _defconfig select the drivers for the devices that people are expected to see. Why does one need actual DT files in the tree? I totally agree on adding more documentation, possibly *pointing* to example DTs or giving commands on how to obtain the actual copy (-dumpdtb, /sys/firmware/devicetree), but don't think that adding some .dts files for platforms that don't need them is the right way. Cheers, Andre. > > It also provides a few qemu clean-ups discovered along the way. > > This series is based on Ilias' two series for OF_HOSTFILE and > OF_PRIOR_STAGE removal. > > It is available at u-boot-dm/ofb-working > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > Simon Glass (16): > arm: qemu: Mention -nographic in the docs > arm: qemu: Explain how to extract the generate devicetree > riscv: qemu: Explain how to extract the generate devicetree > arm: qemu: Add a devicetree file for qemu_arm > arm: qemu: Add a devicetree file for qemu_arm64 > riscv: qemu: Add devicetree files for qemu_riscv32/64 > arm: rpi: Add a devicetree file for rpi_4 > arm: vexpress: Add a devicetree file for juno > arm: xenguest_arm64: Add a fake devicetree file > arm: octeontx: Add a fake devicetree file > arm: xilinx_versal_virt: Add a devicetree file > arm: bcm7xxx: Add a devicetree file > arm: qemu-ppce500: Add a devicetree file > arm: highbank: Add a fake devicetree file > fdt: Make OF_BOARD a bool option > Drop CONFIG_BINMAN_STANDALONE_FDT > > Makefile | 3 +- > arch/arm/dts/Makefile | 20 +- > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++ > arch/arm/dts/bcm7xxx.dts | 15 + > arch/arm/dts/highbank.dts | 14 + > arch/arm/dts/juno-r2.dts | 1038 +++++++++++++ > arch/arm/dts/octeontx.dts | 14 + > arch/arm/dts/qemu-arm.dts | 402 +++++ > arch/arm/dts/qemu-arm64.dts | 381 +++++ > arch/arm/dts/xenguest-arm64.dts | 15 + > arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ > arch/powerpc/dts/Makefile | 1 + > arch/powerpc/dts/qemu-ppce500.dts | 264 ++++ > arch/riscv/dts/Makefile | 2 +- > arch/riscv/dts/qemu-virt.dts | 8 - > arch/riscv/dts/qemu-virt32.dts | 217 +++ > arch/riscv/dts/qemu-virt64.dts | 217 +++ > configs/bcm7260_defconfig | 1 + > configs/bcm7445_defconfig | 1 + > configs/highbank_defconfig | 2 +- > configs/octeontx2_95xx_defconfig | 1 + > configs/octeontx2_96xx_defconfig | 1 + > configs/octeontx_81xx_defconfig | 1 + > configs/octeontx_83xx_defconfig | 1 + > configs/qemu-ppce500_defconfig | 2 + > configs/qemu-riscv32_defconfig | 1 + > configs/qemu-riscv32_smode_defconfig | 1 + > configs/qemu-riscv32_spl_defconfig | 4 +- > configs/qemu-riscv64_defconfig | 1 + > configs/qemu-riscv64_smode_defconfig | 1 + > configs/qemu-riscv64_spl_defconfig | 3 +- > configs/qemu_arm64_defconfig | 1 + > configs/qemu_arm_defconfig | 1 + > configs/rpi_4_32b_defconfig | 1 + > configs/rpi_4_defconfig | 1 + > configs/rpi_arm64_defconfig | 1 + > configs/vexpress_aemv8a_juno_defconfig | 1 + > configs/xenguest_arm64_defconfig | 1 + > configs/xilinx_versal_virt_defconfig | 1 + > doc/board/emulation/qemu-arm.rst | 19 +- > doc/board/emulation/qemu-riscv.rst | 12 + > dts/Kconfig | 27 +- > tools/binman/binman.rst | 20 - > 43 files changed, 4922 insertions(+), 61 deletions(-) > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > create mode 100644 arch/arm/dts/bcm7xxx.dts > create mode 100644 arch/arm/dts/highbank.dts > create mode 100644 arch/arm/dts/juno-r2.dts > create mode 100644 arch/arm/dts/octeontx.dts > create mode 100644 arch/arm/dts/qemu-arm.dts > create mode 100644 arch/arm/dts/qemu-arm64.dts > create mode 100644 arch/arm/dts/xenguest-arm64.dts > create mode 100644 arch/arm/dts/xilinx-versal-virt.dts > create mode 100644 arch/powerpc/dts/qemu-ppce500.dts > delete mode 100644 arch/riscv/dts/qemu-virt.dts > create mode 100644 arch/riscv/dts/qemu-virt32.dts > create mode 100644 arch/riscv/dts/qemu-virt64.dts >
Hi Simon, On 10/13/21 03:29, Bin Meng wrote: > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote: >> >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so >> there are only three ways to obtain a devicetree: >> >> - OF_SEPARATE - the normal way, where the devicetree is built and >> appended to U-Boot >> - OF_EMBED - for development purposes, the devicetree is embedded in >> the ELF file (also used for EFI) >> - OF_BOARD - the board figures it out on its own >> >> The last one is currently set up so that no devicetree is needed at all >> in the U-Boot tree. Most boards do provide one, but some don't. Some >> don't even provide instructions on how to boot on the board. >> >> The problems with this approach are documented at [1]. >> >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board >> can obtain its devicetree at runtime, even it is has a devicetree built >> in U-Boot. This is because U-Boot may be a second-stage bootloader and its >> caller may have a better idea about the hardware available in the machine. >> This is the case with a few QEMU boards, for example. >> >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an >> option, available with either OF_SEPARATE or OF_EMBED. >> >> This series makes this change, adding various missing devicetree files >> (and placeholders) to make the build work. > > Adding device trees that are never used sounds like a hack to me. > > For QEMU, device tree is dynamically generated on the fly based on > command line parameters, and the device tree you put in this series > has various hardcoded <phandle> values which normally do not show up > in hand-written dts files. Besides, QEMU generates these dtb at runtime on purpose: it gives emulated machines the freedom to evolve by adding new devices, mapping/wiring peripherals differently. By adding static dtb this gives QEMU users false expectations the machine hardware is stable, or force QEMU to have this interface become a stable API. From QEMU perspective this seems counter-productive. Digging a bit I see this has already been discussed on qemu-devel@ mailing list recently: https://lore.kernel.org/qemu-devel/CAFEAcA_QNcAHtdxUPLpmyzMYgb9YzhcE0-zyh=N8rqm4vOcGZA@mail.gmail.com/ > I am not sure I understand the whole point of this. > >> >> It also provides a few qemu clean-ups discovered along the way. >> >> This series is based on Ilias' two series for OF_HOSTFILE and >> OF_PRIOR_STAGE removal. >> >> It is available at u-boot-dm/ofb-working >> >> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ >> > > Regards, > Bin >
Le mer. 13 oct. 2021 à 14:41, Andre Przywara <andre.przywara@arm.com> a écrit : > On Tue, 12 Oct 2021 19:01:04 -0600 > Simon Glass <sjg@chromium.org> wrote: > > Hi, > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > there are only three ways to obtain a devicetree: > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > appended to U-Boot > > - OF_EMBED - for development purposes, the devicetree is embedded in > > the ELF file (also used for EFI) > > - OF_BOARD - the board figures it out on its own > > > > The last one is currently set up so that no devicetree is needed at all > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > don't even provide instructions on how to boot on the board. > > > > The problems with this approach are documented at [1]. > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > can obtain its devicetree at runtime, even it is has a devicetree built > > in U-Boot. This is because U-Boot may be a second-stage bootloader and > its > > caller may have a better idea about the hardware available in the > machine. > > This is the case with a few QEMU boards, for example. > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > option, available with either OF_SEPARATE or OF_EMBED. > > So I am possibly fine with that, but: > > > This series makes this change, adding various missing devicetree files > > (and placeholders) to make the build work. > > If we just need it to make the build work, we not just have pure stub DTs, > as you do for highbank, everywhere? > Adding *some* DT files for those platforms that actually do the right > thing seems like the wrong direction to me. > Providing DTs in the source repositories of the actual consumers is more > of a bad habit that dragged on since Linux started this around 10 years > ago (for practical reasons). For *some* platforms U-Boot is the firmware > component that is in the best situation to provide the DTB (because it's > more than a mere bootloader), but for other it's just not. And this is not > even looking at really dynamic platforms like QEMU, where providing some > kind of fixed DT is just not working. > > I don't get the argument that people would need to see the DT in the tree > to develop code. The DT spec and binding documentation (currently living > in the Linux kernel source tree) provide the specification to code > against, and the platform specific selection of drivers in Kconfig and > _defconfig select the drivers for the devices that people are expected to > see. Why does one need actual DT files in the tree? > > I totally agree on adding more documentation, possibly *pointing* to > example > DTs or giving commands on how to obtain the actual copy (-dumpdtb, > /sys/firmware/devicetree), but don't think that adding some .dts files for > platforms that don't need them is the right way. > > Cheers, > Andre. +1 > > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > This series is based on Ilias' two series for OF_HOSTFILE and > > OF_PRIOR_STAGE removal. > > > > It is available at u-boot-dm/ofb-working > > > > [1] > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > Simon Glass (16): > > arm: qemu: Mention -nographic in the docs > > arm: qemu: Explain how to extract the generate devicetree > > riscv: qemu: Explain how to extract the generate devicetree > > arm: qemu: Add a devicetree file for qemu_arm > > arm: qemu: Add a devicetree file for qemu_arm64 > > riscv: qemu: Add devicetree files for qemu_riscv32/64 > > arm: rpi: Add a devicetree file for rpi_4 > > arm: vexpress: Add a devicetree file for juno > > arm: xenguest_arm64: Add a fake devicetree file > > arm: octeontx: Add a fake devicetree file > > arm: xilinx_versal_virt: Add a devicetree file > > arm: bcm7xxx: Add a devicetree file > > arm: qemu-ppce500: Add a devicetree file > > arm: highbank: Add a fake devicetree file > > fdt: Make OF_BOARD a bool option > > Drop CONFIG_BINMAN_STANDALONE_FDT > > > > Makefile | 3 +- > > arch/arm/dts/Makefile | 20 +- > > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++ > > arch/arm/dts/bcm7xxx.dts | 15 + > > arch/arm/dts/highbank.dts | 14 + > > arch/arm/dts/juno-r2.dts | 1038 +++++++++++++ > > arch/arm/dts/octeontx.dts | 14 + > > arch/arm/dts/qemu-arm.dts | 402 +++++ > > arch/arm/dts/qemu-arm64.dts | 381 +++++ > > arch/arm/dts/xenguest-arm64.dts | 15 + > > arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ > > arch/powerpc/dts/Makefile | 1 + > > arch/powerpc/dts/qemu-ppce500.dts | 264 ++++ > > arch/riscv/dts/Makefile | 2 +- > > arch/riscv/dts/qemu-virt.dts | 8 - > > arch/riscv/dts/qemu-virt32.dts | 217 +++ > > arch/riscv/dts/qemu-virt64.dts | 217 +++ > > configs/bcm7260_defconfig | 1 + > > configs/bcm7445_defconfig | 1 + > > configs/highbank_defconfig | 2 +- > > configs/octeontx2_95xx_defconfig | 1 + > > configs/octeontx2_96xx_defconfig | 1 + > > configs/octeontx_81xx_defconfig | 1 + > > configs/octeontx_83xx_defconfig | 1 + > > configs/qemu-ppce500_defconfig | 2 + > > configs/qemu-riscv32_defconfig | 1 + > > configs/qemu-riscv32_smode_defconfig | 1 + > > configs/qemu-riscv32_spl_defconfig | 4 +- > > configs/qemu-riscv64_defconfig | 1 + > > configs/qemu-riscv64_smode_defconfig | 1 + > > configs/qemu-riscv64_spl_defconfig | 3 +- > > configs/qemu_arm64_defconfig | 1 + > > configs/qemu_arm_defconfig | 1 + > > configs/rpi_4_32b_defconfig | 1 + > > configs/rpi_4_defconfig | 1 + > > configs/rpi_arm64_defconfig | 1 + > > configs/vexpress_aemv8a_juno_defconfig | 1 + > > configs/xenguest_arm64_defconfig | 1 + > > configs/xilinx_versal_virt_defconfig | 1 + > > doc/board/emulation/qemu-arm.rst | 19 +- > > doc/board/emulation/qemu-riscv.rst | 12 + > > dts/Kconfig | 27 +- > > tools/binman/binman.rst | 20 - > > 43 files changed, 4922 insertions(+), 61 deletions(-) > > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > > create mode 100644 arch/arm/dts/bcm7xxx.dts > > create mode 100644 arch/arm/dts/highbank.dts > > create mode 100644 arch/arm/dts/juno-r2.dts > > create mode 100644 arch/arm/dts/octeontx.dts > > create mode 100644 arch/arm/dts/qemu-arm.dts > > create mode 100644 arch/arm/dts/qemu-arm64.dts > > create mode 100644 arch/arm/dts/xenguest-arm64.dts > > create mode 100644 arch/arm/dts/xilinx-versal-virt.dts > > create mode 100644 arch/powerpc/dts/qemu-ppce500.dts > > delete mode 100644 arch/riscv/dts/qemu-virt.dts > > create mode 100644 arch/riscv/dts/qemu-virt32.dts > > create mode 100644 arch/riscv/dts/qemu-virt64.dts > > > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
Le mer. 13 oct. 2021 à 14:41, Heinrich Schuchardt < heinrich.schuchardt@canonical.com> a écrit : > > > On 10/13/21 03:01, Simon Glass wrote: > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > there are only three ways to obtain a devicetree: > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > appended to U-Boot > > - OF_EMBED - for development purposes, the devicetree is embedded in > > the ELF file (also used for EFI) > > - OF_BOARD - the board figures it out on its own > > > > The last one is currently set up so that no devicetree is needed at all > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > don't even provide instructions on how to boot on the board. > > > > The problems with this approach are documented at [1]. > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > can obtain its devicetree at runtime, even it is has a devicetree built > > in U-Boot. This is because U-Boot may be a second-stage bootloader and > its > > caller may have a better idea about the hardware available in the > machine. > > This is the case with a few QEMU boards, for example. > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > option, available with either OF_SEPARATE or OF_EMBED. > > > > This series makes this change, adding various missing devicetree files > > (and placeholders) to make the build work. > > Why should we add dummy files with irrelevant content (see patch 06/16) > to make the build work? Why don't you fix the Makefile instead? > +1 > > Best regards > > Heinrich > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > This series is based on Ilias' two series for OF_HOSTFILE and > > OF_PRIOR_STAGE removal. > > > > It is available at u-boot-dm/ofb-working > > > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > Simon Glass (16): > > arm: qemu: Mention -nographic in the docs > > arm: qemu: Explain how to extract the generate devicetree > > riscv: qemu: Explain how to extract the generate devicetree > > arm: qemu: Add a devicetree file for qemu_arm > > arm: qemu: Add a devicetree file for qemu_arm64 > > riscv: qemu: Add devicetree files for qemu_riscv32/64 > > arm: rpi: Add a devicetree file for rpi_4 > > arm: vexpress: Add a devicetree file for juno > > arm: xenguest_arm64: Add a fake devicetree file > > arm: octeontx: Add a fake devicetree file > > arm: xilinx_versal_virt: Add a devicetree file > > arm: bcm7xxx: Add a devicetree file > > arm: qemu-ppce500: Add a devicetree file > > arm: highbank: Add a fake devicetree file > > fdt: Make OF_BOARD a bool option > > Drop CONFIG_BINMAN_STANDALONE_FDT > > > > Makefile | 3 +- > > arch/arm/dts/Makefile | 20 +- > > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++ > > arch/arm/dts/bcm7xxx.dts | 15 + > > arch/arm/dts/highbank.dts | 14 + > > arch/arm/dts/juno-r2.dts | 1038 +++++++++++++ > > arch/arm/dts/octeontx.dts | 14 + > > arch/arm/dts/qemu-arm.dts | 402 +++++ > > arch/arm/dts/qemu-arm64.dts | 381 +++++ > > arch/arm/dts/xenguest-arm64.dts | 15 + > > arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ > > arch/powerpc/dts/Makefile | 1 + > > arch/powerpc/dts/qemu-ppce500.dts | 264 ++++ > > arch/riscv/dts/Makefile | 2 +- > > arch/riscv/dts/qemu-virt.dts | 8 - > > arch/riscv/dts/qemu-virt32.dts | 217 +++ > > arch/riscv/dts/qemu-virt64.dts | 217 +++ > > configs/bcm7260_defconfig | 1 + > > configs/bcm7445_defconfig | 1 + > > configs/highbank_defconfig | 2 +- > > configs/octeontx2_95xx_defconfig | 1 + > > configs/octeontx2_96xx_defconfig | 1 + > > configs/octeontx_81xx_defconfig | 1 + > > configs/octeontx_83xx_defconfig | 1 + > > configs/qemu-ppce500_defconfig | 2 + > > configs/qemu-riscv32_defconfig | 1 + > > configs/qemu-riscv32_smode_defconfig | 1 + > > configs/qemu-riscv32_spl_defconfig | 4 +- > > configs/qemu-riscv64_defconfig | 1 + > > configs/qemu-riscv64_smode_defconfig | 1 + > > configs/qemu-riscv64_spl_defconfig | 3 +- > > configs/qemu_arm64_defconfig | 1 + > > configs/qemu_arm_defconfig | 1 + > > configs/rpi_4_32b_defconfig | 1 + > > configs/rpi_4_defconfig | 1 + > > configs/rpi_arm64_defconfig | 1 + > > configs/vexpress_aemv8a_juno_defconfig | 1 + > > configs/xenguest_arm64_defconfig | 1 + > > configs/xilinx_versal_virt_defconfig | 1 + > > doc/board/emulation/qemu-arm.rst | 19 +- > > doc/board/emulation/qemu-riscv.rst | 12 + > > dts/Kconfig | 27 +- > > tools/binman/binman.rst | 20 - > > 43 files changed, 4922 insertions(+), 61 deletions(-) > > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > > create mode 100644 arch/arm/dts/bcm7xxx.dts > > create mode 100644 arch/arm/dts/highbank.dts > > create mode 100644 arch/arm/dts/juno-r2.dts > > create mode 100644 arch/arm/dts/octeontx.dts > > create mode 100644 arch/arm/dts/qemu-arm.dts > > create mode 100644 arch/arm/dts/qemu-arm64.dts > > create mode 100644 arch/arm/dts/xenguest-arm64.dts > > create mode 100644 arch/arm/dts/xilinx-versal-virt.dts > > create mode 100644 arch/powerpc/dts/qemu-ppce500.dts > > delete mode 100644 arch/riscv/dts/qemu-virt.dts > > create mode 100644 arch/riscv/dts/qemu-virt32.dts > > create mode 100644 arch/riscv/dts/qemu-virt64.dts > > >
Le mer. 13 oct. 2021 à 14:42, Philippe Mathieu-Daudé <philmd@redhat.com> a écrit : > Hi Simon, > > On 10/13/21 03:29, Bin Meng wrote: > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote: > >> > >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > >> there are only three ways to obtain a devicetree: > >> > >> - OF_SEPARATE - the normal way, where the devicetree is built and > >> appended to U-Boot > >> - OF_EMBED - for development purposes, the devicetree is embedded in > >> the ELF file (also used for EFI) > >> - OF_BOARD - the board figures it out on its own > >> > >> The last one is currently set up so that no devicetree is needed at all > >> in the U-Boot tree. Most boards do provide one, but some don't. Some > >> don't even provide instructions on how to boot on the board. > >> > >> The problems with this approach are documented at [1]. > >> > >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > >> can obtain its devicetree at runtime, even it is has a devicetree built > >> in U-Boot. This is because U-Boot may be a second-stage bootloader and > its > >> caller may have a better idea about the hardware available in the > machine. > >> This is the case with a few QEMU boards, for example. > >> > >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an > >> option, available with either OF_SEPARATE or OF_EMBED. > >> > >> This series makes this change, adding various missing devicetree files > >> (and placeholders) to make the build work. > > > > Adding device trees that are never used sounds like a hack to me. > > > > For QEMU, device tree is dynamically generated on the fly based on > > command line parameters, and the device tree you put in this series > > has various hardcoded <phandle> values which normally do not show up > > in hand-written dts files. > > Besides, QEMU generates these dtb at runtime on purpose: it gives > emulated machines the freedom to evolve by adding new devices, > mapping/wiring peripherals differently. > > By adding static dtb this gives QEMU users false expectations the > machine hardware is stable, or force QEMU to have this interface > become a stable API. > > From QEMU perspective this seems counter-productive. > +1 > > Digging a bit I see this has already been discussed on qemu-devel@ > mailing list recently: > > > https://lore.kernel.org/qemu-devel/CAFEAcA_QNcAHtdxUPLpmyzMYgb9YzhcE0-zyh=N8rqm4vOcGZA@mail.gmail.com/ > > > I am not sure I understand the whole point of this. > > > >> > >> It also provides a few qemu clean-ups discovered along the way. > >> > >> This series is based on Ilias' two series for OF_HOSTFILE and > >> OF_PRIOR_STAGE removal. > >> > >> It is available at u-boot-dm/ofb-working > >> > >> [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > >> > > > > Regards, > > Bin > > > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
Hi Tom, Bin,François, On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > Hi Simon, > > > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote: > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > there are only three ways to obtain a devicetree: > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > appended to U-Boot > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > the ELF file (also used for EFI) > > > - OF_BOARD - the board figures it out on its own > > > > > > The last one is currently set up so that no devicetree is needed at all > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > don't even provide instructions on how to boot on the board. > > > > > > The problems with this approach are documented at [1]. > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > caller may have a better idea about the hardware available in the machine. > > > This is the case with a few QEMU boards, for example. > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > This series makes this change, adding various missing devicetree files > > > (and placeholders) to make the build work. > > > > Adding device trees that are never used sounds like a hack to me. > > > > For QEMU, device tree is dynamically generated on the fly based on > > command line parameters, and the device tree you put in this series > > has various hardcoded <phandle> values which normally do not show up > > in hand-written dts files. > > > > I am not sure I understand the whole point of this. > > I am also confused and do not like the idea of adding device trees for > platforms that are capable of and can / do have a device tree to give us > at run time. (I'll just reply to this one email, since the same points applies to all replies I think) I have been thinking about this and discussing it with people for a few months now. I've been signalling a change like this for over a month now, on U-Boot contributor calls and in discussions with Linaro people. I sent a patch (below) to try to explain things. I hope it is not a surprise! The issue here is that we need a devicetree in-tree in U-Boot, to avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between Ilias' series and this one we can get ourselves on a stronger footing. There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. For more context: http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ BTW I did suggest to QEMU ARM that they support a way of adding the u-boot.dtsi but there was not much interest there (in fact the maintainer would prefer there was no special support even for booting Linux directly!) But in any case it doesn't really help U-Boot. I think the path forward might be to run QEMU twice, once to get its generated tree and once to give the 'merged' tree with the U-Boot properties in it, if people want to use U-Boot features. I do strongly believe that OF_BOARD must be a run-time option, not a build-time one. It creates all sorts of problems and obscurity which have taken months to unpick. See the above patch for the rationale. To add to that rationale, OF_BOARD needs to be an option available to any board. At some point in the future it may become a common way things are done, e.g. TF-A calling U-Boot and providing a devicetree to it. It doesn't make any sense to have people decide whether or not to set OF_BOARD at build time, thus affecting how the image is put together. We'll end up with different U-Boot build targets like capricorn, capricorn_of_board and the like. It should be obvious where that will lead. Instead, OF_BOARD needs to become a commonly used option, perhaps enabled by most/all boards, so that this sort of build explosion is not needed. U-Boot needs to be flexible enough to function correctly in whatever runtime environment in which it finds itself. Also as binman is pressed into service more and more to build the complex firmware images that are becoming fashionable, it needs a definition (in the devicetree) that describes how to create the image. We can't support that unless we are building a devicetree, nor can the running program access the image layout without that information. François's point about 'don't use this with any kernel' is germane...but of course I am not suggesting doing that, since OF_BOARD is, still, enabled. We already use OF_BOARD for various boards that include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example (as I said in the cover letter "Most boards do provide one, but some don't."). So this series is just completing the picture by enforcing that *some sort* of devicetree is always present. I can't quite pinpoint the patch where U-Boot started allowing the devicetree to be omitted, but if people are interested I could try a little harder. It was certainly not my intention (putting on my device-tree-maintainer hat) to go down that path and it slipped in somehow in all the confusion. I'm not sure anyone could tell you that rpi_3 has an in-tree devicetree but rpi_4 does not... Anyway this series is very modest. It just adds the requirement that all in-tree boards have some sort of sample devicetree and preferably some documentation as to where it might come from at runtime. That should not be a tough call IMO. Assuming we can get the validation in place (mentioned by Rob Herring recently) it will be quite natural to sync them between (presumably) Linux and U-Boot. I am also quite happy to discuss what should actually be in these devicetree files and whether some of them should be essentially empty. As you probably noticed, some of them are empty since I literally could not figure out where they come from! But there needs to be at least some skeleton for U-Boot to progress, since devicetree is critical to its feature set. It is high time we tidied all this up. I predict it will be much harder, and much more confusing, in 6 months. Regards, Simon
Hi Simon Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > Hi Tom, Bin,François, > > On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > Hi Simon, > > > > > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote: > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > there are only three ways to obtain a devicetree: > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > appended to U-Boot > > > > - OF_EMBED - for development purposes, the devicetree is embedded > in > > > > the ELF file (also used for EFI) > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > The last one is currently set up so that no devicetree is needed at > all > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > don't even provide instructions on how to boot on the board. > > > > > > > > The problems with this approach are documented at [1]. > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > board > > > > can obtain its devicetree at runtime, even it is has a devicetree > built > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader > and its > > > > caller may have a better idea about the hardware available in the > machine. > > > > This is the case with a few QEMU boards, for example. > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > This series makes this change, adding various missing devicetree > files > > > > (and placeholders) to make the build work. > > > > > > Adding device trees that are never used sounds like a hack to me. > > > > > > For QEMU, device tree is dynamically generated on the fly based on > > > command line parameters, and the device tree you put in this series > > > has various hardcoded <phandle> values which normally do not show up > > > in hand-written dts files. > > > > > > I am not sure I understand the whole point of this. > > > > I am also confused and do not like the idea of adding device trees for > > platforms that are capable of and can / do have a device tree to give us > > at run time. > > (I'll just reply to this one email, since the same points applies to > all replies I think) > > I have been thinking about this and discussing it with people for a > few months now. I've been signalling a change like this for over a > month now, on U-Boot contributor calls and in discussions with Linaro > people. I sent a patch (below) to try to explain things. I hope it is > not a surprise! > > The issue here is that we need a devicetree in-tree in U-Boot, to > avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > Ilias' series and this one we can get ourselves on a stronger footing. > There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > For more context: > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > BTW I did suggest to QEMU ARM that they support a way of adding the > u-boot.dtsi but there was not much interest there (in fact the > maintainer would prefer there was no special support even for booting > Linux directly!) i understand their point of view and agree with it. > But in any case it doesn't really help U-Boot. I > think the path forward might be to run QEMU twice, once to get its > generated tree and once to give the 'merged' tree with the U-Boot > properties in it, if people want to use U-Boot features. > > I do strongly believe that OF_BOARD must be a run-time option, not a > build-time one. It creates all sorts of problems and obscurity which > have taken months to unpick. See the above patch for the rationale. > > To add to that rationale, OF_BOARD needs to be an option available to > any board. At some point in the future it may become a common way > things are done, e.g. TF-A calling U-Boot and providing a devicetree > to it. It doesn't make any sense to have people decide whether or not > to set OF_BOARD at build time, thus affecting how the image is put > together. We'll end up with different U-Boot build targets like > capricorn, capricorn_of_board and the like. It should be obvious where > that will lead. Instead, OF_BOARD needs to become a commonly used > option, perhaps enabled by most/all boards, so that this sort of build > explosion is not needed. If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. > U-Boot needs to be flexible enough to > function correctly in whatever runtime environment in which it finds > itself. > > Also as binman is pressed into service more and more to build the > complex firmware images that are becoming fashionable, it needs a > definition (in the devicetree) that describes how to create the image. > We can't support that unless we are building a devicetree, nor can the > running program access the image layout without that information. > > François's point about 'don't use this with any kernel' is > germane...but of course I am not suggesting doing that, since OF_BOARD > is, still, enabled. We already use OF_BOARD for various boards that > include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > (as I said in the cover letter "Most boards do provide one, but some > don't."). So this series is just completing the picture by enforcing > that *some sort* of devicetree is always present. > That seems inconsistent with the OF_BOARD becomes the default. > > I can't quite pinpoint the patch where U-Boot started allowing the > devicetree to be omitted, but if people are interested I could try a > little harder. It was certainly not my intention (putting on my > device-tree-maintainer hat) to go down that path and it slipped in > somehow in all the confusion. I'm not sure anyone could tell you that > rpi_3 has an in-tree devicetree but rpi_4 does not... > > Anyway this series is very modest. It just adds the requirement that > all in-tree boards have some sort of sample devicetree and preferably > some documentation as to where it might come from at runtime. That’s a very good goal. But adding files in dts make them not samples but templates to be used and replace board provided DTB. If you push all your DTS files in documentation, you do what you say: adding sample files. > That > should not be a tough call IMO. Assuming we can get the validation in > place (mentioned by Rob Herring recently) it will be quite natural to > sync them between (presumably) Linux and U-Boot. > > I am also quite happy to discuss what should actually be in these > devicetree files and whether some of them should be essentially empty. > As you probably noticed, some of them are empty since I literally > could not figure out where they come from! But there needs to be at > least some skeleton for U-Boot to progress, since devicetree is > critical to its feature set. absolutely. And thank you for your efforts to make that center stage. This is also Linaro Edge group mist challenging task on the next 6 moths. Knowing that we have lived in a floating situation for over 10 years, I just hope we get consensus across projects and distro providers about the right end goal and migration strategy. > > > It is high time we tidied all this up. I predict it will be much > harder, and much more confusing, in 6 months. > > Regards, > Simon >
Hi François, On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: > > Hi Simon > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : >> >> Hi Tom, Bin,François, >> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: >> > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: >> > > Hi Simon, >> > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote: >> > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so >> > > > there are only three ways to obtain a devicetree: >> > > > >> > > > - OF_SEPARATE - the normal way, where the devicetree is built and >> > > > appended to U-Boot >> > > > - OF_EMBED - for development purposes, the devicetree is embedded in >> > > > the ELF file (also used for EFI) >> > > > - OF_BOARD - the board figures it out on its own >> > > > >> > > > The last one is currently set up so that no devicetree is needed at all >> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some >> > > > don't even provide instructions on how to boot on the board. >> > > > >> > > > The problems with this approach are documented at [1]. >> > > > >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board >> > > > can obtain its devicetree at runtime, even it is has a devicetree built >> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its >> > > > caller may have a better idea about the hardware available in the machine. >> > > > This is the case with a few QEMU boards, for example. >> > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an >> > > > option, available with either OF_SEPARATE or OF_EMBED. >> > > > >> > > > This series makes this change, adding various missing devicetree files >> > > > (and placeholders) to make the build work. >> > > >> > > Adding device trees that are never used sounds like a hack to me. >> > > >> > > For QEMU, device tree is dynamically generated on the fly based on >> > > command line parameters, and the device tree you put in this series >> > > has various hardcoded <phandle> values which normally do not show up >> > > in hand-written dts files. >> > > >> > > I am not sure I understand the whole point of this. >> > >> > I am also confused and do not like the idea of adding device trees for >> > platforms that are capable of and can / do have a device tree to give us >> > at run time. >> >> (I'll just reply to this one email, since the same points applies to >> all replies I think) >> >> I have been thinking about this and discussing it with people for a >> few months now. I've been signalling a change like this for over a >> month now, on U-Boot contributor calls and in discussions with Linaro >> people. I sent a patch (below) to try to explain things. I hope it is >> not a surprise! >> >> The issue here is that we need a devicetree in-tree in U-Boot, to >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between >> Ilias' series and this one we can get ourselves on a stronger footing. >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. >> For more context: >> >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ >> >> BTW I did suggest to QEMU ARM that they support a way of adding the >> u-boot.dtsi but there was not much interest there (in fact the >> maintainer would prefer there was no special support even for booting >> Linux directly!) > > i understand their point of view and agree with it. >> >> But in any case it doesn't really help U-Boot. I >> think the path forward might be to run QEMU twice, once to get its >> generated tree and once to give the 'merged' tree with the U-Boot >> properties in it, if people want to use U-Boot features. >> >> I do strongly believe that OF_BOARD must be a run-time option, not a >> build-time one. It creates all sorts of problems and obscurity which >> have taken months to unpick. See the above patch for the rationale. >> >> To add to that rationale, OF_BOARD needs to be an option available to >> any board. At some point in the future it may become a common way >> things are done, e.g. TF-A calling U-Boot and providing a devicetree >> to it. It doesn't make any sense to have people decide whether or not >> to set OF_BOARD at build time, thus affecting how the image is put >> together. We'll end up with different U-Boot build targets like >> capricorn, capricorn_of_board and the like. It should be obvious where >> that will lead. Instead, OF_BOARD needs to become a commonly used >> option, perhaps enabled by most/all boards, so that this sort of build >> explosion is not needed. > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. >> >> U-Boot needs to be flexible enough to >> function correctly in whatever runtime environment in which it finds >> itself. >> >> Also as binman is pressed into service more and more to build the >> complex firmware images that are becoming fashionable, it needs a >> definition (in the devicetree) that describes how to create the image. >> We can't support that unless we are building a devicetree, nor can the >> running program access the image layout without that information. >> >> François's point about 'don't use this with any kernel' is >> germane...but of course I am not suggesting doing that, since OF_BOARD >> is, still, enabled. We already use OF_BOARD for various boards that >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example >> (as I said in the cover letter "Most boards do provide one, but some >> don't."). So this series is just completing the picture by enforcing >> that *some sort* of devicetree is always present. > > That seems inconsistent with the OF_BOARD becomes the default. I think the key point that will get you closer to where I am on this issue, is that OF_BOARD needs to be a run-time option. At present it has build-time effects and this is quite wrong. If you go through all the material I have written on this I think I have motivated that very clearly. Another big issue is that I believe we need ONE devicetree for U-Boot, not two that get merged by U-Boot. Again I have gone through that in a lot of detail. >> >> >> I can't quite pinpoint the patch where U-Boot started allowing the >> devicetree to be omitted, but if people are interested I could try a >> little harder. It was certainly not my intention (putting on my >> device-tree-maintainer hat) to go down that path and it slipped in >> somehow in all the confusion. I'm not sure anyone could tell you that >> rpi_3 has an in-tree devicetree but rpi_4 does not... >> >> Anyway this series is very modest. It just adds the requirement that >> all in-tree boards have some sort of sample devicetree and preferably >> some documentation as to where it might come from at runtime. > > That’s a very good goal. But adding files in dts make them not samples but templates to be used and replace board provided DTB. > If you push all your DTS files in documentation, you do what you say: adding sample files. >> >> That >> should not be a tough call IMO. Assuming we can get the validation in >> place (mentioned by Rob Herring recently) it will be quite natural to >> sync them between (presumably) Linux and U-Boot. >> >> I am also quite happy to discuss what should actually be in these >> devicetree files and whether some of them should be essentially empty. >> As you probably noticed, some of them are empty since I literally >> could not figure out where they come from! But there needs to be at >> least some skeleton for U-Boot to progress, since devicetree is >> critical to its feature set. > > absolutely. And thank you for your efforts to make that center stage. This is also Linaro Edge group mist challenging task on the next 6 moths. Knowing that we have lived in a floating situation for over 10 years, I just hope we get consensus across projects and distro providers about the right end goal and migration strategy. >> Thank you. >> >> >> It is high time we tidied all this up. I predict it will be much >> harder, and much more confusing, in 6 months. Just to set a road map here in case you can help unblock anything, here are the things I am aware of, excluding the things I have forgotten: - Ilias OF_PRIOR_STAGE, OF_HOSTFILE series - this series - the devicetree docs patch - devicetree bindings upstream for U-Boot (first patch under discussion) - bloblist as a means of passing devicetree, ACPI, tiny config info as C structs to U-Boot (needs to be written) - VPL so we can handle verification (patches pending) - bootflow / VBE v2 series (coming next week) Regards, Simon
On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > Hi François, > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: > > > > Hi Simon > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > >> > >> Hi Tom, Bin,François, > >> > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > >> > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > >> > > Hi Simon, > >> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote: > >> > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > >> > > > there are only three ways to obtain a devicetree: > >> > > > > >> > > > - OF_SEPARATE - the normal way, where the devicetree is built and > >> > > > appended to U-Boot > >> > > > - OF_EMBED - for development purposes, the devicetree is embedded in > >> > > > the ELF file (also used for EFI) > >> > > > - OF_BOARD - the board figures it out on its own > >> > > > > >> > > > The last one is currently set up so that no devicetree is needed at all > >> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > >> > > > don't even provide instructions on how to boot on the board. > >> > > > > >> > > > The problems with this approach are documented at [1]. > >> > > > > >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > >> > > > can obtain its devicetree at runtime, even it is has a devicetree built > >> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > >> > > > caller may have a better idea about the hardware available in the machine. > >> > > > This is the case with a few QEMU boards, for example. > >> > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > >> > > > > >> > > > This series makes this change, adding various missing devicetree files > >> > > > (and placeholders) to make the build work. > >> > > > >> > > Adding device trees that are never used sounds like a hack to me. > >> > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > >> > > command line parameters, and the device tree you put in this series > >> > > has various hardcoded <phandle> values which normally do not show up > >> > > in hand-written dts files. > >> > > > >> > > I am not sure I understand the whole point of this. > >> > > >> > I am also confused and do not like the idea of adding device trees for > >> > platforms that are capable of and can / do have a device tree to give us > >> > at run time. > >> > >> (I'll just reply to this one email, since the same points applies to > >> all replies I think) > >> > >> I have been thinking about this and discussing it with people for a > >> few months now. I've been signalling a change like this for over a > >> month now, on U-Boot contributor calls and in discussions with Linaro > >> people. I sent a patch (below) to try to explain things. I hope it is > >> not a surprise! > >> > >> The issue here is that we need a devicetree in-tree in U-Boot, to > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > >> Ilias' series and this one we can get ourselves on a stronger footing. > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > >> For more context: > >> > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > >> > >> BTW I did suggest to QEMU ARM that they support a way of adding the > >> u-boot.dtsi but there was not much interest there (in fact the > >> maintainer would prefer there was no special support even for booting > >> Linux directly!) > > > > i understand their point of view and agree with it. > >> > >> But in any case it doesn't really help U-Boot. I > >> think the path forward might be to run QEMU twice, once to get its > >> generated tree and once to give the 'merged' tree with the U-Boot > >> properties in it, if people want to use U-Boot features. > >> > >> I do strongly believe that OF_BOARD must be a run-time option, not a > >> build-time one. It creates all sorts of problems and obscurity which > >> have taken months to unpick. See the above patch for the rationale. > >> > >> To add to that rationale, OF_BOARD needs to be an option available to > >> any board. At some point in the future it may become a common way > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree > >> to it. It doesn't make any sense to have people decide whether or not > >> to set OF_BOARD at build time, thus affecting how the image is put > >> together. We'll end up with different U-Boot build targets like > >> capricorn, capricorn_of_board and the like. It should be obvious where > >> that will lead. Instead, OF_BOARD needs to become a commonly used > >> option, perhaps enabled by most/all boards, so that this sort of build > >> explosion is not needed. > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. > >> > >> U-Boot needs to be flexible enough to > >> function correctly in whatever runtime environment in which it finds > >> itself. > >> > >> Also as binman is pressed into service more and more to build the > >> complex firmware images that are becoming fashionable, it needs a > >> definition (in the devicetree) that describes how to create the image. > >> We can't support that unless we are building a devicetree, nor can the > >> running program access the image layout without that information. > >> > >> François's point about 'don't use this with any kernel' is > >> germane...but of course I am not suggesting doing that, since OF_BOARD > >> is, still, enabled. We already use OF_BOARD for various boards that > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > >> (as I said in the cover letter "Most boards do provide one, but some > >> don't."). So this series is just completing the picture by enforcing > >> that *some sort* of devicetree is always present. > > > > That seems inconsistent with the OF_BOARD becomes the default. > > I think the key point that will get you closer to where I am on this > issue, is that OF_BOARD needs to be a run-time option. At present it > has build-time effects and this is quite wrong. If you go through all > the material I have written on this I think I have motivated that very > clearly. > > Another big issue is that I believe we need ONE devicetree for U-Boot, > not two that get merged by U-Boot. Again I have gone through that in a > lot of detail. I have a long long reply to your first reply here saved, but, maybe here's the biggest sticking point. To be clear, you agree that U-Boot needs to support being passed a device tree to use, at run time, yes? And in that case, would not be using the "fake" tree we built in? So is the sticking point here that we really have two classes of devices, one class where we will never ever be given the device tree at run time (think BeagleBone Black) and one where we will always be given one at run time (think Raspberry Pi) ?
Hi Tom, On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > Hi François, > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > Hi Simon > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > > >> > > >> Hi Tom, Bin,François, > > >> > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > > >> > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > >> > > Hi Simon, > > >> > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote: > > >> > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > >> > > > there are only three ways to obtain a devicetree: > > >> > > > > > >> > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > >> > > > appended to U-Boot > > >> > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > >> > > > the ELF file (also used for EFI) > > >> > > > - OF_BOARD - the board figures it out on its own > > >> > > > > > >> > > > The last one is currently set up so that no devicetree is needed at all > > >> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > >> > > > don't even provide instructions on how to boot on the board. > > >> > > > > > >> > > > The problems with this approach are documented at [1]. > > >> > > > > > >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > >> > > > can obtain its devicetree at runtime, even it is has a devicetree built > > >> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > >> > > > caller may have a better idea about the hardware available in the machine. > > >> > > > This is the case with a few QEMU boards, for example. > > >> > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > >> > > > > > >> > > > This series makes this change, adding various missing devicetree files > > >> > > > (and placeholders) to make the build work. > > >> > > > > >> > > Adding device trees that are never used sounds like a hack to me. > > >> > > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > > >> > > command line parameters, and the device tree you put in this series > > >> > > has various hardcoded <phandle> values which normally do not show up > > >> > > in hand-written dts files. > > >> > > > > >> > > I am not sure I understand the whole point of this. > > >> > > > >> > I am also confused and do not like the idea of adding device trees for > > >> > platforms that are capable of and can / do have a device tree to give us > > >> > at run time. > > >> > > >> (I'll just reply to this one email, since the same points applies to > > >> all replies I think) > > >> > > >> I have been thinking about this and discussing it with people for a > > >> few months now. I've been signalling a change like this for over a > > >> month now, on U-Boot contributor calls and in discussions with Linaro > > >> people. I sent a patch (below) to try to explain things. I hope it is > > >> not a surprise! > > >> > > >> The issue here is that we need a devicetree in-tree in U-Boot, to > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > > >> Ilias' series and this one we can get ourselves on a stronger footing. > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > > >> For more context: > > >> > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > >> > > >> BTW I did suggest to QEMU ARM that they support a way of adding the > > >> u-boot.dtsi but there was not much interest there (in fact the > > >> maintainer would prefer there was no special support even for booting > > >> Linux directly!) > > > > > > i understand their point of view and agree with it. > > >> > > >> But in any case it doesn't really help U-Boot. I > > >> think the path forward might be to run QEMU twice, once to get its > > >> generated tree and once to give the 'merged' tree with the U-Boot > > >> properties in it, if people want to use U-Boot features. > > >> > > >> I do strongly believe that OF_BOARD must be a run-time option, not a > > >> build-time one. It creates all sorts of problems and obscurity which > > >> have taken months to unpick. See the above patch for the rationale. > > >> > > >> To add to that rationale, OF_BOARD needs to be an option available to > > >> any board. At some point in the future it may become a common way > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree > > >> to it. It doesn't make any sense to have people decide whether or not > > >> to set OF_BOARD at build time, thus affecting how the image is put > > >> together. We'll end up with different U-Boot build targets like > > >> capricorn, capricorn_of_board and the like. It should be obvious where > > >> that will lead. Instead, OF_BOARD needs to become a commonly used > > >> option, perhaps enabled by most/all boards, so that this sort of build > > >> explosion is not needed. > > > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. > > >> > > >> U-Boot needs to be flexible enough to > > >> function correctly in whatever runtime environment in which it finds > > >> itself. > > >> > > >> Also as binman is pressed into service more and more to build the > > >> complex firmware images that are becoming fashionable, it needs a > > >> definition (in the devicetree) that describes how to create the image. > > >> We can't support that unless we are building a devicetree, nor can the > > >> running program access the image layout without that information. > > >> > > >> François's point about 'don't use this with any kernel' is > > >> germane...but of course I am not suggesting doing that, since OF_BOARD > > >> is, still, enabled. We already use OF_BOARD for various boards that > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > > >> (as I said in the cover letter "Most boards do provide one, but some > > >> don't."). So this series is just completing the picture by enforcing > > >> that *some sort* of devicetree is always present. > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > I think the key point that will get you closer to where I am on this > > issue, is that OF_BOARD needs to be a run-time option. At present it > > has build-time effects and this is quite wrong. If you go through all > > the material I have written on this I think I have motivated that very > > clearly. > > > > Another big issue is that I believe we need ONE devicetree for U-Boot, > > not two that get merged by U-Boot. Again I have gone through that in a > > lot of detail. > > I have a long long reply to your first reply here saved, but, maybe > here's the biggest sticking point. To be clear, you agree that U-Boot > needs to support being passed a device tree to use, at run time, yes? Yes. The OF_BOARD feature provides this. > > And in that case, would not be using the "fake" tree we built in? Not at runtime. > > So is the sticking point here that we really have two classes of > devices, one class where we will never ever be given the device tree at > run time (think BeagleBone Black) and one where we will always be given > one at run time (think Raspberry Pi) ? I'm not sure it will be that black and white. I suspect there will be (many) boards which can boot happily with the U-Boot devicetree but can also accept one at runtime, if provided. For example, you may want to boot with or without TF-A or some other, earlier stage. I believe we have got unstuck because OF_BOARD (perhaps inadvertently) provided a way to entirely omit a devicetree from U-Boot, thus making things like binman and U-Boot /config impossible, for example. So I want to claw that back, so there is always some sort of devicetree in U-Boot, as we have for rpi_3, etc. Regards, Simon
On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > Hi François, > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > Hi Simon > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > > > >> > > > >> Hi Tom, Bin,François, > > > >> > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > > > >> > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > >> > > Hi Simon, > > > >> > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote: > > > >> > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > >> > > > there are only three ways to obtain a devicetree: > > > >> > > > > > > >> > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > >> > > > appended to U-Boot > > > >> > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > >> > > > the ELF file (also used for EFI) > > > >> > > > - OF_BOARD - the board figures it out on its own > > > >> > > > > > > >> > > > The last one is currently set up so that no devicetree is needed at all > > > >> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > >> > > > don't even provide instructions on how to boot on the board. > > > >> > > > > > > >> > > > The problems with this approach are documented at [1]. > > > >> > > > > > > >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > >> > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > >> > > > caller may have a better idea about the hardware available in the machine. > > > >> > > > This is the case with a few QEMU boards, for example. > > > >> > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > >> > > > > > > >> > > > This series makes this change, adding various missing devicetree files > > > >> > > > (and placeholders) to make the build work. > > > >> > > > > > >> > > Adding device trees that are never used sounds like a hack to me. > > > >> > > > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > > > >> > > command line parameters, and the device tree you put in this series > > > >> > > has various hardcoded <phandle> values which normally do not show up > > > >> > > in hand-written dts files. > > > >> > > > > > >> > > I am not sure I understand the whole point of this. > > > >> > > > > >> > I am also confused and do not like the idea of adding device trees for > > > >> > platforms that are capable of and can / do have a device tree to give us > > > >> > at run time. > > > >> > > > >> (I'll just reply to this one email, since the same points applies to > > > >> all replies I think) > > > >> > > > >> I have been thinking about this and discussing it with people for a > > > >> few months now. I've been signalling a change like this for over a > > > >> month now, on U-Boot contributor calls and in discussions with Linaro > > > >> people. I sent a patch (below) to try to explain things. I hope it is > > > >> not a surprise! > > > >> > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > > > >> Ilias' series and this one we can get ourselves on a stronger footing. > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > > > >> For more context: > > > >> > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > >> > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > >> maintainer would prefer there was no special support even for booting > > > >> Linux directly!) > > > > > > > > i understand their point of view and agree with it. > > > >> > > > >> But in any case it doesn't really help U-Boot. I > > > >> think the path forward might be to run QEMU twice, once to get its > > > >> generated tree and once to give the 'merged' tree with the U-Boot > > > >> properties in it, if people want to use U-Boot features. > > > >> > > > >> I do strongly believe that OF_BOARD must be a run-time option, not a > > > >> build-time one. It creates all sorts of problems and obscurity which > > > >> have taken months to unpick. See the above patch for the rationale. > > > >> > > > >> To add to that rationale, OF_BOARD needs to be an option available to > > > >> any board. At some point in the future it may become a common way > > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree > > > >> to it. It doesn't make any sense to have people decide whether or not > > > >> to set OF_BOARD at build time, thus affecting how the image is put > > > >> together. We'll end up with different U-Boot build targets like > > > >> capricorn, capricorn_of_board and the like. It should be obvious where > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used > > > >> option, perhaps enabled by most/all boards, so that this sort of build > > > >> explosion is not needed. > > > > > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. > > > >> > > > >> U-Boot needs to be flexible enough to > > > >> function correctly in whatever runtime environment in which it finds > > > >> itself. > > > >> > > > >> Also as binman is pressed into service more and more to build the > > > >> complex firmware images that are becoming fashionable, it needs a > > > >> definition (in the devicetree) that describes how to create the image. > > > >> We can't support that unless we are building a devicetree, nor can the > > > >> running program access the image layout without that information. > > > >> > > > >> François's point about 'don't use this with any kernel' is > > > >> germane...but of course I am not suggesting doing that, since OF_BOARD > > > >> is, still, enabled. We already use OF_BOARD for various boards that > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > > > >> (as I said in the cover letter "Most boards do provide one, but some > > > >> don't."). So this series is just completing the picture by enforcing > > > >> that *some sort* of devicetree is always present. > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > I think the key point that will get you closer to where I am on this > > > issue, is that OF_BOARD needs to be a run-time option. At present it > > > has build-time effects and this is quite wrong. If you go through all > > > the material I have written on this I think I have motivated that very > > > clearly. > > > > > > Another big issue is that I believe we need ONE devicetree for U-Boot, > > > not two that get merged by U-Boot. Again I have gone through that in a > > > lot of detail. > > > > I have a long long reply to your first reply here saved, but, maybe > > here's the biggest sticking point. To be clear, you agree that U-Boot > > needs to support being passed a device tree to use, at run time, yes? > > Yes. The OF_BOARD feature provides this. > > > > > And in that case, would not be using the "fake" tree we built in? > > Not at runtime. OK. > > So is the sticking point here that we really have two classes of > > devices, one class where we will never ever be given the device tree at > > run time (think BeagleBone Black) and one where we will always be given > > one at run time (think Raspberry Pi) ? > > I'm not sure it will be that black and white. I suspect there will be > (many) boards which can boot happily with the U-Boot devicetree but > can also accept one at runtime, if provided. For example, you may want > to boot with or without TF-A or some other, earlier stage. I'm not sure I see the value in making this a gray area. There's very much a class of "never" boards. There's also the class of "can" today. Maybe as part of a developer iterative flow it would be nice to not have to re-flash the prior stage to change a DT, and just do it in U-Boot until things are happy, but I'm not sure what the use case is for overriding the previous stage. Especially since the pushback on this series I think has all been "why are we copying in a tree to build with? We don't want to use it at run time!". And then softer push back like "Well, U-Boot says we have to include the device tree file here, but we won't use it...". > I believe we have got unstuck because OF_BOARD (perhaps inadvertently) > provided a way to entirely omit a devicetree from U-Boot, thus making > things like binman and U-Boot /config impossible, for example. So I > want to claw that back, so there is always some sort of devicetree in > U-Boot, as we have for rpi_3, etc. I really want to see what the binary case looks like since we could then kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could then also do a rpi_arm32_defconfig too. I want to see less device trees in U-Boot sources, if they can come functionally correct from the hardware/our caller. And I'm not seeing how we make use of "U-Boot /config" if we also don't use the device tree from build time at run time, ignoring the device tree provided to us at run time by the caller.
On Thu, 14 Oct 2021 09:17:52 -0600 Simon Glass <sjg@chromium.org> wrote: > Hi Tom, > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > Hi François, > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > Hi Simon > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > > > >> > > > >> Hi Tom, Bin,François, > > > >> > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > > > >> > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > >> > > Hi Simon, > > > >> > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote: > > > >> > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > >> > > > there are only three ways to obtain a devicetree: > > > >> > > > > > > >> > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > >> > > > appended to U-Boot > > > >> > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > >> > > > the ELF file (also used for EFI) > > > >> > > > - OF_BOARD - the board figures it out on its own > > > >> > > > > > > >> > > > The last one is currently set up so that no devicetree is needed at all > > > >> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > >> > > > don't even provide instructions on how to boot on the board. > > > >> > > > > > > >> > > > The problems with this approach are documented at [1]. > > > >> > > > > > > >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > >> > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > >> > > > caller may have a better idea about the hardware available in the machine. > > > >> > > > This is the case with a few QEMU boards, for example. > > > >> > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > >> > > > > > > >> > > > This series makes this change, adding various missing devicetree files > > > >> > > > (and placeholders) to make the build work. > > > >> > > > > > >> > > Adding device trees that are never used sounds like a hack to me. > > > >> > > > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > > > >> > > command line parameters, and the device tree you put in this series > > > >> > > has various hardcoded <phandle> values which normally do not show up > > > >> > > in hand-written dts files. > > > >> > > > > > >> > > I am not sure I understand the whole point of this. > > > >> > > > > >> > I am also confused and do not like the idea of adding device trees for > > > >> > platforms that are capable of and can / do have a device tree to give us > > > >> > at run time. > > > >> > > > >> (I'll just reply to this one email, since the same points applies to > > > >> all replies I think) > > > >> > > > >> I have been thinking about this and discussing it with people for a > > > >> few months now. I've been signalling a change like this for over a > > > >> month now, on U-Boot contributor calls and in discussions with Linaro > > > >> people. I sent a patch (below) to try to explain things. I hope it is > > > >> not a surprise! > > > >> > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > > > >> Ilias' series and this one we can get ourselves on a stronger footing. > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > > > >> For more context: > > > >> > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > >> > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > >> maintainer would prefer there was no special support even for booting > > > >> Linux directly!) > > > > > > > > i understand their point of view and agree with it. > > > >> > > > >> But in any case it doesn't really help U-Boot. I > > > >> think the path forward might be to run QEMU twice, once to get its > > > >> generated tree and once to give the 'merged' tree with the U-Boot > > > >> properties in it, if people want to use U-Boot features. > > > >> > > > >> I do strongly believe that OF_BOARD must be a run-time option, not a > > > >> build-time one. It creates all sorts of problems and obscurity which > > > >> have taken months to unpick. See the above patch for the rationale. > > > >> > > > >> To add to that rationale, OF_BOARD needs to be an option available to > > > >> any board. At some point in the future it may become a common way > > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree > > > >> to it. It doesn't make any sense to have people decide whether or not > > > >> to set OF_BOARD at build time, thus affecting how the image is put > > > >> together. We'll end up with different U-Boot build targets like > > > >> capricorn, capricorn_of_board and the like. It should be obvious where > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used > > > >> option, perhaps enabled by most/all boards, so that this sort of build > > > >> explosion is not needed. > > > > > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. > > > >> > > > >> U-Boot needs to be flexible enough to > > > >> function correctly in whatever runtime environment in which it finds > > > >> itself. > > > >> > > > >> Also as binman is pressed into service more and more to build the > > > >> complex firmware images that are becoming fashionable, it needs a > > > >> definition (in the devicetree) that describes how to create the image. > > > >> We can't support that unless we are building a devicetree, nor can the > > > >> running program access the image layout without that information. > > > >> > > > >> François's point about 'don't use this with any kernel' is > > > >> germane...but of course I am not suggesting doing that, since OF_BOARD > > > >> is, still, enabled. We already use OF_BOARD for various boards that > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > > > >> (as I said in the cover letter "Most boards do provide one, but some > > > >> don't."). So this series is just completing the picture by enforcing > > > >> that *some sort* of devicetree is always present. > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > I think the key point that will get you closer to where I am on this > > > issue, is that OF_BOARD needs to be a run-time option. At present it > > > has build-time effects and this is quite wrong. If you go through all > > > the material I have written on this I think I have motivated that very > > > clearly. > > > > > > Another big issue is that I believe we need ONE devicetree for U-Boot, > > > not two that get merged by U-Boot. Again I have gone through that in a > > > lot of detail. > > > > I have a long long reply to your first reply here saved, but, maybe > > here's the biggest sticking point. To be clear, you agree that U-Boot > > needs to support being passed a device tree to use, at run time, yes? > > Yes. The OF_BOARD feature provides this. > > > > > And in that case, would not be using the "fake" tree we built in? > > Not at runtime. > > > > > So is the sticking point here that we really have two classes of > > devices, one class where we will never ever be given the device tree at > > run time (think BeagleBone Black) and one where we will always be given > > one at run time (think Raspberry Pi) ? > > I'm not sure it will be that black and white. I suspect there will be > (many) boards which can boot happily with the U-Boot devicetree but > can also accept one at runtime, if provided. For example, you may want > to boot with or without TF-A or some other, earlier stage. I don't understand this: as Tom mentioned this is a platform decision: either it provides a DT somewhere (flash, EEPROM, prior firmware stage), or it doesn't. Sure, you can always hack your own DT in, somehow, for development or experimentation purposes, but that is a separate issue. Most of those platforms actually utilise some dynamic DTs, btw, where software amends the DT on the fly: - Highbank has a stub DT in SPI flash, and the management controller firmware detects the size and some extra DRAM (DIMMs!) parameters at boot time, and writes the /memory node accordingly. - RPi3/4 have DT overlay files on the SD card, and depending on what a user wrote in config.txt, they get applied to the DT (or not). - Even for the Allwinner H616 we amend the OF_SEPARATE provided DT copy in DRAM in TF-A, to carve out the DRAM region TF-A occupies. - QEMU is the obvious example, where the whole machine is highly dynamic, and there is no such thing as a fixed DT (how many cores?, how much memory?, how many virtio devices?, flash?, SCSI?) > I believe we have got unstuck because OF_BOARD (perhaps inadvertently) > provided a way to entirely omit a devicetree from U-Boot, thus making > things like binman and U-Boot /config impossible, for example. I have the feeling this is because we abuse DT for this. Conceptually the DT is not a configuration file, but a hardware description. I see that it is also a nice and flexible, hierarchical key/value storage, for which we have code in anyway, so it makes hardcoding data in the code easier to avoid. But as we see now, this has problems as well. So shall we separate those use cases? And attach just a tree with /binman and /config (in DTB format), but treat this separately from the hardware description? (Admittedly I have still to wrap my head around why we need /binman at U-Boot runtime in the first place.) Cheers, Andre > So I > want to claw that back, so there is always some sort of devicetree in > U-Boot, as we have for rpi_3, etc. > > Regards, > Simon
Le jeu. 14 oct. 2021 à 18:24, Andre Przywara <andre.przywara@arm.com> a écrit : > On Thu, 14 Oct 2021 09:17:52 -0600 > Simon Glass <sjg@chromium.org> wrote: > > > Hi Tom, > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > Hi François, > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > francois.ozog@linaro.org> wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a > écrit : > > > > >> > > > > >> Hi Tom, Bin,François, > > > > >> > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> > wrote: > > > > >> > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > >> > > Hi Simon, > > > > >> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> > wrote: > > > > >> > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > OF_HOSTFILE so > > > > >> > > > there are only three ways to obtain a devicetree: > > > > >> > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the devicetree is > built and > > > > >> > > > appended to U-Boot > > > > >> > > > - OF_EMBED - for development purposes, the devicetree is > embedded in > > > > >> > > > the ELF file (also used for EFI) > > > > >> > > > - OF_BOARD - the board figures it out on its own > > > > >> > > > > > > > >> > > > The last one is currently set up so that no devicetree is > needed at all > > > > >> > > > in the U-Boot tree. Most boards do provide one, but some > don't. Some > > > > >> > > > don't even provide instructions on how to boot on the board. > > > > >> > > > > > > > >> > > > The problems with this approach are documented at [1]. > > > > >> > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > OF_SEPARATE. Any board > > > > >> > > > can obtain its devicetree at runtime, even it is has a > devicetree built > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage > bootloader and its > > > > >> > > > caller may have a better idea about the hardware available > in the machine. > > > > >> > > > This is the case with a few QEMU boards, for example. > > > > >> > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It > should be an > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > >> > > > > > > > >> > > > This series makes this change, adding various missing > devicetree files > > > > >> > > > (and placeholders) to make the build work. > > > > >> > > > > > > >> > > Adding device trees that are never used sounds like a hack to > me. > > > > >> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > based on > > > > >> > > command line parameters, and the device tree you put in this > series > > > > >> > > has various hardcoded <phandle> values which normally do not > show up > > > > >> > > in hand-written dts files. > > > > >> > > > > > > >> > > I am not sure I understand the whole point of this. > > > > >> > > > > > >> > I am also confused and do not like the idea of adding device > trees for > > > > >> > platforms that are capable of and can / do have a device tree > to give us > > > > >> > at run time. > > > > >> > > > > >> (I'll just reply to this one email, since the same points applies > to > > > > >> all replies I think) > > > > >> > > > > >> I have been thinking about this and discussing it with people for > a > > > > >> few months now. I've been signalling a change like this for over a > > > > >> month now, on U-Boot contributor calls and in discussions with > Linaro > > > > >> people. I sent a patch (below) to try to explain things. I hope > it is > > > > >> not a surprise! > > > > >> > > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > > > > >> Ilias' series and this one we can get ourselves on a stronger > footing. > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > > > > >> For more context: > > > > >> > > > > >> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > >> > > > > >> BTW I did suggest to QEMU ARM that they support a way of adding > the > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > >> maintainer would prefer there was no special support even for > booting > > > > >> Linux directly!) > > > > > > > > > > i understand their point of view and agree with it. > > > > >> > > > > >> But in any case it doesn't really help U-Boot. I > > > > >> think the path forward might be to run QEMU twice, once to get its > > > > >> generated tree and once to give the 'merged' tree with the U-Boot > > > > >> properties in it, if people want to use U-Boot features. > > > > >> > > > > >> I do strongly believe that OF_BOARD must be a run-time option, > not a > > > > >> build-time one. It creates all sorts of problems and obscurity > which > > > > >> have taken months to unpick. See the above patch for the > rationale. > > > > >> > > > > >> To add to that rationale, OF_BOARD needs to be an option > available to > > > > >> any board. At some point in the future it may become a common way > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > devicetree > > > > >> to it. It doesn't make any sense to have people decide whether or > not > > > > >> to set OF_BOARD at build time, thus affecting how the image is put > > > > >> together. We'll end up with different U-Boot build targets like > > > > >> capricorn, capricorn_of_board and the like. It should be obvious > where > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used > > > > >> option, perhaps enabled by most/all boards, so that this sort of > build > > > > >> explosion is not needed. > > > > > > > > > > If you mean that when boards are by construction providing a DTB > to U-Boot then I agree very much. But I don’t understand how the patch set > supports it as it puts dts files for those boards to be built. > > > > >> > > > > >> U-Boot needs to be flexible enough to > > > > >> function correctly in whatever runtime environment in which it > finds > > > > >> itself. > > > > >> > > > > >> Also as binman is pressed into service more and more to build the > > > > >> complex firmware images that are becoming fashionable, it needs a > > > > >> definition (in the devicetree) that describes how to create the > image. > > > > >> We can't support that unless we are building a devicetree, nor > can the > > > > >> running program access the image layout without that information. > > > > >> > > > > >> François's point about 'don't use this with any kernel' is > > > > >> germane...but of course I am not suggesting doing that, since > OF_BOARD > > > > >> is, still, enabled. We already use OF_BOARD for various boards > that > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for > example > > > > >> (as I said in the cover letter "Most boards do provide one, but > some > > > > >> don't."). So this series is just completing the picture by > enforcing > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > I think the key point that will get you closer to where I am on this > > > > issue, is that OF_BOARD needs to be a run-time option. At present it > > > > has build-time effects and this is quite wrong. If you go through all > > > > the material I have written on this I think I have motivated that > very > > > > clearly. > > > > > > > > Another big issue is that I believe we need ONE devicetree for > U-Boot, > > > > not two that get merged by U-Boot. Again I have gone through that in > a > > > > lot of detail. > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > here's the biggest sticking point. To be clear, you agree that U-Boot > > > needs to support being passed a device tree to use, at run time, yes? > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > Not at runtime. > > > > > > > > So is the sticking point here that we really have two classes of > > > devices, one class where we will never ever be given the device tree at > > > run time (think BeagleBone Black) and one where we will always be given > > > one at run time (think Raspberry Pi) ? > > > > I'm not sure it will be that black and white. I suspect there will be > > (many) boards which can boot happily with the U-Boot devicetree but > > can also accept one at runtime, if provided. For example, you may want > > to boot with or without TF-A or some other, earlier stage. > > I don't understand this: as Tom mentioned this is a platform decision: > either it provides a DT somewhere (flash, EEPROM, prior firmware stage), > or it doesn't. Sure, you can always hack your own DT in, somehow, for > development or experimentation purposes, but that is a separate issue. > > Most of those platforms actually utilise some dynamic DTs, btw, where > software amends the DT on the fly: > - Highbank has a stub DT in SPI flash, and the management controller > firmware detects the size and some extra DRAM (DIMMs!) parameters at boot > time, and writes the /memory node accordingly. > - RPi3/4 have DT overlay files on the SD card, and depending on what a > user wrote in config.txt, they get applied to the DT (or not). > - Even for the Allwinner H616 we amend the OF_SEPARATE provided DT copy in > DRAM in TF-A, to carve out the DRAM region TF-A occupies. > - QEMU is the obvious example, where the whole machine is highly dynamic, > and there is no such thing as a fixed DT (how many cores?, how much > memory?, how many virtio devices?, flash?, SCSI?) > > > I believe we have got unstuck because OF_BOARD (perhaps inadvertently) > > provided a way to entirely omit a devicetree from U-Boot, thus making > > things like binman and U-Boot /config impossible, for example. > > I have the feeling this is because we abuse DT for this. Conceptually the > DT is not a configuration file, but a hardware description. +42!!! > I see that it > is also a nice and flexible, hierarchical key/value storage, for which we > have code in anyway, so it makes hardcoding data in the code easier to > avoid. > But as we see now, this has problems as well. > > So shall we separate those use cases? And attach just a tree with /binman > and /config (in DTB format), but treat this separately from the hardware > description? (Admittedly I have still to wrap my head around why we need > /binman at U-Boot runtime in the first place.) +1 > > > Cheers, > Andre > > > So I > > want to claw that back, so there is always some sort of devicetree in > > U-Boot, as we have for rpi_3, etc. > > > > Regards, > > Simon > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
Le jeu. 14 oct. 2021 à 17:28, Tom Rini <trini@konsulko.com> a écrit : > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > Hi François, > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > francois.ozog@linaro.org> wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a > écrit : > > > > >> > > > > >> Hi Tom, Bin,François, > > > > >> > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> > wrote: > > > > >> > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > >> > > Hi Simon, > > > > >> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> > wrote: > > > > >> > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > OF_HOSTFILE so > > > > >> > > > there are only three ways to obtain a devicetree: > > > > >> > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the devicetree is > built and > > > > >> > > > appended to U-Boot > > > > >> > > > - OF_EMBED - for development purposes, the devicetree is > embedded in > > > > >> > > > the ELF file (also used for EFI) > > > > >> > > > - OF_BOARD - the board figures it out on its own > > > > >> > > > > > > > >> > > > The last one is currently set up so that no devicetree is > needed at all > > > > >> > > > in the U-Boot tree. Most boards do provide one, but some > don't. Some > > > > >> > > > don't even provide instructions on how to boot on the board. > > > > >> > > > > > > > >> > > > The problems with this approach are documented at [1]. > > > > >> > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > OF_SEPARATE. Any board > > > > >> > > > can obtain its devicetree at runtime, even it is has a > devicetree built > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage > bootloader and its > > > > >> > > > caller may have a better idea about the hardware available > in the machine. > > > > >> > > > This is the case with a few QEMU boards, for example. > > > > >> > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It > should be an > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > >> > > > > > > > >> > > > This series makes this change, adding various missing > devicetree files > > > > >> > > > (and placeholders) to make the build work. > > > > >> > > > > > > >> > > Adding device trees that are never used sounds like a hack to > me. > > > > >> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > based on > > > > >> > > command line parameters, and the device tree you put in this > series > > > > >> > > has various hardcoded <phandle> values which normally do not > show up > > > > >> > > in hand-written dts files. > > > > >> > > > > > > >> > > I am not sure I understand the whole point of this. > > > > >> > > > > > >> > I am also confused and do not like the idea of adding device > trees for > > > > >> > platforms that are capable of and can / do have a device tree > to give us > > > > >> > at run time. > > > > >> > > > > >> (I'll just reply to this one email, since the same points applies > to > > > > >> all replies I think) > > > > >> > > > > >> I have been thinking about this and discussing it with people for > a > > > > >> few months now. I've been signalling a change like this for over a > > > > >> month now, on U-Boot contributor calls and in discussions with > Linaro > > > > >> people. I sent a patch (below) to try to explain things. I hope > it is > > > > >> not a surprise! > > > > >> > > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > > > > >> Ilias' series and this one we can get ourselves on a stronger > footing. > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > > > > >> For more context: > > > > >> > > > > >> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > >> > > > > >> BTW I did suggest to QEMU ARM that they support a way of adding > the > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > >> maintainer would prefer there was no special support even for > booting > > > > >> Linux directly!) > > > > > > > > > > i understand their point of view and agree with it. > > > > >> > > > > >> But in any case it doesn't really help U-Boot. I > > > > >> think the path forward might be to run QEMU twice, once to get its > > > > >> generated tree and once to give the 'merged' tree with the U-Boot > > > > >> properties in it, if people want to use U-Boot features. > > > > >> > > > > >> I do strongly believe that OF_BOARD must be a run-time option, > not a > > > > >> build-time one. It creates all sorts of problems and obscurity > which > > > > >> have taken months to unpick. See the above patch for the > rationale. > > > > >> > > > > >> To add to that rationale, OF_BOARD needs to be an option > available to > > > > >> any board. At some point in the future it may become a common way > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > devicetree > > > > >> to it. It doesn't make any sense to have people decide whether or > not > > > > >> to set OF_BOARD at build time, thus affecting how the image is put > > > > >> together. We'll end up with different U-Boot build targets like > > > > >> capricorn, capricorn_of_board and the like. It should be obvious > where > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used > > > > >> option, perhaps enabled by most/all boards, so that this sort of > build > > > > >> explosion is not needed. > > > > > > > > > > If you mean that when boards are by construction providing a DTB > to U-Boot then I agree very much. But I don’t understand how the patch set > supports it as it puts dts files for those boards to be built. > > > > >> > > > > >> U-Boot needs to be flexible enough to > > > > >> function correctly in whatever runtime environment in which it > finds > > > > >> itself. > > > > >> > > > > >> Also as binman is pressed into service more and more to build the > > > > >> complex firmware images that are becoming fashionable, it needs a > > > > >> definition (in the devicetree) that describes how to create the > image. > > > > >> We can't support that unless we are building a devicetree, nor > can the > > > > >> running program access the image layout without that information. > > > > >> > > > > >> François's point about 'don't use this with any kernel' is > > > > >> germane...but of course I am not suggesting doing that, since > OF_BOARD > > > > >> is, still, enabled. We already use OF_BOARD for various boards > that > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for > example > > > > >> (as I said in the cover letter "Most boards do provide one, but > some > > > > >> don't."). So this series is just completing the picture by > enforcing > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > I think the key point that will get you closer to where I am on this > > > > issue, is that OF_BOARD needs to be a run-time option. At present it > > > > has build-time effects and this is quite wrong. If you go through all > > > > the material I have written on this I think I have motivated that > very > > > > clearly. > > > > > > > > Another big issue is that I believe we need ONE devicetree for > U-Boot, > > > > not two that get merged by U-Boot. Again I have gone through that in > a > > > > lot of detail. > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > here's the biggest sticking point. To be clear, you agree that U-Boot > > > needs to support being passed a device tree to use, at run time, yes? > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > Not at runtime. > > OK. > > > > So is the sticking point here that we really have two classes of > > > devices, one class where we will never ever be given the device tree at > > > run time (think BeagleBone Black) and one where we will always be given > > > one at run time (think Raspberry Pi) ? > > > > I'm not sure it will be that black and white. I suspect there will be > > (many) boards which can boot happily with the U-Boot devicetree but > > can also accept one at runtime, if provided. For example, you may want > > to boot with or without TF-A or some other, earlier stage. > > I'm not sure I see the value in making this a gray area. There's very > much a class of "never" boards. There's also the class of "can" today. > Maybe as part of a developer iterative flow it would be nice to not have > to re-flash the prior stage to change a DT, and just do it in U-Boot > until things are happy, but I'm not sure what the use case is for > overriding the previous stage. > > Especially since the pushback on this series I think has all been "why > are we copying in a tree to build with? We don't want to use it at run > time!". And then softer push back like "Well, U-Boot says we have to > include the device tree file here, but we won't use it...". > > > I believe we have got unstuck because OF_BOARD (perhaps inadvertently) > > provided a way to entirely omit a devicetree from U-Boot, thus making > > things like binman and U-Boot /config impossible, for example. So I > > want to claw that back, so there is always some sort of devicetree in > > U-Boot, as we have for rpi_3, etc. > > I really want to see what the binary case looks like since we could then > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > then also do a rpi_arm32_defconfig too. > > I want to see less device trees in U-Boot sources, if they can come > functionally correct from the hardware/our caller. > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > use the device tree from build time at run time, ignoring the device > tree provided to us at run time by the caller. +1 if there is a complex build problem to solve when no DT is needed when OF_BOARD is needed i could agree to temporarily have a void.dts like /dts-v1/; / { /* required to pass build until proper makefike for OF_BOARD */ }; But not pseudo dts for boards that provide a DT to U-Boot. The pseudo dts are good for reference in the documentation part of the tree. > > -- > Tom >
Le mer. 13 oct. 2021 à 20:06, Simon Glass <sjg@chromium.org> a écrit : > Hi François, > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> > wrote: > > > > Hi Simon > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > >> > >> Hi Tom, Bin,François, > >> > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > >> > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > >> > > Hi Simon, > >> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> > wrote: > >> > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > OF_HOSTFILE so > >> > > > there are only three ways to obtain a devicetree: > >> > > > > >> > > > - OF_SEPARATE - the normal way, where the devicetree is built > and > >> > > > appended to U-Boot > >> > > > - OF_EMBED - for development purposes, the devicetree is > embedded in > >> > > > the ELF file (also used for EFI) > >> > > > - OF_BOARD - the board figures it out on its own > >> > > > > >> > > > The last one is currently set up so that no devicetree is needed > at all > >> > > > in the U-Boot tree. Most boards do provide one, but some don't. > Some > >> > > > don't even provide instructions on how to boot on the board. > >> > > > > >> > > > The problems with this approach are documented at [1]. > >> > > > > >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. > Any board > >> > > > can obtain its devicetree at runtime, even it is has a devicetree > built > >> > > > in U-Boot. This is because U-Boot may be a second-stage > bootloader and its > >> > > > caller may have a better idea about the hardware available in the > machine. > >> > > > This is the case with a few QEMU boards, for example. > >> > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be > an > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > >> > > > > >> > > > This series makes this change, adding various missing devicetree > files > >> > > > (and placeholders) to make the build work. > >> > > > >> > > Adding device trees that are never used sounds like a hack to me. > >> > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > >> > > command line parameters, and the device tree you put in this series > >> > > has various hardcoded <phandle> values which normally do not show up > >> > > in hand-written dts files. > >> > > > >> > > I am not sure I understand the whole point of this. > >> > > >> > I am also confused and do not like the idea of adding device trees for > >> > platforms that are capable of and can / do have a device tree to give > us > >> > at run time. > >> > >> (I'll just reply to this one email, since the same points applies to > >> all replies I think) > >> > >> I have been thinking about this and discussing it with people for a > >> few months now. I've been signalling a change like this for over a > >> month now, on U-Boot contributor calls and in discussions with Linaro > >> people. I sent a patch (below) to try to explain things. I hope it is > >> not a surprise! > >> > >> The issue here is that we need a devicetree in-tree in U-Boot, to > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > >> Ilias' series and this one we can get ourselves on a stronger footing. > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > >> For more context: > >> > >> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > >> > >> BTW I did suggest to QEMU ARM that they support a way of adding the > >> u-boot.dtsi but there was not much interest there (in fact the > >> maintainer would prefer there was no special support even for booting > >> Linux directly!) > > > > i understand their point of view and agree with it. > >> > >> But in any case it doesn't really help U-Boot. I > >> think the path forward might be to run QEMU twice, once to get its > >> generated tree and once to give the 'merged' tree with the U-Boot > >> properties in it, if people want to use U-Boot features. > >> > >> I do strongly believe that OF_BOARD must be a run-time option, not a > >> build-time one. It creates all sorts of problems and obscurity which > >> have taken months to unpick. See the above patch for the rationale. > >> > >> To add to that rationale, OF_BOARD needs to be an option available to > >> any board. At some point in the future it may become a common way > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree > >> to it. It doesn't make any sense to have people decide whether or not > >> to set OF_BOARD at build time, thus affecting how the image is put > >> together. We'll end up with different U-Boot build targets like > >> capricorn, capricorn_of_board and the like. It should be obvious where > >> that will lead. Instead, OF_BOARD needs to become a commonly used > >> option, perhaps enabled by most/all boards, so that this sort of build > >> explosion is not needed. > > > > If you mean that when boards are by construction providing a DTB to > U-Boot then I agree very much. But I don’t understand how the patch set > supports it as it puts dts files for those boards to be built. > >> > >> U-Boot needs to be flexible enough to > >> function correctly in whatever runtime environment in which it finds > >> itself. > >> > >> Also as binman is pressed into service more and more to build the > >> complex firmware images that are becoming fashionable, it needs a > >> definition (in the devicetree) that describes how to create the image. > >> We can't support that unless we are building a devicetree, nor can the > >> running program access the image layout without that information. > >> > >> François's point about 'don't use this with any kernel' is > >> germane...but of course I am not suggesting doing that, since OF_BOARD > >> is, still, enabled. We already use OF_BOARD for various boards that > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > >> (as I said in the cover letter "Most boards do provide one, but some > >> don't."). So this series is just completing the picture by enforcing > >> that *some sort* of devicetree is always present. > > > > That seems inconsistent with the OF_BOARD becomes the default. > > I think the key point that will get you closer to where I am on this > issue, is that OF_BOARD needs to be a run-time option. At present it > has build-time effects and this is quite wrong. Doesn’t that mean that the current build system is not fully supporting boards that do provide the DT and you try to hack your way in ? As I replied to Tom, I could accept temporarily a void.dts containing nothing to actually uallly pass any build problem until we properly fix the build system. (But no “close to real” fake dts in the dts section) > If you go through all > the material I have written on this I think I have motivated that very > clearly. > > Another big issue is that I believe we need ONE devicetree for U-Boot, > not two that get merged by U-Boot. Again I have gone through that in a > lot of detail. > i know but a number of people do not agree with your position. U-Boot can leverage many DTs coming from hats and capes to finalize the DT it passes to OS. It can also leverage a file, a FIP section (NT_FW_CONFIG in TFA) a FIT section formatted as FDT for its own configuration. > > >> > >> > >> I can't quite pinpoint the patch where U-Boot started allowing the > >> devicetree to be omitted, but if people are interested I could try a > >> little harder. It was certainly not my intention (putting on my > >> device-tree-maintainer hat) to go down that path and it slipped in > >> somehow in all the confusion. I'm not sure anyone could tell you that > >> rpi_3 has an in-tree devicetree but rpi_4 does not... > >> > >> Anyway this series is very modest. It just adds the requirement that > >> all in-tree boards have some sort of sample devicetree and preferably > >> some documentation as to where it might come from at runtime. > > > > That’s a very good goal. But adding files in dts make them not samples > but templates to be used and replace board provided DTB. > > If you push all your DTS files in documentation, you do what you say: > adding sample files. > >> > >> That > >> should not be a tough call IMO. Assuming we can get the validation in > >> place (mentioned by Rob Herring recently) it will be quite natural to > >> sync them between (presumably) Linux and U-Boot. > >> > >> I am also quite happy to discuss what should actually be in these > >> devicetree files and whether some of them should be essentially empty. > >> As you probably noticed, some of them are empty since I literally > >> could not figure out where they come from! But there needs to be at > >> least some skeleton for U-Boot to progress, since devicetree is > >> critical to its feature set. > > > > absolutely. And thank you for your efforts to make that center stage. > This is also Linaro Edge group mist challenging task on the next 6 moths. > Knowing that we have lived in a floating situation for over 10 years, I > just hope we get consensus across projects and distro providers about the > right end goal and migration strategy. > >> > > Thank you. > > >> > >> > >> It is high time we tidied all this up. I predict it will be much > >> harder, and much more confusing, in 6 months. > > Just to set a road map here in case you can help unblock anything, > here are the things I am aware of, excluding the things I have > forgotten: > > - Ilias OF_PRIOR_STAGE, OF_HOSTFILE series > - this series > - the devicetree docs patch > - devicetree bindings upstream for U-Boot (first patch under discussion) > - bloblist as a means of passing devicetree, ACPI, tiny config info as the “ABI” of U-Boot entry need more specification. Having something close to Linux helped to get U-Boot in the RPI4 and other boards I believe. So we could start from here. The blob list may be an extra arg (x0=DTB, x1=bloblist in Arm). > > C structs to U-Boot (needs to be written) > - VPL so we can handle verification (patches pending) > - bootflow / VBE v2 series (coming next week) > > Regards, > Simon >
Hi François, On Thu, 14 Oct 2021 at 12:13, François Ozog <francois.ozog@linaro.org> wrote: > > > > Le mer. 13 oct. 2021 à 20:06, Simon Glass <sjg@chromium.org> a écrit : >> >> Hi François, >> >> On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: >> > >> > Hi Simon >> > >> > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : >> >> >> >> Hi Tom, Bin,François, >> >> >> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: >> >> > >> >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: >> >> > > Hi Simon, >> >> > > >> >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote: >> >> > > > >> >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so >> >> > > > there are only three ways to obtain a devicetree: >> >> > > > >> >> > > > - OF_SEPARATE - the normal way, where the devicetree is built and >> >> > > > appended to U-Boot >> >> > > > - OF_EMBED - for development purposes, the devicetree is embedded in >> >> > > > the ELF file (also used for EFI) >> >> > > > - OF_BOARD - the board figures it out on its own >> >> > > > >> >> > > > The last one is currently set up so that no devicetree is needed at all >> >> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some >> >> > > > don't even provide instructions on how to boot on the board. >> >> > > > >> >> > > > The problems with this approach are documented at [1]. >> >> > > > >> >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board >> >> > > > can obtain its devicetree at runtime, even it is has a devicetree built >> >> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its >> >> > > > caller may have a better idea about the hardware available in the machine. >> >> > > > This is the case with a few QEMU boards, for example. >> >> > > > >> >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an >> >> > > > option, available with either OF_SEPARATE or OF_EMBED. >> >> > > > >> >> > > > This series makes this change, adding various missing devicetree files >> >> > > > (and placeholders) to make the build work. >> >> > > >> >> > > Adding device trees that are never used sounds like a hack to me. >> >> > > >> >> > > For QEMU, device tree is dynamically generated on the fly based on >> >> > > command line parameters, and the device tree you put in this series >> >> > > has various hardcoded <phandle> values which normally do not show up >> >> > > in hand-written dts files. >> >> > > >> >> > > I am not sure I understand the whole point of this. >> >> > >> >> > I am also confused and do not like the idea of adding device trees for >> >> > platforms that are capable of and can / do have a device tree to give us >> >> > at run time. >> >> >> >> (I'll just reply to this one email, since the same points applies to >> >> all replies I think) >> >> >> >> I have been thinking about this and discussing it with people for a >> >> few months now. I've been signalling a change like this for over a >> >> month now, on U-Boot contributor calls and in discussions with Linaro >> >> people. I sent a patch (below) to try to explain things. I hope it is >> >> not a surprise! >> >> >> >> The issue here is that we need a devicetree in-tree in U-Boot, to >> >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, >> >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between >> >> Ilias' series and this one we can get ourselves on a stronger footing. >> >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. >> >> For more context: >> >> >> >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ >> >> >> >> BTW I did suggest to QEMU ARM that they support a way of adding the >> >> u-boot.dtsi but there was not much interest there (in fact the >> >> maintainer would prefer there was no special support even for booting >> >> Linux directly!) >> > >> > i understand their point of view and agree with it. >> >> >> >> But in any case it doesn't really help U-Boot. I >> >> think the path forward might be to run QEMU twice, once to get its >> >> generated tree and once to give the 'merged' tree with the U-Boot >> >> properties in it, if people want to use U-Boot features. >> >> >> >> I do strongly believe that OF_BOARD must be a run-time option, not a >> >> build-time one. It creates all sorts of problems and obscurity which >> >> have taken months to unpick. See the above patch for the rationale. >> >> >> >> To add to that rationale, OF_BOARD needs to be an option available to >> >> any board. At some point in the future it may become a common way >> >> things are done, e.g. TF-A calling U-Boot and providing a devicetree >> >> to it. It doesn't make any sense to have people decide whether or not >> >> to set OF_BOARD at build time, thus affecting how the image is put >> >> together. We'll end up with different U-Boot build targets like >> >> capricorn, capricorn_of_board and the like. It should be obvious where >> >> that will lead. Instead, OF_BOARD needs to become a commonly used >> >> option, perhaps enabled by most/all boards, so that this sort of build >> >> explosion is not needed. >> > >> > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. >> >> >> >> U-Boot needs to be flexible enough to >> >> function correctly in whatever runtime environment in which it finds >> >> itself. >> >> >> >> Also as binman is pressed into service more and more to build the >> >> complex firmware images that are becoming fashionable, it needs a >> >> definition (in the devicetree) that describes how to create the image. >> >> We can't support that unless we are building a devicetree, nor can the >> >> running program access the image layout without that information. >> >> >> >> François's point about 'don't use this with any kernel' is >> >> germane...but of course I am not suggesting doing that, since OF_BOARD >> >> is, still, enabled. We already use OF_BOARD for various boards that >> >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example >> >> (as I said in the cover letter "Most boards do provide one, but some >> >> don't."). So this series is just completing the picture by enforcing >> >> that *some sort* of devicetree is always present. >> > >> > That seems inconsistent with the OF_BOARD becomes the default. >> >> I think the key point that will get you closer to where I am on this >> issue, is that OF_BOARD needs to be a run-time option. At present it >> has build-time effects and this is quite wrong. > > Doesn’t that mean that the current build system is not fully supporting boards that do provide the DT and you try to hack your way in ? As I replied to Tom, I could accept temporarily a void.dts containing nothing to actually uallly pass any build problem until we properly fix the build system. > (But no “close to real” fake dts in the dts section) Can you rephrase that paragraph, particularly the first setence? I am not sure what you are getting at. >> >> If you go through all >> the material I have written on this I think I have motivated that very >> clearly. >> >> Another big issue is that I believe we need ONE devicetree for U-Boot, >> not two that get merged by U-Boot. Again I have gone through that in a >> lot of detail. > > i know but a number of people do not agree with your position. U-Boot can leverage many DTs coming from hats and capes to finalize the DT it passes to OS. It can also leverage a file, a FIP section (NT_FW_CONFIG in TFA) a FIT section formatted as FDT for its own configuration. Perhaps it wasn't clear from the context, but I was talking about the devicetree for U-Boot, i.e. the control DTB for U-Boot. It's fine to merge overlays, etc. to pass to Linux, of course. >> >> >> >> >> >> >> >> I can't quite pinpoint the patch where U-Boot started allowing the >> >> devicetree to be omitted, but if people are interested I could try a >> >> little harder. It was certainly not my intention (putting on my >> >> device-tree-maintainer hat) to go down that path and it slipped in >> >> somehow in all the confusion. I'm not sure anyone could tell you that >> >> rpi_3 has an in-tree devicetree but rpi_4 does not... >> >> >> >> Anyway this series is very modest. It just adds the requirement that >> >> all in-tree boards have some sort of sample devicetree and preferably >> >> some documentation as to where it might come from at runtime. >> > >> > That’s a very good goal. But adding files in dts make them not samples but templates to be used and replace board provided DTB. >> > If you push all your DTS files in documentation, you do what you say: adding sample files. >> >> >> >> That >> >> should not be a tough call IMO. Assuming we can get the validation in >> >> place (mentioned by Rob Herring recently) it will be quite natural to >> >> sync them between (presumably) Linux and U-Boot. >> >> >> >> I am also quite happy to discuss what should actually be in these >> >> devicetree files and whether some of them should be essentially empty. >> >> As you probably noticed, some of them are empty since I literally >> >> could not figure out where they come from! But there needs to be at >> >> least some skeleton for U-Boot to progress, since devicetree is >> >> critical to its feature set. >> > >> > absolutely. And thank you for your efforts to make that center stage. This is also Linaro Edge group mist challenging task on the next 6 moths. Knowing that we have lived in a floating situation for over 10 years, I just hope we get consensus across projects and distro providers about the right end goal and migration strategy. >> >> >> >> Thank you. >> >> >> >> >> >> >> It is high time we tidied all this up. I predict it will be much >> >> harder, and much more confusing, in 6 months. >> >> Just to set a road map here in case you can help unblock anything, >> here are the things I am aware of, excluding the things I have >> forgotten: >> >> - Ilias OF_PRIOR_STAGE, OF_HOSTFILE series >> - this series >> - the devicetree docs patch >> - devicetree bindings upstream for U-Boot (first patch under discussion) >> - bloblist as a means of passing devicetree, ACPI, tiny config info as > > the “ABI” of U-Boot entry need more specification. Having something close to Linux helped to get U-Boot in the RPI4 and other boards I believe. So we could start from here. The blob list may be an extra arg (x0=DTB, x1=bloblist in Arm). Yes that's my intent, hopefully in a few weeks. >> >> >> C structs to U-Boot (needs to be written) >> - VPL so we can handle verification (patches pending) >> - bootflow / VBE v2 series (coming next week) Regards, Simon
Hi all, On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > Hi François, > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > > > > >> > > > > >> Hi Tom, Bin,François, > > > > >> > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > > > > >> > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > >> > > Hi Simon, > > > > >> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote: > > > > >> > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > >> > > > there are only three ways to obtain a devicetree: > > > > >> > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > >> > > > appended to U-Boot > > > > >> > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > >> > > > the ELF file (also used for EFI) > > > > >> > > > - OF_BOARD - the board figures it out on its own > > > > >> > > > > > > > >> > > > The last one is currently set up so that no devicetree is needed at all > > > > >> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > >> > > > don't even provide instructions on how to boot on the board. > > > > >> > > > > > > > >> > > > The problems with this approach are documented at [1]. > > > > >> > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > >> > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > >> > > > caller may have a better idea about the hardware available in the machine. > > > > >> > > > This is the case with a few QEMU boards, for example. > > > > >> > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > >> > > > > > > > >> > > > This series makes this change, adding various missing devicetree files > > > > >> > > > (and placeholders) to make the build work. > > > > >> > > > > > > >> > > Adding device trees that are never used sounds like a hack to me. > > > > >> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > > > > >> > > command line parameters, and the device tree you put in this series > > > > >> > > has various hardcoded <phandle> values which normally do not show up > > > > >> > > in hand-written dts files. > > > > >> > > > > > > >> > > I am not sure I understand the whole point of this. > > > > >> > > > > > >> > I am also confused and do not like the idea of adding device trees for > > > > >> > platforms that are capable of and can / do have a device tree to give us > > > > >> > at run time. > > > > >> > > > > >> (I'll just reply to this one email, since the same points applies to > > > > >> all replies I think) > > > > >> > > > > >> I have been thinking about this and discussing it with people for a > > > > >> few months now. I've been signalling a change like this for over a > > > > >> month now, on U-Boot contributor calls and in discussions with Linaro > > > > >> people. I sent a patch (below) to try to explain things. I hope it is > > > > >> not a surprise! > > > > >> > > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > > > > >> Ilias' series and this one we can get ourselves on a stronger footing. > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > > > > >> For more context: > > > > >> > > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > >> > > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > >> maintainer would prefer there was no special support even for booting > > > > >> Linux directly!) > > > > > > > > > > i understand their point of view and agree with it. > > > > >> > > > > >> But in any case it doesn't really help U-Boot. I > > > > >> think the path forward might be to run QEMU twice, once to get its > > > > >> generated tree and once to give the 'merged' tree with the U-Boot > > > > >> properties in it, if people want to use U-Boot features. > > > > >> > > > > >> I do strongly believe that OF_BOARD must be a run-time option, not a > > > > >> build-time one. It creates all sorts of problems and obscurity which > > > > >> have taken months to unpick. See the above patch for the rationale. > > > > >> > > > > >> To add to that rationale, OF_BOARD needs to be an option available to > > > > >> any board. At some point in the future it may become a common way > > > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree > > > > >> to it. It doesn't make any sense to have people decide whether or not > > > > >> to set OF_BOARD at build time, thus affecting how the image is put > > > > >> together. We'll end up with different U-Boot build targets like > > > > >> capricorn, capricorn_of_board and the like. It should be obvious where > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used > > > > >> option, perhaps enabled by most/all boards, so that this sort of build > > > > >> explosion is not needed. > > > > > > > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. > > > > >> > > > > >> U-Boot needs to be flexible enough to > > > > >> function correctly in whatever runtime environment in which it finds > > > > >> itself. > > > > >> > > > > >> Also as binman is pressed into service more and more to build the > > > > >> complex firmware images that are becoming fashionable, it needs a > > > > >> definition (in the devicetree) that describes how to create the image. > > > > >> We can't support that unless we are building a devicetree, nor can the > > > > >> running program access the image layout without that information. > > > > >> > > > > >> François's point about 'don't use this with any kernel' is > > > > >> germane...but of course I am not suggesting doing that, since OF_BOARD > > > > >> is, still, enabled. We already use OF_BOARD for various boards that > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > > > > >> (as I said in the cover letter "Most boards do provide one, but some > > > > >> don't."). So this series is just completing the picture by enforcing > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > I think the key point that will get you closer to where I am on this > > > > issue, is that OF_BOARD needs to be a run-time option. At present it > > > > has build-time effects and this is quite wrong. If you go through all > > > > the material I have written on this I think I have motivated that very > > > > clearly. > > > > > > > > Another big issue is that I believe we need ONE devicetree for U-Boot, > > > > not two that get merged by U-Boot. Again I have gone through that in a > > > > lot of detail. > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > here's the biggest sticking point. To be clear, you agree that U-Boot > > > needs to support being passed a device tree to use, at run time, yes? > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > Not at runtime. > > OK. > > > > So is the sticking point here that we really have two classes of > > > devices, one class where we will never ever be given the device tree at > > > run time (think BeagleBone Black) and one where we will always be given > > > one at run time (think Raspberry Pi) ? > > > > I'm not sure it will be that black and white. I suspect there will be > > (many) boards which can boot happily with the U-Boot devicetree but > > can also accept one at runtime, if provided. For example, you may want > > to boot with or without TF-A or some other, earlier stage. > > I'm not sure I see the value in making this a gray area. There's very > much a class of "never" boards. There's also the class of "can" today. > Maybe as part of a developer iterative flow it would be nice to not have > to re-flash the prior stage to change a DT, and just do it in U-Boot > until things are happy, but I'm not sure what the use case is for > overriding the previous stage. > > Especially since the pushback on this series I think has all been "why > are we copying in a tree to build with? We don't want to use it at run > time!". And then softer push back like "Well, U-Boot says we have to > include the device tree file here, but we won't use it...". See below. > > > I believe we have got unstuck because OF_BOARD (perhaps inadvertently) > > provided a way to entirely omit a devicetree from U-Boot, thus making > > things like binman and U-Boot /config impossible, for example. So I > > want to claw that back, so there is always some sort of devicetree in > > U-Boot, as we have for rpi_3, etc. > > I really want to see what the binary case looks like since we could then > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > then also do a rpi_arm32_defconfig too. > > I want to see less device trees in U-Boot sources, if they can come > functionally correct from the hardware/our caller. > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > use the device tree from build time at run time, ignoring the device > tree provided to us at run time by the caller. Firstly I should say that I find building firmware very messy and confusing these days. Lots of things to build and it's hard to find the instructions. It doesn't have to be that way, but if we carry on as we are, it will continue to be messy and in five years you will need a Ph.D and a lucky charm to boot on any modern board. My objective here is to simplify things, bringing some consistency to the different components. Binman was one effort there. I feel that putting at least the U-Boot house in order, in my role as devicetree maintainer (and as author of devicetree support in U-Boot back in 2011), is the next step. If we set things up correctly and agree on the bindings, devicetree can be the unifying configuration mechanism through the whole of firmware (except for very early bits) and into the OS, this will set us up very well to deal with the complexity that is coming. Anyway, here are the mental steps that I've gone through over the past two months: Step 1: At present, some people think U-Boot is not even allowed to have its own nodes/properties in the DT. It is an abuse of the devicetree standard, like the /chosen node but with less history. We should sacrifice efficiency, expedience and expandability on the altar of 'devicetree is a hardware description'. How do we get over that one? Wel, I just think we need to accept that U-Boot uses devicetree for its own purposes, as well as for booting the OS. I am not saying it always has to have those properties, but with existing features like verified boot, SPL as well as complex firmware images where U-Boot needs to be able to find things in the image, it is essential. So let's just assume that we need this everywhere, since we certainly need it in at least some places. (stop reading here if you disagree, because nothing below will make any sense...you can still use U-Boot v2011.06 which doesn't have OF_CONTROL :-) Step 2: Assume U-Boot has its own nodes/properties. How do they get there? Well, we have u-boot.dtsi files for that (the 2016 patch "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we have binman definitions, etc. So we need a way to overlay those things into the DT. We already support this for in-tree DTs, so IMO this is easy. Just require every board to have an in-tree DT. It helps with discoverability and documentation, anyway. That is this series. (I think most of us are at the beginning of step 2, unsure about it and worried about step 3) Step 3: Ah, but there are flows (i.e. boards that use a particular flow only, or boards that sometimes use a flow) which need the DT to come from a prior stage. How to handle that? IMO that is only going to grow as every man and his dog get into the write-a-bootloader business. We need a way to provide the U-Boot nodes/properties in a form that the prior stage can consume and integrate with its build system. Is TF-A the only thing being discussed here? If so, let's just do it. We have the u-boot.dtsi and we can use binman to put the image together, for example. Or we can get clever and create some sort of overlay dtb. Step 3a. But I don't want to do that. a) If U-Boot needs this stuff then it will need to build it in and use two devicetrees, one internal and one from the prior stage....well that is not very efficient and it is going to be confusing for people to figure out what U-Boot is actually doing. But we actually already do that in a lot of cases where U-Boot passes a DT to the kernel which is different to the one it uses. So perhaps we have three devicetrees? OMG. b) Well then U-Boot can have its own small devicetree with its bits and then U-Boot can merge the two when it starts. Again that is not very efficient. It means that U-Boot cannot be controlled by the prior stage (e.g. to get its public key from there or to enable/disable the console), so unified firmware config is not possible. It will get very confusing, particularly for debugging U-Boot. c) Some other scheme to avoid accepting step 3...please stop! Step 4: Yes, but there is QEMU, which makes the devicetree up out of whole cloth. What about that? Well, we are just going to have to deal with that. We can easily merge in the U-Boot nodes/properties and update the U-Boot CI scripts to do this, as needed, e.g. with qemu-riscv64_spl. It's only one use case, although Xen might do something similar. To my mind, that deals with both the build-time and run-time issues. We have a discoverable DT in U-Boot, which should be considered the source of truth for most boards. We can sync it with Linux automatically with the tooling that I hope Rob Herring will come up with. We can use an empty one where there really is no default, although I'd argue that is making perfect an enemy of the good. Step 5: If we get clever and want to remove them from the U-Boot tree and pick them up from somewhere else, we can do that with sufficient tooling. Perhaps we should set a timeline for that? A year? Two? Six? To repeat, if we set things up correctly and agree on the bindings, devicetree can be the unifying configuration mechanism through the whole of firmware (except for very early bits) and into the OS. I feel this will set us up very well to deal with the complexity that is coming. Regards, Simon
Hi Simon, A bit late to the party, sorry! [...] > > > > I really want to see what the binary case looks like since we could then > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > then also do a rpi_arm32_defconfig too. > > > > I want to see less device trees in U-Boot sources, if they can come > > functionally correct from the hardware/our caller. > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > use the device tree from build time at run time, ignoring the device > > tree provided to us at run time by the caller. > > Firstly I should say that I find building firmware very messy and > confusing these days. Lots of things to build and it's hard to find > the instructions. It doesn't have to be that way, but if we carry on > as we are, it will continue to be messy and in five years you will > need a Ph.D and a lucky charm to boot on any modern board. My > objective here is to simplify things, bringing some consistency to the > different components. Binman was one effort there. I feel that putting > at least the U-Boot house in order, in my role as devicetree > maintainer (and as author of devicetree support in U-Boot back in > 2011), is the next step. > > If we set things up correctly and agree on the bindings, devicetree > can be the unifying configuration mechanism through the whole of > firmware (except for very early bits) and into the OS, this will set > us up very well to deal with the complexity that is coming. > > Anyway, here are the mental steps that I've gone through over the past > two months: > > Step 1: At present, some people think U-Boot is not even allowed to > have its own nodes/properties in the DT. It is an abuse of the > devicetree standard, like the /chosen node but with less history. We > should sacrifice efficiency, expedience and expandability on the altar > of 'devicetree is a hardware description'. How do we get over that > one? Wel, I just think we need to accept that U-Boot uses devicetree > for its own purposes, as well as for booting the OS. I am not saying > it always has to have those properties, but with existing features > like verified boot, SPL as well as complex firmware images where > U-Boot needs to be able to find things in the image, it is essential. > So let's just assume that we need this everywhere, since we certainly > need it in at least some places. > > (stop reading here if you disagree, because nothing below will make > any sense...you can still use U-Boot v2011.06 which doesn't have > OF_CONTROL :-) Having U-Boot keep it's *internal* config state in DTs is fine. Adding that to the DTs that are copied over from linux isn't imho. There are various reasons for that. First of all syncing device trees is a huge pain and that's probably one of the main reasons our DTs are out of sync for a large number of boards. The point is this was fine in 2011 were we had SPL only, but the reality today is completely different. There's previous stage boot loaders (and enough cases were vendors prefer those over SPL). If that bootloader needs to use it's own device tree for whatever reason, imposing restrictions on it wrt to the device tree it has to include, and require them to have knowledge of U-Boot and it's internal config mechanism makes no sense not to mention it doesn't scale at all. > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > there? Well, we have u-boot.dtsi files for that (the 2016 patch > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > have binman definitions, etc. So we need a way to overlay those things > into the DT. We already support this for in-tree DTs, so IMO this is > easy. Just require every board to have an in-tree DT. It helps with > discoverability and documentation, anyway. That is this series. > Again, the board might decide for it's own reason to provide it's own DT. IMHO U-Boot must be able to cope with that and asking DTs to be included in U-Boot source is not the right way to do that, not to mention cases were that's completely unrealistic (e.g QEMU or a board that reads the DTB from it's flash). > (I think most of us are at the beginning of step 2, unsure about it > and worried about step 3) > > Step 3: Ah, but there are flows (i.e. boards that use a particular > flow only, or boards that sometimes use a flow) which need the DT to > come from a prior stage. How to handle that? IMO that is only going to > grow as every man and his dog get into the write-a-bootloader > business. And that's exactly why we have to come up with something that scales, without having to add a bunch of unusable DTs in U-Boot. > We need a way to provide the U-Boot nodes/properties in a > form that the prior stage can consume and integrate with its build > system. Is TF-A the only thing being discussed here? If so, let's just > do it. We have the u-boot.dtsi and we can use binman to put the image > together, for example. Or we can get clever and create some sort of > overlay dtb. > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > then it will need to build it in and use two devicetrees, one internal > and one from the prior stage....well that is not very efficient and it > is going to be confusing for people to figure out what U-Boot is > actually doing. But we actually already do that in a lot of cases > where U-Boot passes a DT to the kernel which is different to the one > it uses. So perhaps we have three devicetrees? OMG. No we don't. That's a moot point. If you separate the DTs U-Boot provides the internal one and inherits one 'generic'. Linux will be able to use that. So the only case were you'll need 3 DTs is if the *vendor* breaks the DT across kernel versions, In which case there's not much you can do to begin with and that's already a case we have to deal with. > b) Well then > U-Boot can have its own small devicetree with its bits and then U-Boot > can merge the two when it starts. Again that is not very efficient. It > means that U-Boot cannot be controlled by the prior stage (e.g. to get > its public key from there or to enable/disable the console), so > unified firmware config is not possible. It will get very confusing, > particularly for debugging U-Boot. c) Some other scheme to avoid > accepting step 3...please stop! > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > whole cloth. What about that? Well, we are just going to have to deal > with that. We can easily merge in the U-Boot nodes/properties and > update the U-Boot CI scripts to do this, as needed, e.g. with > qemu-riscv64_spl. It's only one use case, although Xen might do > something similar. > > To my mind, that deals with both the build-time and run-time issues. > We have a discoverable DT in U-Boot, which should be considered the > source of truth for most boards. We can sync it with Linux > automatically with the tooling that I hope Rob Herring will come up > with. We can use an empty one where there really is no default, > although I'd argue that is making perfect an enemy of the good. > > Step 5: If we get clever and want to remove them from the U-Boot tree > and pick them up from somewhere else, we can do that with sufficient > tooling. Perhaps we should set a timeline for that? A year? Two? Six? We can start slowly migrating boards and see how that works out. We could either use 2 device trees as you proposed, or have u-boot merge the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer if linux gets handed a clean device tree without the u-boot internals in it, so I think 2 discrete DTs is cleaner overall. Regards /Ilias > > To repeat, if we set things up correctly and agree on the bindings, > devicetree can be the unifying configuration mechanism through the > whole of firmware (except for very early bits) and into the OS. I feel > this will set us up very well to deal with the complexity that is > coming. > > Regards, > Simon
On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > Hi all, > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > Hi François, > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote: > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit : > > > > > >> > > > > > >> Hi Tom, Bin,François, > > > > > >> > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote: > > > > > >> > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > >> > > Hi Simon, > > > > > >> > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote: > > > > > >> > > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > >> > > > there are only three ways to obtain a devicetree: > > > > > >> > > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > > > > >> > > > appended to U-Boot > > > > > >> > > > - OF_EMBED - for development purposes, the devicetree is embedded in > > > > > >> > > > the ELF file (also used for EFI) > > > > > >> > > > - OF_BOARD - the board figures it out on its own > > > > > >> > > > > > > > > >> > > > The last one is currently set up so that no devicetree is needed at all > > > > > >> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > >> > > > don't even provide instructions on how to boot on the board. > > > > > >> > > > > > > > > >> > > > The problems with this approach are documented at [1]. > > > > > >> > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > > >> > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > > > >> > > > caller may have a better idea about the hardware available in the machine. > > > > > >> > > > This is the case with a few QEMU boards, for example. > > > > > >> > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > >> > > > > > > > > >> > > > This series makes this change, adding various missing devicetree files > > > > > >> > > > (and placeholders) to make the build work. > > > > > >> > > > > > > > >> > > Adding device trees that are never used sounds like a hack to me. > > > > > >> > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > > > > > >> > > command line parameters, and the device tree you put in this series > > > > > >> > > has various hardcoded <phandle> values which normally do not show up > > > > > >> > > in hand-written dts files. > > > > > >> > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > >> > > > > > > >> > I am also confused and do not like the idea of adding device trees for > > > > > >> > platforms that are capable of and can / do have a device tree to give us > > > > > >> > at run time. > > > > > >> > > > > > >> (I'll just reply to this one email, since the same points applies to > > > > > >> all replies I think) > > > > > >> > > > > > >> I have been thinking about this and discussing it with people for a > > > > > >> few months now. I've been signalling a change like this for over a > > > > > >> month now, on U-Boot contributor calls and in discussions with Linaro > > > > > >> people. I sent a patch (below) to try to explain things. I hope it is > > > > > >> not a surprise! > > > > > >> > > > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > > > > > >> Ilias' series and this one we can get ourselves on a stronger footing. > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > > > > > >> For more context: > > > > > >> > > > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > >> > > > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the > > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > > >> maintainer would prefer there was no special support even for booting > > > > > >> Linux directly!) > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > >> > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > >> think the path forward might be to run QEMU twice, once to get its > > > > > >> generated tree and once to give the 'merged' tree with the U-Boot > > > > > >> properties in it, if people want to use U-Boot features. > > > > > >> > > > > > >> I do strongly believe that OF_BOARD must be a run-time option, not a > > > > > >> build-time one. It creates all sorts of problems and obscurity which > > > > > >> have taken months to unpick. See the above patch for the rationale. > > > > > >> > > > > > >> To add to that rationale, OF_BOARD needs to be an option available to > > > > > >> any board. At some point in the future it may become a common way > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree > > > > > >> to it. It doesn't make any sense to have people decide whether or not > > > > > >> to set OF_BOARD at build time, thus affecting how the image is put > > > > > >> together. We'll end up with different U-Boot build targets like > > > > > >> capricorn, capricorn_of_board and the like. It should be obvious where > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used > > > > > >> option, perhaps enabled by most/all boards, so that this sort of build > > > > > >> explosion is not needed. > > > > > > > > > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. > > > > > >> > > > > > >> U-Boot needs to be flexible enough to > > > > > >> function correctly in whatever runtime environment in which it finds > > > > > >> itself. > > > > > >> > > > > > >> Also as binman is pressed into service more and more to build the > > > > > >> complex firmware images that are becoming fashionable, it needs a > > > > > >> definition (in the devicetree) that describes how to create the image. > > > > > >> We can't support that unless we are building a devicetree, nor can the > > > > > >> running program access the image layout without that information. > > > > > >> > > > > > >> François's point about 'don't use this with any kernel' is > > > > > >> germane...but of course I am not suggesting doing that, since OF_BOARD > > > > > >> is, still, enabled. We already use OF_BOARD for various boards that > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > > > > > >> (as I said in the cover letter "Most boards do provide one, but some > > > > > >> don't."). So this series is just completing the picture by enforcing > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > > > I think the key point that will get you closer to where I am on this > > > > > issue, is that OF_BOARD needs to be a run-time option. At present it > > > > > has build-time effects and this is quite wrong. If you go through all > > > > > the material I have written on this I think I have motivated that very > > > > > clearly. > > > > > > > > > > Another big issue is that I believe we need ONE devicetree for U-Boot, > > > > > not two that get merged by U-Boot. Again I have gone through that in a > > > > > lot of detail. > > > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > > here's the biggest sticking point. To be clear, you agree that U-Boot > > > > needs to support being passed a device tree to use, at run time, yes? > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > > > Not at runtime. > > > > OK. > > > > > > So is the sticking point here that we really have two classes of > > > > devices, one class where we will never ever be given the device tree at > > > > run time (think BeagleBone Black) and one where we will always be given > > > > one at run time (think Raspberry Pi) ? > > > > > > I'm not sure it will be that black and white. I suspect there will be > > > (many) boards which can boot happily with the U-Boot devicetree but > > > can also accept one at runtime, if provided. For example, you may want > > > to boot with or without TF-A or some other, earlier stage. > > > > I'm not sure I see the value in making this a gray area. There's very > > much a class of "never" boards. There's also the class of "can" today. > > Maybe as part of a developer iterative flow it would be nice to not have > > to re-flash the prior stage to change a DT, and just do it in U-Boot > > until things are happy, but I'm not sure what the use case is for > > overriding the previous stage. > > > > Especially since the pushback on this series I think has all been "why > > are we copying in a tree to build with? We don't want to use it at run > > time!". And then softer push back like "Well, U-Boot says we have to > > include the device tree file here, but we won't use it...". > > See below. > > > > > > I believe we have got unstuck because OF_BOARD (perhaps inadvertently) > > > provided a way to entirely omit a devicetree from U-Boot, thus making > > > things like binman and U-Boot /config impossible, for example. So I > > > want to claw that back, so there is always some sort of devicetree in > > > U-Boot, as we have for rpi_3, etc. > > > > I really want to see what the binary case looks like since we could then > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > then also do a rpi_arm32_defconfig too. > > > > I want to see less device trees in U-Boot sources, if they can come > > functionally correct from the hardware/our caller. > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > use the device tree from build time at run time, ignoring the device > > tree provided to us at run time by the caller. > > Firstly I should say that I find building firmware very messy and > confusing these days. Lots of things to build and it's hard to find > the instructions. It doesn't have to be that way, but if we carry on > as we are, it will continue to be messy and in five years you will > need a Ph.D and a lucky charm to boot on any modern board. My > objective here is to simplify things, bringing some consistency to the > different components. Binman was one effort there. I feel that putting > at least the U-Boot house in order, in my role as devicetree > maintainer (and as author of devicetree support in U-Boot back in > 2011), is the next step. Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts that know where to grab other known-good binaries of varying licenses that are needed to assemble something that boots. > If we set things up correctly and agree on the bindings, devicetree > can be the unifying configuration mechanism through the whole of > firmware (except for very early bits) and into the OS, this will set > us up very well to deal with the complexity that is coming. > > Anyway, here are the mental steps that I've gone through over the past > two months: > > Step 1: At present, some people think U-Boot is not even allowed to > have its own nodes/properties in the DT. It is an abuse of the > devicetree standard, like the /chosen node but with less history. We > should sacrifice efficiency, expedience and expandability on the altar > of 'devicetree is a hardware description'. How do we get over that > one? Wel, I just think we need to accept that U-Boot uses devicetree > for its own purposes, as well as for booting the OS. I am not saying Yes, we need to have properties present in the device tree, and just like how "linux," is a valid vendor prefix for the linux kernel (but not used I would expect by the BSD families) we have cases that need "u-boot," properties. > it always has to have those properties, but with existing features > like verified boot, SPL as well as complex firmware images where > U-Boot needs to be able to find things in the image, it is essential. > So let's just assume that we need this everywhere, since we certainly > need it in at least some places. No, we can't / shouldn't assume we need this everywhere. A lot of places? Yes. But some features are going to be optional. A valid must be supported use case is something like a Pi where the hardware gives us a device tree, the tree is correct and some features in U-Boot aren't needed (SPL) nor possibly supported immediately (verified boot). We can go off on a tangent about how useful it would be to have HW platforms that are both common and can demonstrate a number of features, but that's its own problem to solve. > (stop reading here if you disagree, because nothing below will make > any sense...you can still use U-Boot v2011.06 which doesn't have > OF_CONTROL :-) > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > there? Well, we have u-boot.dtsi files for that (the 2016 patch > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > have binman definitions, etc. So we need a way to overlay those things > into the DT. We already support this for in-tree DTs, so IMO this is > easy. Just require every board to have an in-tree DT. It helps with > discoverability and documentation, anyway. That is this series. > > (I think most of us are at the beginning of step 2, unsure about it > and worried about step 3) > > Step 3: Ah, but there are flows (i.e. boards that use a particular > flow only, or boards that sometimes use a flow) which need the DT to > come from a prior stage. How to handle that? IMO that is only going to > grow as every man and his dog get into the write-a-bootloader > business. We need a way to provide the U-Boot nodes/properties in a > form that the prior stage can consume and integrate with its build > system. Is TF-A the only thing being discussed here? If so, let's just > do it. We have the u-boot.dtsi and we can use binman to put the image > together, for example. Or we can get clever and create some sort of > overlay dtb. > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > then it will need to build it in and use two devicetrees, one internal > and one from the prior stage....well that is not very efficient and it > is going to be confusing for people to figure out what U-Boot is > actually doing. But we actually already do that in a lot of cases > where U-Boot passes a DT to the kernel which is different to the one > it uses. So perhaps we have three devicetrees? OMG. b) Well then > U-Boot can have its own small devicetree with its bits and then U-Boot > can merge the two when it starts. Again that is not very efficient. It > means that U-Boot cannot be controlled by the prior stage (e.g. to get > its public key from there or to enable/disable the console), so > unified firmware config is not possible. It will get very confusing, > particularly for debugging U-Boot. c) Some other scheme to avoid > accepting step 3...please stop! How the nodes should get there is how the rest of the nodes in a system get there. Bindings are submitted and reviewed. The authoritative source of the dtses in question then has them, like any other property. > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > whole cloth. What about that? Well, we are just going to have to deal > with that. We can easily merge in the U-Boot nodes/properties and > update the U-Boot CI scripts to do this, as needed, e.g. with > qemu-riscv64_spl. It's only one use case, although Xen might do > something similar. > > To my mind, that deals with both the build-time and run-time issues. > We have a discoverable DT in U-Boot, which should be considered the > source of truth for most boards. We can sync it with Linux > automatically with the tooling that I hope Rob Herring will come up > with. We can use an empty one where there really is no default, > although I'd argue that is making perfect an enemy of the good. > > Step 5: If we get clever and want to remove them from the U-Boot tree > and pick them up from somewhere else, we can do that with sufficient > tooling. Perhaps we should set a timeline for that? A year? Two? Six? These last two paragraphs condense what I think is honestly close to a decade of debate / discussion down to a fiat "U-Boot will have the DTS files". I don't want that. I don't think any of the other projects that want to leverage DTS files want that. > To repeat, if we set things up correctly and agree on the bindings, > devicetree can be the unifying configuration mechanism through the > whole of firmware (except for very early bits) and into the OS. I feel > this will set us up very well to deal with the complexity that is > coming. Sure, it could. But that doesn't mean that U-Boot is where the dts files live.
On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > Hi Simon, > > A bit late to the party, sorry! > > [...] > > > > > > > I really want to see what the binary case looks like since we could then > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > then also do a rpi_arm32_defconfig too. > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > functionally correct from the hardware/our caller. > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > use the device tree from build time at run time, ignoring the device > > > tree provided to us at run time by the caller. > > > > Firstly I should say that I find building firmware very messy and > > confusing these days. Lots of things to build and it's hard to find > > the instructions. It doesn't have to be that way, but if we carry on > > as we are, it will continue to be messy and in five years you will > > need a Ph.D and a lucky charm to boot on any modern board. My > > objective here is to simplify things, bringing some consistency to the > > different components. Binman was one effort there. I feel that putting > > at least the U-Boot house in order, in my role as devicetree > > maintainer (and as author of devicetree support in U-Boot back in > > 2011), is the next step. > > > > If we set things up correctly and agree on the bindings, devicetree > > can be the unifying configuration mechanism through the whole of > > firmware (except for very early bits) and into the OS, this will set > > us up very well to deal with the complexity that is coming. > > > > Anyway, here are the mental steps that I've gone through over the past > > two months: > > > > Step 1: At present, some people think U-Boot is not even allowed to > > have its own nodes/properties in the DT. It is an abuse of the > > devicetree standard, like the /chosen node but with less history. We > > should sacrifice efficiency, expedience and expandability on the altar > > of 'devicetree is a hardware description'. How do we get over that > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > for its own purposes, as well as for booting the OS. I am not saying > > it always has to have those properties, but with existing features > > like verified boot, SPL as well as complex firmware images where > > U-Boot needs to be able to find things in the image, it is essential. > > So let's just assume that we need this everywhere, since we certainly > > need it in at least some places. > > > > (stop reading here if you disagree, because nothing below will make > > any sense...you can still use U-Boot v2011.06 which doesn't have > > OF_CONTROL :-) > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > that to the DTs that are copied over from linux isn't imho. There are > various reasons for that. First of all syncing device trees is a huge pain > and that's probably one of the main reasons our DTs are out of sync for a > large number of boards. This re-sync is only a pain because: 1. Some platforms have been modifying the core dts files LIKE THEY ARE NOT SUPPOSED TO. 2. DTS files are getting closer to being the super stable API that has been promised now that there's validation tools. Some SoCs, like stm32 are doing an amazing job and keeping things in sync, every release. Others like NXP are violating rule #1. Still others like some TI platforms get bit by #2 (I solved one of these, and need to cycle back to the one you and I talked about on IRC a while back, I bet it's another node name dash changed to underbar). > The point is this was fine in 2011 were we had SPL only, but the reality > today is completely different. There's previous stage boot loaders (and > enough cases were vendors prefer those over SPL). If that bootloader needs > to use it's own device tree for whatever reason, imposing restrictions on > it wrt to the device tree it has to include, and require them to have > knowledge of U-Boot and it's internal config mechanism makes no sense not > to mention it doesn't scale at all. If you are passing the full device tree around, a few more nodes/properties aren't going to make the situation worse. If we're talking about a 60 kilobyte blob one more kilobyte isn't where we call the line, especially since if we wait another 6 months it'll be a 62 kilobyte file coming in from Linux instead. > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > have binman definitions, etc. So we need a way to overlay those things > > into the DT. We already support this for in-tree DTs, so IMO this is > > easy. Just require every board to have an in-tree DT. It helps with > > discoverability and documentation, anyway. That is this series. > > Again, the board might decide for it's own reason to provide it's own DT. > IMHO U-Boot must be able to cope with that and asking DTs to be included in > U-Boot source is not the right way to do that, not to mention cases were > that's completely unrealistic (e.g QEMU or a board that reads the DTB from > it's flash). > > > (I think most of us are at the beginning of step 2, unsure about it > > and worried about step 3) > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > flow only, or boards that sometimes use a flow) which need the DT to > > come from a prior stage. How to handle that? IMO that is only going to > > grow as every man and his dog get into the write-a-bootloader > > business. > > And that's exactly why we have to come up with something that scales, without > having to add a bunch of unusable DTs in U-Boot. Both of these are solved by having our bindings reviewed and upstreamed and then what we need included in the authoritative dts files. > > We need a way to provide the U-Boot nodes/properties in a > > form that the prior stage can consume and integrate with its build > > system. Is TF-A the only thing being discussed here? If so, let's just > > do it. We have the u-boot.dtsi and we can use binman to put the image > > together, for example. Or we can get clever and create some sort of > > overlay dtb. > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > then it will need to build it in and use two devicetrees, one internal > > and one from the prior stage....well that is not very efficient and it > > is going to be confusing for people to figure out what U-Boot is > > actually doing. But we actually already do that in a lot of cases > > where U-Boot passes a DT to the kernel which is different to the one > > it uses. So perhaps we have three devicetrees? OMG. > > No we don't. That's a moot point. If you separate the DTs U-Boot > provides the internal one and inherits one 'generic'. Linux will be able to use > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the > DT across kernel versions, In which case there's not much you can do to > begin with and that's already a case we have to deal with. > > > b) Well then > > U-Boot can have its own small devicetree with its bits and then U-Boot > > can merge the two when it starts. Again that is not very efficient. It > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > its public key from there or to enable/disable the console), so > > unified firmware config is not possible. It will get very confusing, > > particularly for debugging U-Boot. c) Some other scheme to avoid > > accepting step 3...please stop! > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > whole cloth. What about that? Well, we are just going to have to deal > > with that. We can easily merge in the U-Boot nodes/properties and > > update the U-Boot CI scripts to do this, as needed, e.g. with > > qemu-riscv64_spl. It's only one use case, although Xen might do > > something similar. > > > > To my mind, that deals with both the build-time and run-time issues. > > We have a discoverable DT in U-Boot, which should be considered the > > source of truth for most boards. We can sync it with Linux > > automatically with the tooling that I hope Rob Herring will come up > > with. We can use an empty one where there really is no default, > > although I'd argue that is making perfect an enemy of the good. > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > and pick them up from somewhere else, we can do that with sufficient > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > We can start slowly migrating boards and see how that works out. > We could either use 2 device trees as you proposed, or have u-boot merge > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer > if linux gets handed a clean device tree without the u-boot internals in > it, so I think 2 discrete DTs is cleaner overall. Why does it matter if Linux sees some u-boot, properties? If some huge stink is going to be thrown, we could probably prune them out at run time but it's already being passed N disabled nodes, yes?
Hi, On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > Hi all, > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > Hi François, > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> > a écrit : > > > > > > >> > > > > > > >> Hi Tom, Bin,François, > > > > > > >> > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> > wrote: > > > > > > >> > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > > >> > > Hi Simon, > > > > > > >> > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > sjg@chromium.org> wrote: > > > > > > >> > > > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > OF_HOSTFILE so > > > > > > >> > > > there are only three ways to obtain a devicetree: > > > > > > >> > > > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the devicetree > is built and > > > > > > >> > > > appended to U-Boot > > > > > > >> > > > - OF_EMBED - for development purposes, the > devicetree is embedded in > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > >> > > > - OF_BOARD - the board figures it out on its own > > > > > > >> > > > > > > > > > >> > > > The last one is currently set up so that no devicetree > is needed at all > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, but > some don't. Some > > > > > > >> > > > don't even provide instructions on how to boot on the > board. > > > > > > >> > > > > > > > > > >> > > > The problems with this approach are documented at [1]. > > > > > > >> > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > OF_SEPARATE. Any board > > > > > > >> > > > can obtain its devicetree at runtime, even it is has a > devicetree built > > > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage > bootloader and its > > > > > > >> > > > caller may have a better idea about the hardware > available in the machine. > > > > > > >> > > > This is the case with a few QEMU boards, for example. > > > > > > >> > > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It > should be an > > > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > >> > > > > > > > > > >> > > > This series makes this change, adding various missing > devicetree files > > > > > > >> > > > (and placeholders) to make the build work. > > > > > > >> > > > > > > > > >> > > Adding device trees that are never used sounds like a > hack to me. > > > > > > >> > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > based on > > > > > > >> > > command line parameters, and the device tree you put in > this series > > > > > > >> > > has various hardcoded <phandle> values which normally do > not show up > > > > > > >> > > in hand-written dts files. > > > > > > >> > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > >> > > > > > > > >> > I am also confused and do not like the idea of adding > device trees for > > > > > > >> > platforms that are capable of and can / do have a device > tree to give us > > > > > > >> > at run time. > > > > > > >> > > > > > > >> (I'll just reply to this one email, since the same points > applies to > > > > > > >> all replies I think) > > > > > > >> > > > > > > >> I have been thinking about this and discussing it with people > for a > > > > > > >> few months now. I've been signalling a change like this for > over a > > > > > > >> month now, on U-Boot contributor calls and in discussions > with Linaro > > > > > > >> people. I sent a patch (below) to try to explain things. I > hope it is > > > > > > >> not a surprise! > > > > > > >> > > > > > > >> The issue here is that we need a devicetree in-tree in > U-Boot, to > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, > OF_BOARD, > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. > Between > > > > > > >> Ilias' series and this one we can get ourselves on a stronger > footing. > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF > use. > > > > > > >> For more context: > > > > > > >> > > > > > > >> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > >> > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of > adding the > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > > > >> maintainer would prefer there was no special support even for > booting > > > > > > >> Linux directly!) > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > >> > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > >> think the path forward might be to run QEMU twice, once to > get its > > > > > > >> generated tree and once to give the 'merged' tree with the > U-Boot > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > >> > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > option, not a > > > > > > >> build-time one. It creates all sorts of problems and > obscurity which > > > > > > >> have taken months to unpick. See the above patch for the > rationale. > > > > > > >> > > > > > > >> To add to that rationale, OF_BOARD needs to be an option > available to > > > > > > >> any board. At some point in the future it may become a common > way > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > devicetree > > > > > > >> to it. It doesn't make any sense to have people decide > whether or not > > > > > > >> to set OF_BOARD at build time, thus affecting how the image > is put > > > > > > >> together. We'll end up with different U-Boot build targets > like > > > > > > >> capricorn, capricorn_of_board and the like. It should be > obvious where > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly > used > > > > > > >> option, perhaps enabled by most/all boards, so that this sort > of build > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > If you mean that when boards are by construction providing a > DTB to U-Boot then I agree very much. But I don’t understand how the patch > set supports it as it puts dts files for those boards to be built. > > > > > > >> > > > > > > >> U-Boot needs to be flexible enough to > > > > > > >> function correctly in whatever runtime environment in which > it finds > > > > > > >> itself. > > > > > > >> > > > > > > >> Also as binman is pressed into service more and more to build > the > > > > > > >> complex firmware images that are becoming fashionable, it > needs a > > > > > > >> definition (in the devicetree) that describes how to create > the image. > > > > > > >> We can't support that unless we are building a devicetree, > nor can the > > > > > > >> running program access the image layout without that > information. > > > > > > >> > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > >> germane...but of course I am not suggesting doing that, since > OF_BOARD > > > > > > >> is, still, enabled. We already use OF_BOARD for various > boards that > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for > example > > > > > > >> (as I said in the cover letter "Most boards do provide one, > but some > > > > > > >> don't."). So this series is just completing the picture by > enforcing > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > > > > > I think the key point that will get you closer to where I am on > this > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > present it > > > > > > has build-time effects and this is quite wrong. If you go > through all > > > > > > the material I have written on this I think I have motivated > that very > > > > > > clearly. > > > > > > > > > > > > Another big issue is that I believe we need ONE devicetree for > U-Boot, > > > > > > not two that get merged by U-Boot. Again I have gone through > that in a > > > > > > lot of detail. > > > > > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > > > here's the biggest sticking point. To be clear, you agree that > U-Boot > > > > > needs to support being passed a device tree to use, at run time, > yes? > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > > > > > Not at runtime. > > > > > > OK. > > > > > > > > So is the sticking point here that we really have two classes of > > > > > devices, one class where we will never ever be given the device > tree at > > > > > run time (think BeagleBone Black) and one where we will always be > given > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > I'm not sure it will be that black and white. I suspect there will be > > > > (many) boards which can boot happily with the U-Boot devicetree but > > > > can also accept one at runtime, if provided. For example, you may > want > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > I'm not sure I see the value in making this a gray area. There's very > > > much a class of "never" boards. There's also the class of "can" today. > > > Maybe as part of a developer iterative flow it would be nice to not > have > > > to re-flash the prior stage to change a DT, and just do it in U-Boot > > > until things are happy, but I'm not sure what the use case is for > > > overriding the previous stage. > > > > > > Especially since the pushback on this series I think has all been "why > > > are we copying in a tree to build with? We don't want to use it at run > > > time!". And then softer push back like "Well, U-Boot says we have to > > > include the device tree file here, but we won't use it...". > > > > See below. > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > inadvertently) > > > > provided a way to entirely omit a devicetree from U-Boot, thus making > > > > things like binman and U-Boot /config impossible, for example. So I > > > > want to claw that back, so there is always some sort of devicetree in > > > > U-Boot, as we have for rpi_3, etc. > > > > > > I really want to see what the binary case looks like since we could > then > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > then also do a rpi_arm32_defconfig too. > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > functionally correct from the hardware/our caller. > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > use the device tree from build time at run time, ignoring the device > > > tree provided to us at run time by the caller. > > > > Firstly I should say that I find building firmware very messy and > > confusing these days. Lots of things to build and it's hard to find > > the instructions. It doesn't have to be that way, but if we carry on > > as we are, it will continue to be messy and in five years you will > > need a Ph.D and a lucky charm to boot on any modern board. My > > objective here is to simplify things, bringing some consistency to the > > different components. Binman was one effort there. I feel that putting > > at least the U-Boot house in order, in my role as devicetree > > maintainer (and as author of devicetree support in U-Boot back in > > 2011), is the next step. > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > that know where to grab other known-good binaries of varying licenses > that are needed to assemble something that boots. > > > If we set things up correctly and agree on the bindings, devicetree > > can be the unifying configuration mechanism through the whole of > > firmware (except for very early bits) and into the OS, this will set > > us up very well to deal with the complexity that is coming. > > > > Anyway, here are the mental steps that I've gone through over the past > > two months: > > > > Step 1: At present, some people think U-Boot is not even allowed to > > have its own nodes/properties in the DT. In my view U-Boot shall be able to leverage device tree format (source and binary) to store its own data. When you say "the" DT, I always think this is "the" DT that is passed to OS and in "that" DT, there should be no U-Boot entries. As stated in another mail thread, I also refer to a place in a FIP where that dynamic config DT is meant to be stored: NT_FW_CONFIG. But there can be U-Boot defined bindings in "a" control/dynamic config DT; Trusted Firmware does that. > It is an abuse of the > > devicetree standard, like the /chosen node but with less history. We > > should sacrifice efficiency, expedience and expandability on the altar > > of 'devicetree is a hardware description'. How do we get over that > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > for its own purposes, as well as for booting the OS. I am not saying > > Yes, we need to have properties present in the device tree, and just > like how "linux," is a valid vendor prefix for the linux kernel (but not > used I would expect by the BSD families) we have cases that need > "u-boot," properties. > > > it always has to have those properties, but with existing features > > like verified boot, SPL as well as complex firmware images where > > U-Boot needs to be able to find things in the image, it is essential. > > So let's just assume that we need this everywhere, since we certainly > > need it in at least some places. > > No, we can't / shouldn't assume we need this everywhere. A lot of > places? Yes. But some features are going to be optional. A valid must > be supported use case is something like a Pi where the hardware gives us > a device tree, the tree is correct and some features in U-Boot aren't > needed (SPL) nor possibly supported immediately (verified boot). We can > go off on a tangent about how useful it would be to have HW platforms > that are both common and can demonstrate a number of features, but > that's its own problem to solve. > > > (stop reading here if you disagree, because nothing below will make > > any sense...you can still use U-Boot v2011.06 which doesn't have > > OF_CONTROL :-) > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > have binman definitions, etc. So we need a way to overlay those things > > into the DT. We already support this for in-tree DTs, so IMO this is > > easy. Just require every board to have an in-tree DT. It helps with > > discoverability and documentation, anyway. That is this series. > > > > (I think most of us are at the beginning of step 2, unsure about it > > and worried about step 3) > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > flow only, or boards that sometimes use a flow) which need the DT to > > come from a prior stage. How to handle that? IMO that is only going to > > grow as every man and his dog get into the write-a-bootloader > > business. We need a way to provide the U-Boot nodes/properties in a > > form that the prior stage can consume and integrate with its build > > system. Is TF-A the only thing being discussed here? If so, let's just > > do it. We have the u-boot.dtsi and we can use binman to put the image > > together, for example. Or we can get clever and create some sort of > > overlay dtb. > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > then it will need to build it in and use two devicetrees, one internal > > and one from the prior stage....well that is not very efficient and it > > is going to be confusing for people to figure out what U-Boot is > > actually doing. But we actually already do that in a lot of cases > > where U-Boot passes a DT to the kernel which is different to the one > > it uses. So perhaps we have three devicetrees? OMG. b) Well then > > U-Boot can have its own small devicetree with its bits and then U-Boot > > can merge the two when it starts. Again that is not very efficient. Does not need to merge the two. hence it does not have any influence on efficiency. For properties access, trusted firmware has defined an abstract way to get them: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html . The properties are currently implemented as DT but TF.ORG could decide to move to CBOR. The API will remain so that a change in backend will not influence existing code. I think you are too focused on "THE" device tree. "THE" device tree that is passed to the OS shall be hardware description and not a hacky place to fit any piece of metadata. I would argue that /chosen shall not even be there as most if not all information can be passed as OS command line. And actually for the UEFI contract, /chosen should go empty. > It > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > its public key from there or to enable/disable the console), so > > unified firmware config is not possible. It will get very confusing, > > particularly for debugging U-Boot. c) Some other scheme to avoid > > accepting step 3...please stop! > > How the nodes should get there is how the rest of the nodes in a system > get there. Bindings are submitted and reviewed. The authoritative > source of the dtses in question then has them, like any other property. > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > whole cloth. What about that? Well, we are just going to have to deal > > with that. We can easily merge in the U-Boot nodes/properties and > > update the U-Boot CI scripts to do this, as needed, e.g. with > > qemu-riscv64_spl. It's only one use case, although Xen might do > > something similar. > > > > To my mind, that deals with both the build-time and run-time issues. > > We have a discoverable DT in U-Boot, which should be considered the > > source of truth for most boards. We can sync it with Linux > > automatically with the tooling that I hope Rob Herring will come up > > with. We can use an empty one where there really is no default, > > although I'd argue that is making perfect an enemy of the good. > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > and pick them up from somewhere else, we can do that with sufficient > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > For SystemReady compliant boards, this has to come much faster. Do you think distros will keep providing DTs for ever? I bet not. > These last two paragraphs condense what I think is honestly close to a > decade of debate / discussion down to a fiat "U-Boot will have the DTS > files". I don't want that. I don't think any of the other projects > that want to leverage DTS files want that. > > > To repeat, if we set things up correctly and agree on the bindings, > > devicetree can be the unifying configuration mechanism through the > > whole of firmware (except for very early bits) and into the OS. I feel > > this will set us up very well to deal with the complexity that is > > coming. > > Sure, it could. But that doesn't mean that U-Boot is where the dts > files live. > > -- > Tom >
On 10/27/21 15:15, François Ozog wrote: > Hi, > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com > <mailto:trini@konsulko.com>> wrote: > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > Hi all, > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com > <mailto:trini@konsulko.com>> wrote: > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com > <mailto:trini@konsulko.com>> wrote: > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > Hi François, > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog > <francois.ozog@linaro.org <mailto:francois.ozog@linaro.org>> wrote: > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass > <sjg@chromium.org <mailto:sjg@chromium.org>> a écrit : > > > > > > >> > > > > > > >> Hi Tom, Bin,François, > > > > > > >> > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini > <trini@konsulko.com <mailto:trini@konsulko.com>> wrote: > > > > > > >> > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > wrote: > > > > > > >> > > Hi Simon, > > > > > > >> > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass > <sjg@chromium.org <mailto:sjg@chromium.org>> wrote: > > > > > > >> > > > > > > > > > >> > > > With Ilias' efforts we have dropped > OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > > >> > > > there are only three ways to obtain a devicetree: > > > > > > >> > > > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the > devicetree is built and > > > > > > >> > > > appended to U-Boot > > > > > > >> > > > - OF_EMBED - for development purposes, the > devicetree is embedded in > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > >> > > > - OF_BOARD - the board figures it out on its own > > > > > > >> > > > > > > > > > >> > > > The last one is currently set up so that no > devicetree is needed at all > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, > but some don't. Some > > > > > > >> > > > don't even provide instructions on how to boot > on the board. > > > > > > >> > > > > > > > > > >> > > > The problems with this approach are documented > at [1]. > > > > > > >> > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct > from OF_SEPARATE. Any board > > > > > > >> > > > can obtain its devicetree at runtime, even it is > has a devicetree built > > > > > > >> > > > in U-Boot. This is because U-Boot may be a > second-stage bootloader and its > > > > > > >> > > > caller may have a better idea about the hardware > available in the machine. > > > > > > >> > > > This is the case with a few QEMU boards, for > example. > > > > > > >> > > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a > 'choice'. It should be an > > > > > > >> > > > option, available with either OF_SEPARATE or > OF_EMBED. > > > > > > >> > > > > > > > > > >> > > > This series makes this change, adding various > missing devicetree files > > > > > > >> > > > (and placeholders) to make the build work. > > > > > > >> > > > > > > > > >> > > Adding device trees that are never used sounds > like a hack to me. > > > > > > >> > > > > > > > > >> > > For QEMU, device tree is dynamically generated on > the fly based on > > > > > > >> > > command line parameters, and the device tree you > put in this series > > > > > > >> > > has various hardcoded <phandle> values which > normally do not show up > > > > > > >> > > in hand-written dts files. > > > > > > >> > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > >> > > > > > > > >> > I am also confused and do not like the idea of > adding device trees for > > > > > > >> > platforms that are capable of and can / do have a > device tree to give us > > > > > > >> > at run time. > > > > > > >> > > > > > > >> (I'll just reply to this one email, since the same > points applies to > > > > > > >> all replies I think) > > > > > > >> > > > > > > >> I have been thinking about this and discussing it with > people for a > > > > > > >> few months now. I've been signalling a change like > this for over a > > > > > > >> month now, on U-Boot contributor calls and in > discussions with Linaro > > > > > > >> people. I sent a patch (below) to try to explain > things. I hope it is > > > > > > >> not a surprise! > > > > > > >> > > > > > > >> The issue here is that we need a devicetree in-tree in > U-Boot, to > > > > > > >> avoid the mess that has been created by > OF_PRIOR_STAGE, OF_BOARD, > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, > OF_HOSTFILE. Between > > > > > > >> Ilias' series and this one we can get ourselves on a > stronger footing. > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for > debugging/ELF use. > > > > > > >> For more context: > > > > > > >> > > > > > > >> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > <http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/> > > > > > > >> > > > > > > >> BTW I did suggest to QEMU ARM that they support a way > of adding the > > > > > > >> u-boot.dtsi but there was not much interest there (in > fact the > > > > > > >> maintainer would prefer there was no special support > even for booting > > > > > > >> Linux directly!) > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > >> > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > >> think the path forward might be to run QEMU twice, > once to get its > > > > > > >> generated tree and once to give the 'merged' tree with > the U-Boot > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > >> > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > option, not a > > > > > > >> build-time one. It creates all sorts of problems and > obscurity which > > > > > > >> have taken months to unpick. See the above patch for > the rationale. > > > > > > >> > > > > > > >> To add to that rationale, OF_BOARD needs to be an > option available to > > > > > > >> any board. At some point in the future it may become a > common way > > > > > > >> things are done, e.g. TF-A calling U-Boot and > providing a devicetree > > > > > > >> to it. It doesn't make any sense to have people decide > whether or not > > > > > > >> to set OF_BOARD at build time, thus affecting how the > image is put > > > > > > >> together. We'll end up with different U-Boot build > targets like > > > > > > >> capricorn, capricorn_of_board and the like. It should > be obvious where > > > > > > >> that will lead. Instead, OF_BOARD needs to become a > commonly used > > > > > > >> option, perhaps enabled by most/all boards, so that > this sort of build > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > If you mean that when boards are by construction > providing a DTB to U-Boot then I agree very much. But I don’t > understand how the patch set supports it as it puts dts files for > those boards to be built. > > > > > > >> > > > > > > >> U-Boot needs to be flexible enough to > > > > > > >> function correctly in whatever runtime environment in > which it finds > > > > > > >> itself. > > > > > > >> > > > > > > >> Also as binman is pressed into service more and more > to build the > > > > > > >> complex firmware images that are becoming fashionable, > it needs a > > > > > > >> definition (in the devicetree) that describes how to > create the image. > > > > > > >> We can't support that unless we are building a > devicetree, nor can the > > > > > > >> running program access the image layout without that > information. > > > > > > >> > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > >> germane...but of course I am not suggesting doing > that, since OF_BOARD > > > > > > >> is, still, enabled. We already use OF_BOARD for > various boards that > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and > 3, for example > > > > > > >> (as I said in the cover letter "Most boards do provide > one, but some > > > > > > >> don't."). So this series is just completing the > picture by enforcing > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the > default. > > > > > > > > > > > > I think the key point that will get you closer to where I > am on this > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > present it > > > > > > has build-time effects and this is quite wrong. If you go > through all > > > > > > the material I have written on this I think I have > motivated that very > > > > > > clearly. > > > > > > > > > > > > Another big issue is that I believe we need ONE > devicetree for U-Boot, > > > > > > not two that get merged by U-Boot. Again I have gone > through that in a > > > > > > lot of detail. > > > > > > > > > > I have a long long reply to your first reply here saved, > but, maybe > > > > > here's the biggest sticking point. To be clear, you agree > that U-Boot > > > > > needs to support being passed a device tree to use, at run > time, yes? > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we > built in? > > > > > > > > Not at runtime. > > > > > > OK. > > > > > > > > So is the sticking point here that we really have two > classes of > > > > > devices, one class where we will never ever be given the > device tree at > > > > > run time (think BeagleBone Black) and one where we will > always be given > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > I'm not sure it will be that black and white. I suspect there > will be > > > > (many) boards which can boot happily with the U-Boot > devicetree but > > > > can also accept one at runtime, if provided. For example, you > may want > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > I'm not sure I see the value in making this a gray area. > There's very > > > much a class of "never" boards. There's also the class of > "can" today. > > > Maybe as part of a developer iterative flow it would be nice to > not have > > > to re-flash the prior stage to change a DT, and just do it in > U-Boot > > > until things are happy, but I'm not sure what the use case is for > > > overriding the previous stage. > > > > > > Especially since the pushback on this series I think has all > been "why > > > are we copying in a tree to build with? We don't want to use > it at run > > > time!". And then softer push back like "Well, U-Boot says we > have to > > > include the device tree file here, but we won't use it...". > > > > See below. > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > inadvertently) > > > > provided a way to entirely omit a devicetree from U-Boot, > thus making > > > > things like binman and U-Boot /config impossible, for > example. So I > > > > want to claw that back, so there is always some sort of > devicetree in > > > > U-Boot, as we have for rpi_3, etc. > > > > > > I really want to see what the binary case looks like since we > could then > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > could > > > then also do a rpi_arm32_defconfig too. > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > functionally correct from the hardware/our caller. > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we > also don't > > > use the device tree from build time at run time, ignoring the > device > > > tree provided to us at run time by the caller. > > > > Firstly I should say that I find building firmware very messy and > > confusing these days. Lots of things to build and it's hard to find > > the instructions. It doesn't have to be that way, but if we carry on > > as we are, it will continue to be messy and in five years you will > > need a Ph.D and a lucky charm to boot on any modern board. My > > objective here is to simplify things, bringing some consistency > to the > > different components. Binman was one effort there. I feel that > putting > > at least the U-Boot house in order, in my role as devicetree > > maintainer (and as author of devicetree support in U-Boot back in > > 2011), is the next step. > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > that know where to grab other known-good binaries of varying licenses > that are needed to assemble something that boots. > > > If we set things up correctly and agree on the bindings, devicetree > > can be the unifying configuration mechanism through the whole of > > firmware (except for very early bits) and into the OS, this will set > > us up very well to deal with the complexity that is coming. > > > > Anyway, here are the mental steps that I've gone through over the > past > > two months: > > > > Step 1: At present, some people think U-Boot is not even allowed to > > have its own nodes/properties in the DT. > > In my view U-Boot shall be able to leverage device tree format (source > and binary) to store its own data. > When you say "the" DT, I always think this is "the" DT that is passed to > OS and in "that" DT, there should be no U-Boot entries. As stated in > another mail thread, I also refer to a place in a FIP where that dynamic > config DT is meant to be stored: NT_FW_CONFIG. > But there can be U-Boot defined bindings in "a" control/dynamic config > DT; Trusted Firmware does that. It ends up in that we need two separate devicetrees. One passed to U-Boot for fixups and further passed to the OS. This devicetree may originate from a prior boot stage, from a file loaded by U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command. This devicetree will not contain any U-Boot specific information. A second devicetree to hold everything that U-Boot needs for its internal purposes. Best regards Heinrich > > It is an abuse of the > > devicetree standard, like the /chosen node but with less history. We > > should sacrifice efficiency, expedience and expandability on the > altar > > of 'devicetree is a hardware description'. How do we get over that > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > for its own purposes, as well as for booting the OS. I am not saying > > Yes, we need to have properties present in the device tree, and just > like how "linux," is a valid vendor prefix for the linux kernel (but not > used I would expect by the BSD families) we have cases that need > "u-boot," properties. > > > it always has to have those properties, but with existing features > > like verified boot, SPL as well as complex firmware images where > > U-Boot needs to be able to find things in the image, it is essential. > > So let's just assume that we need this everywhere, since we certainly > > need it in at least some places. > > No, we can't / shouldn't assume we need this everywhere. A lot of > places? Yes. But some features are going to be optional. A valid must > be supported use case is something like a Pi where the hardware gives us > a device tree, the tree is correct and some features in U-Boot aren't > needed (SPL) nor possibly supported immediately (verified boot). We can > go off on a tangent about how useful it would be to have HW platforms > that are both common and can demonstrate a number of features, but > that's its own problem to solve. > > > (stop reading here if you disagree, because nothing below will make > > any sense...you can still use U-Boot v2011.06 which doesn't have > > OF_CONTROL :-) > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > have binman definitions, etc. So we need a way to overlay those > things > > into the DT. We already support this for in-tree DTs, so IMO this is > > easy. Just require every board to have an in-tree DT. It helps with > > discoverability and documentation, anyway. That is this series. > > > > (I think most of us are at the beginning of step 2, unsure about it > > and worried about step 3) > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > flow only, or boards that sometimes use a flow) which need the DT to > > come from a prior stage. How to handle that? IMO that is only > going to > > grow as every man and his dog get into the write-a-bootloader > > business. We need a way to provide the U-Boot nodes/properties in a > > form that the prior stage can consume and integrate with its build > > system. Is TF-A the only thing being discussed here? If so, let's > just > > do it. We have the u-boot.dtsi and we can use binman to put the image > > together, for example. Or we can get clever and create some sort of > > overlay dtb. > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > then it will need to build it in and use two devicetrees, one > internal > > and one from the prior stage....well that is not very efficient > and it > > is going to be confusing for people to figure out what U-Boot is > > actually doing. But we actually already do that in a lot of cases > > where U-Boot passes a DT to the kernel which is different to the one > > it uses. So perhaps we have three devicetrees? OMG. b) Well then > > U-Boot can have its own small devicetree with its bits and then > U-Boot > > can merge the two when it starts. Again that is not very efficient. > > Does not need to merge the two. hence it does not have any influence on > efficiency. > For properties access, trusted firmware has defined an abstract way to > get them: > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html > <https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html>. > > The properties are currently implemented as DT but TF.ORG > <http://TF.ORG> could decide to move to CBOR. > The API will remain so that a change in backend will not influence > existing code. > I think you are too focused on "THE" device tree. "THE" device tree that > is passed to the OS > shall be hardware description and not a hacky place to fit any piece of > metadata. > I would argue that /chosen shall not even be there as most if not all > information can be passed as OS command line. And actually for the UEFI > contract, /chosen should go empty. > > It > > means that U-Boot cannot be controlled by the prior stage (e.g. > to get > > its public key from there or to enable/disable the console), so > > unified firmware config is not possible. It will get very confusing, > > particularly for debugging U-Boot. c) Some other scheme to avoid > > accepting step 3...please stop! > > How the nodes should get there is how the rest of the nodes in a system > get there. Bindings are submitted and reviewed. The authoritative > source of the dtses in question then has them, like any other property. > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > whole cloth. What about that? Well, we are just going to have to deal > > with that. We can easily merge in the U-Boot nodes/properties and > > update the U-Boot CI scripts to do this, as needed, e.g. with > > qemu-riscv64_spl. It's only one use case, although Xen might do > > something similar. > > > > To my mind, that deals with both the build-time and run-time issues. > > We have a discoverable DT in U-Boot, which should be considered the > > source of truth for most boards. We can sync it with Linux > > automatically with the tooling that I hope Rob Herring will come up > > with. We can use an empty one where there really is no default, > > although I'd argue that is making perfect an enemy of the good. > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > and pick them up from somewhere else, we can do that with sufficient > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > For SystemReady compliant boards, this has to come much faster. > Do you think distros will keep providing DTs for ever? I bet not. > > These last two paragraphs condense what I think is honestly close to a > decade of debate / discussion down to a fiat "U-Boot will have the DTS > files". I don't want that. I don't think any of the other projects > that want to leverage DTS files want that. > > > To repeat, if we set things up correctly and agree on the bindings, > > devicetree can be the unifying configuration mechanism through the > > whole of firmware (except for very early bits) and into the OS. I > feel > > this will set us up very well to deal with the complexity that is > > coming. > > Sure, it could. But that doesn't mean that U-Boot is where the dts > files live. > > -- > Tom > > > > -- > > François-Frédéric Ozog | /Director Business Development/ > T: +33.67221.6485 > francois.ozog@linaro.org <mailto:francois.ozog@linaro.org> | Skype: ffozog > >
Hi Tom, On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote: > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > > Hi Simon, > > > > A bit late to the party, sorry! > > > > [...] > > > > > > > > > > I really want to see what the binary case looks like since we could > then > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > functionally correct from the hardware/our caller. > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > don't > > > > use the device tree from build time at run time, ignoring the device > > > > tree provided to us at run time by the caller. > > > > > > Firstly I should say that I find building firmware very messy and > > > confusing these days. Lots of things to build and it's hard to find > > > the instructions. It doesn't have to be that way, but if we carry on > > > as we are, it will continue to be messy and in five years you will > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > objective here is to simplify things, bringing some consistency to the > > > different components. Binman was one effort there. I feel that putting > > > at least the U-Boot house in order, in my role as devicetree > > > maintainer (and as author of devicetree support in U-Boot back in > > > 2011), is the next step. > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > can be the unifying configuration mechanism through the whole of > > > firmware (except for very early bits) and into the OS, this will set > > > us up very well to deal with the complexity that is coming. > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > two months: > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > have its own nodes/properties in the DT. It is an abuse of the > > > devicetree standard, like the /chosen node but with less history. We > > > should sacrifice efficiency, expedience and expandability on the altar > > > of 'devicetree is a hardware description'. How do we get over that > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > for its own purposes, as well as for booting the OS. I am not saying > > > it always has to have those properties, but with existing features > > > like verified boot, SPL as well as complex firmware images where > > > U-Boot needs to be able to find things in the image, it is essential. > > > So let's just assume that we need this everywhere, since we certainly > > > need it in at least some places. > > > > > > (stop reading here if you disagree, because nothing below will make > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > OF_CONTROL :-) > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > that to the DTs that are copied over from linux isn't imho. There are > > various reasons for that. First of all syncing device trees is a huge > pain > > and that's probably one of the main reasons our DTs are out of sync for a > > large number of boards. > > This re-sync is only a pain because: > 1. Some platforms have been modifying the core dts files LIKE THEY ARE > NOT SUPPOSED TO. > 2. DTS files are getting closer to being the super stable API that has > been promised now that there's validation tools. > > Some SoCs, like stm32 are doing an amazing job and keeping things in > sync, every release. Others like NXP are violating rule #1. With NXP commitment to SystemReady on some IMX8 boards, I think this is changing, at least for the SystemReady boards. > Still > others like some TI platforms get bit by #2 (I solved one of these, and > need to cycle back to the one you and I talked about on IRC a while > back, I bet it's another node name dash changed to underbar). > > > The point is this was fine in 2011 were we had SPL only, but the reality > > today is completely different. There's previous stage boot loaders (and > > enough cases were vendors prefer those over SPL). If that bootloader > needs > > to use it's own device tree for whatever reason, imposing restrictions > on > > it wrt to the device tree it has to include, and require them to have > > knowledge of U-Boot and it's internal config mechanism makes no sense not > > to mention it doesn't scale at all. > > If you are passing the full device tree around, a few more > nodes/properties aren't going to make the situation worse. If we're > talking about a 60 kilobyte blob one more kilobyte isn't where we call > the line, especially since if we wait another 6 months it'll be a 62 > kilobyte file coming in from Linux instead. > This is not about size but about firmware supply chain organization. > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > have binman definitions, etc. So we need a way to overlay those things > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > easy. Just require every board to have an in-tree DT. It helps with > > > discoverability and documentation, anyway. That is this series. > > > > Again, the board might decide for it's own reason to provide it's own > DT. > > IMHO U-Boot must be able to cope with that and asking DTs to be included > in > > U-Boot source is not the right way to do that, not to mention cases were > > that's completely unrealistic (e.g QEMU or a board that reads the DTB > from > > it's flash). > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > and worried about step 3) > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > flow only, or boards that sometimes use a flow) which need the DT to > > > come from a prior stage. How to handle that? IMO that is only going to > > > grow as every man and his dog get into the write-a-bootloader > > > business. > > > > And that's exactly why we have to come up with something that scales, > without > > having to add a bunch of unusable DTs in U-Boot. > > Both of these are solved by having our bindings reviewed and upstreamed > and then what we need included in the authoritative dts files. > There shall be authoritative System Device Trees as vendors are working on. Those System Device Trees cover all aspects of a board, not just the Cortex-A part that U-Boot cares about. Out of those system device trees, a tool (lopper) is going to carve out the "authoritative dts for the cortex-A". Essentially, that carve out will correspond to what would come out of Linux. This scheme will not be generalized, just adopted by vendors on some boards. DT for those board become part of the OS ABI (meaning, the driver developper is constrained). > > > > We need a way to provide the U-Boot nodes/properties in a > > > form that the prior stage can consume and integrate with its build > > > system. Is TF-A the only thing being discussed here? If so, let's just > > > do it. We have the u-boot.dtsi and we can use binman to put the image > > > together, for example. Or we can get clever and create some sort of > > > overlay dtb. > > > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > > then it will need to build it in and use two devicetrees, one internal > > > and one from the prior stage....well that is not very efficient and it > > > is going to be confusing for people to figure out what U-Boot is > > > actually doing. But we actually already do that in a lot of cases > > > where U-Boot passes a DT to the kernel which is different to the one > > > it uses. So perhaps we have three devicetrees? OMG. > > > > No we don't. That's a moot point. If you separate the DTs U-Boot > > provides the internal one and inherits one 'generic'. Linux will be > able to use > > that. So the only case were you'll need 3 DTs is if the *vendor* breaks > the > > DT across kernel versions, In which case there's not much you can do to > > begin with and that's already a case we have to deal with. > > > > > b) Well then > > > U-Boot can have its own small devicetree with its bits and then U-Boot > > > can merge the two when it starts. Again that is not very efficient. It > > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > > its public key from there or to enable/disable the console), so > > > unified firmware config is not possible. It will get very confusing, > > > particularly for debugging U-Boot. c) Some other scheme to avoid > > > accepting step 3...please stop! > > > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > > whole cloth. What about that? Well, we are just going to have to deal > > > with that. We can easily merge in the U-Boot nodes/properties and > > > update the U-Boot CI scripts to do this, as needed, e.g. with > > > qemu-riscv64_spl. It's only one use case, although Xen might do > > > something similar. > > > > > > To my mind, that deals with both the build-time and run-time issues. > > > We have a discoverable DT in U-Boot, which should be considered the > > > source of truth for most boards. We can sync it with Linux > > > automatically with the tooling that I hope Rob Herring will come up > > > with. We can use an empty one where there really is no default, > > > although I'd argue that is making perfect an enemy of the good. > > > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > > and pick them up from somewhere else, we can do that with sufficient > > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > > > We can start slowly migrating boards and see how that works out. > > We could either use 2 device trees as you proposed, or have u-boot merge > > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd > prefer > > if linux gets handed a clean device tree without the u-boot internals in > > it, so I think 2 discrete DTs is cleaner overall. > > Why does it matter if Linux sees some u-boot, properties? If some huge > stink is going to be thrown, we could probably prune them out at run > time but it's already being passed N disabled nodes, yes? > > -- > Tom >
On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote: > Hi Tom, > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote: > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > > > Hi Simon, > > > > > > A bit late to the party, sorry! > > > > > > [...] > > > > > > > > > > > > > I really want to see what the binary case looks like since we could > > then > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > > don't > > > > > use the device tree from build time at run time, ignoring the device > > > > > tree provided to us at run time by the caller. > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > confusing these days. Lots of things to build and it's hard to find > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > as we are, it will continue to be messy and in five years you will > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > objective here is to simplify things, bringing some consistency to the > > > > different components. Binman was one effort there. I feel that putting > > > > at least the U-Boot house in order, in my role as devicetree > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > 2011), is the next step. > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > can be the unifying configuration mechanism through the whole of > > > > firmware (except for very early bits) and into the OS, this will set > > > > us up very well to deal with the complexity that is coming. > > > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > > two months: > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > have its own nodes/properties in the DT. It is an abuse of the > > > > devicetree standard, like the /chosen node but with less history. We > > > > should sacrifice efficiency, expedience and expandability on the altar > > > > of 'devicetree is a hardware description'. How do we get over that > > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > > for its own purposes, as well as for booting the OS. I am not saying > > > > it always has to have those properties, but with existing features > > > > like verified boot, SPL as well as complex firmware images where > > > > U-Boot needs to be able to find things in the image, it is essential. > > > > So let's just assume that we need this everywhere, since we certainly > > > > need it in at least some places. > > > > > > > > (stop reading here if you disagree, because nothing below will make > > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > > OF_CONTROL :-) > > > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > > that to the DTs that are copied over from linux isn't imho. There are > > > various reasons for that. First of all syncing device trees is a huge > > pain > > > and that's probably one of the main reasons our DTs are out of sync for a > > > large number of boards. > > > > This re-sync is only a pain because: > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE > > NOT SUPPOSED TO. > > 2. DTS files are getting closer to being the super stable API that has > > been promised now that there's validation tools. > > > > Some SoCs, like stm32 are doing an amazing job and keeping things in > > sync, every release. Others like NXP are violating rule #1. > > With NXP commitment to SystemReady on some IMX8 boards, I think this is > changing, > at least for the SystemReady boards. I'd really like to see some progress (as would the other non-NXP folks working on NXP SoCs) in that regard. > > Still > > others like some TI platforms get bit by #2 (I solved one of these, and > > need to cycle back to the one you and I talked about on IRC a while > > back, I bet it's another node name dash changed to underbar). > > > > > The point is this was fine in 2011 were we had SPL only, but the reality > > > today is completely different. There's previous stage boot loaders (and > > > enough cases were vendors prefer those over SPL). If that bootloader > > needs > > > to use it's own device tree for whatever reason, imposing restrictions > > on > > > it wrt to the device tree it has to include, and require them to have > > > knowledge of U-Boot and it's internal config mechanism makes no sense not > > > to mention it doesn't scale at all. > > > > If you are passing the full device tree around, a few more > > nodes/properties aren't going to make the situation worse. If we're > > talking about a 60 kilobyte blob one more kilobyte isn't where we call > > the line, especially since if we wait another 6 months it'll be a 62 > > kilobyte file coming in from Linux instead. > > This is not about size but about firmware supply chain organization. That's great since it means we just need the bindings reviewed then everyone can pass whatever everyone else needs. > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > > have binman definitions, etc. So we need a way to overlay those things > > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > > easy. Just require every board to have an in-tree DT. It helps with > > > > discoverability and documentation, anyway. That is this series. > > > > > > Again, the board might decide for it's own reason to provide it's own > > DT. > > > IMHO U-Boot must be able to cope with that and asking DTs to be included > > in > > > U-Boot source is not the right way to do that, not to mention cases were > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB > > from > > > it's flash). > > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > > and worried about step 3) > > > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > > flow only, or boards that sometimes use a flow) which need the DT to > > > > come from a prior stage. How to handle that? IMO that is only going to > > > > grow as every man and his dog get into the write-a-bootloader > > > > business. > > > > > > And that's exactly why we have to come up with something that scales, > > without > > > having to add a bunch of unusable DTs in U-Boot. > > > > Both of these are solved by having our bindings reviewed and upstreamed > > and then what we need included in the authoritative dts files. > > > There shall be authoritative System Device Trees as vendors are working on. > Those System Device Trees cover all aspects of a board, not just the > Cortex-A part that U-Boot cares about. > Out of those system device trees, a tool (lopper) is going to carve out the > "authoritative dts for the cortex-A". > Essentially, that carve out will correspond to what would come out of Linux. s/Linux/software/ > This scheme will not be generalized, just adopted by vendors on some > boards. > DT for those board become part of the OS ABI (meaning, the driver > developper is constrained). OK? And is going to pick and choose which valid bindings to implement? Or is it going to provide half a node for Linux? No? I assume no. So it will also provide whatever bindings we've upstreamed and say need to be passed.
Hi trying to reply to all at the same time! On Wed, Oct 27, 2021 at 09:38:40AM -0400, Tom Rini wrote: > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote: > > Hi Tom, > > > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote: > > > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > > > > Hi Simon, > > > > > > > > A bit late to the party, sorry! > > > > > > > > [...] > > > > > > > > > > > > > > > > I really want to see what the binary case looks like since we could > > > then > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > > > don't > > > > > > use the device tree from build time at run time, ignoring the device > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > confusing these days. Lots of things to build and it's hard to find > > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > > as we are, it will continue to be messy and in five years you will > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > objective here is to simplify things, bringing some consistency to the > > > > > different components. Binman was one effort there. I feel that putting > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > 2011), is the next step. > > > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > > can be the unifying configuration mechanism through the whole of > > > > > firmware (except for very early bits) and into the OS, this will set > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > > > two months: > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > > have its own nodes/properties in the DT. It is an abuse of the > > > > > devicetree standard, like the /chosen node but with less history. We > > > > > should sacrifice efficiency, expedience and expandability on the altar > > > > > of 'devicetree is a hardware description'. How do we get over that > > > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > > > for its own purposes, as well as for booting the OS. I am not saying > > > > > it always has to have those properties, but with existing features > > > > > like verified boot, SPL as well as complex firmware images where > > > > > U-Boot needs to be able to find things in the image, it is essential. > > > > > So let's just assume that we need this everywhere, since we certainly > > > > > need it in at least some places. > > > > > > > > > > (stop reading here if you disagree, because nothing below will make > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > > > OF_CONTROL :-) > > > > > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > > > that to the DTs that are copied over from linux isn't imho. There are > > > > various reasons for that. First of all syncing device trees is a huge > > > pain > > > > and that's probably one of the main reasons our DTs are out of sync for a > > > > large number of boards. > > > > > > This re-sync is only a pain because: > > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE > > > NOT SUPPOSED TO. > > > 2. DTS files are getting closer to being the super stable API that has > > > been promised now that there's validation tools. Agree on both, but still this is the reality we have to deal with right now > > > > > > Some SoCs, like stm32 are doing an amazing job and keeping things in > > > sync, every release. Others like NXP are violating rule #1. > > > > With NXP commitment to SystemReady on some IMX8 boards, I think this is > > changing, > > at least for the SystemReady boards. > > I'd really like to see some progress (as would the other non-NXP folks > working on NXP SoCs) in that regard. > > > > Still > > > others like some TI platforms get bit by #2 (I solved one of these, and > > > need to cycle back to the one you and I talked about on IRC a while > > > back, I bet it's another node name dash changed to underbar). > > > > > > > The point is this was fine in 2011 were we had SPL only, but the reality > > > > today is completely different. There's previous stage boot loaders (and > > > > enough cases were vendors prefer those over SPL). If that bootloader > > > needs > > > > to use it's own device tree for whatever reason, imposing restrictions > > > on > > > > it wrt to the device tree it has to include, and require them to have > > > > knowledge of U-Boot and it's internal config mechanism makes no sense not > > > > to mention it doesn't scale at all. > > > > > > If you are passing the full device tree around, a few more > > > nodes/properties aren't going to make the situation worse. If we're > > > talking about a 60 kilobyte blob one more kilobyte isn't where we call > > > the line, especially since if we wait another 6 months it'll be a 62 > > > kilobyte file coming in from Linux instead. > > > > This is not about size but about firmware supply chain organization. > > That's great since it means we just need the bindings reviewed then > everyone can pass whatever everyone else needs. > Size here is not my concern. If the bindings u-boot expects gets upstreamed I am obviously fine with the previous stage bootloader passing them over. What I strongly disagree, is *demand* the previous stage boot loader have knowledge about them if they are not in upstream. > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > > > have binman definitions, etc. So we need a way to overlay those things > > > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > > > easy. Just require every board to have an in-tree DT. It helps with > > > > > discoverability and documentation, anyway. That is this series. > > > > > > > > Again, the board might decide for it's own reason to provide it's own > > > DT. > > > > IMHO U-Boot must be able to cope with that and asking DTs to be included > > > in > > > > U-Boot source is not the right way to do that, not to mention cases were > > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB > > > from > > > > it's flash). > > > > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > > > and worried about step 3) > > > > > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > > > flow only, or boards that sometimes use a flow) which need the DT to > > > > > come from a prior stage. How to handle that? IMO that is only going to > > > > > grow as every man and his dog get into the write-a-bootloader > > > > > business. > > > > > > > > And that's exactly why we have to come up with something that scales, > > > without > > > > having to add a bunch of unusable DTs in U-Boot. > > > > > > Both of these are solved by having our bindings reviewed and upstreamed > > > and then what we need included in the authoritative dts files. > > > yes > > There shall be authoritative System Device Trees as vendors are working on. > > Those System Device Trees cover all aspects of a board, not just the > > Cortex-A part that U-Boot cares about. > > Out of those system device trees, a tool (lopper) is going to carve out the > > "authoritative dts for the cortex-A". > > Essentially, that carve out will correspond to what would come out of Linux. > > s/Linux/software/ > > > This scheme will not be generalized, just adopted by vendors on some > > boards. > > DT for those board become part of the OS ABI (meaning, the driver > > developper is constrained). > > OK? And is going to pick and choose which valid bindings to implement? > Or is it going to provide half a node for Linux? No? I assume no. So > it will also provide whatever bindings we've upstreamed and say need to > be passed. > > -- > Tom Regards /Ilias
On Wed, 27 Oct 2021 at 15:38, Tom Rini <trini@konsulko.com> wrote: > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote: > > Hi Tom, > > > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote: > > > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > > > > Hi Simon, > > > > > > > > A bit late to the party, sorry! > > > > > > > > [...] > > > > > > > > > > > > > > > > I really want to see what the binary case looks like since we > could > > > then > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > could > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can > come > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > > > don't > > > > > > use the device tree from build time at run time, ignoring the > device > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > confusing these days. Lots of things to build and it's hard to find > > > > > the instructions. It doesn't have to be that way, but if we carry > on > > > > > as we are, it will continue to be messy and in five years you will > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > objective here is to simplify things, bringing some consistency to > the > > > > > different components. Binman was one effort there. I feel that > putting > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > 2011), is the next step. > > > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > > can be the unifying configuration mechanism through the whole of > > > > > firmware (except for very early bits) and into the OS, this will > set > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the > past > > > > > two months: > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > > have its own nodes/properties in the DT. It is an abuse of the > > > > > devicetree standard, like the /chosen node but with less history. > We > > > > > should sacrifice efficiency, expedience and expandability on the > altar > > > > > of 'devicetree is a hardware description'. How do we get over that > > > > > one? Wel, I just think we need to accept that U-Boot uses > devicetree > > > > > for its own purposes, as well as for booting the OS. I am not > saying > > > > > it always has to have those properties, but with existing features > > > > > like verified boot, SPL as well as complex firmware images where > > > > > U-Boot needs to be able to find things in the image, it is > essential. > > > > > So let's just assume that we need this everywhere, since we > certainly > > > > > need it in at least some places. > > > > > > > > > > (stop reading here if you disagree, because nothing below will make > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > > > OF_CONTROL :-) > > > > > > > > Having U-Boot keep it's *internal* config state in DTs is fine. > Adding > > > > that to the DTs that are copied over from linux isn't imho. There > are > > > > various reasons for that. First of all syncing device trees is a > huge > > > pain > > > > and that's probably one of the main reasons our DTs are out of sync > for a > > > > large number of boards. > > > > > > This re-sync is only a pain because: > > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE > > > NOT SUPPOSED TO. > > > 2. DTS files are getting closer to being the super stable API that has > > > been promised now that there's validation tools. > > > > > > Some SoCs, like stm32 are doing an amazing job and keeping things in > > > sync, every release. Others like NXP are violating rule #1. > > > > With NXP commitment to SystemReady on some IMX8 boards, I think this is > > changing, > > at least for the SystemReady boards. > > I'd really like to see some progress (as would the other non-NXP folks > working on NXP SoCs) in that regard. > > > > Still > > > others like some TI platforms get bit by #2 (I solved one of these, and > > > need to cycle back to the one you and I talked about on IRC a while > > > back, I bet it's another node name dash changed to underbar). > > > > > > > The point is this was fine in 2011 were we had SPL only, but the > reality > > > > today is completely different. There's previous stage boot loaders > (and > > > > enough cases were vendors prefer those over SPL). If that bootloader > > > needs > > > > to use it's own device tree for whatever reason, imposing > restrictions > > > on > > > > it wrt to the device tree it has to include, and require them to > have > > > > knowledge of U-Boot and it's internal config mechanism makes no > sense not > > > > to mention it doesn't scale at all. > > > > > > If you are passing the full device tree around, a few more > > > nodes/properties aren't going to make the situation worse. If we're > > > talking about a 60 kilobyte blob one more kilobyte isn't where we call > > > the line, especially since if we wait another 6 months it'll be a 62 > > > kilobyte file coming in from Linux instead. > > > > This is not about size but about firmware supply chain organization. > > That's great since it means we just need the bindings reviewed then > everyone can pass whatever everyone else needs. > > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), > we > > > > > have binman definitions, etc. So we need a way to overlay those > things > > > > > into the DT. We already support this for in-tree DTs, so IMO this > is > > > > > easy. Just require every board to have an in-tree DT. It helps with > > > > > discoverability and documentation, anyway. That is this series. > > > > > > > > Again, the board might decide for it's own reason to provide it's own > > > DT. > > > > IMHO U-Boot must be able to cope with that and asking DTs to be > included > > > in > > > > U-Boot source is not the right way to do that, not to mention cases > were > > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB > > > from > > > > it's flash). > > > > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > > > and worried about step 3) > > > > > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > > > flow only, or boards that sometimes use a flow) which need the DT > to > > > > > come from a prior stage. How to handle that? IMO that is only > going to > > > > > grow as every man and his dog get into the write-a-bootloader > > > > > business. > > > > > > > > And that's exactly why we have to come up with something that scales, > > > without > > > > having to add a bunch of unusable DTs in U-Boot. > > > > > > Both of these are solved by having our bindings reviewed and upstreamed > > > and then what we need included in the authoritative dts files. > > > > > There shall be authoritative System Device Trees as vendors are working > on. > > Those System Device Trees cover all aspects of a board, not just the > > Cortex-A part that U-Boot cares about. > > Out of those system device trees, a tool (lopper) is going to carve out > the > > "authoritative dts for the cortex-A". > > Essentially, that carve out will correspond to what would come out of > Linux. > > s/Linux/software/ > > > This scheme will not be generalized, just adopted by vendors on some > > boards. > > DT for those board become part of the OS ABI (meaning, the driver > > developper is constrained). > > OK? And is going to pick and choose which valid bindings to implement? > Or is it going to provide half a node for Linux? No? I assume no. So > it will also provide whatever bindings we've upstreamed and say need to > be passed. > Until we can agree on a better scheme, Linux will server as the basis for most of the bindings. Some projects, like TF-A maintain their own bindings specifications. I guess U-Boot shall do the same. The U-Boot DT (for properties or whatever purpose) can be stored in a various of U-Boot decided ways and as part of the TF-A FIP image in the ad-hoc section: NT_FW_CONFIG. Passing FIP information to U-Boot to retrieve the NF_FW_CONFIG should be part of the blob_list discussion that started a while ago. For System Device Tree, the bindings and the master repo will be maintained in devicetree.org (AFAIK). > > -- > Tom >
On Wed, Oct 27, 2021 at 04:47:55PM +0300, Ilias Apalodimas wrote: > Hi trying to reply to all at the same time! > > On Wed, Oct 27, 2021 at 09:38:40AM -0400, Tom Rini wrote: > > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote: > > > Hi Tom, > > > > > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > > > > > Hi Simon, > > > > > > > > > > A bit late to the party, sorry! > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > I really want to see what the binary case looks like since we could > > > > then > > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > > > > don't > > > > > > > use the device tree from build time at run time, ignoring the device > > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > > confusing these days. Lots of things to build and it's hard to find > > > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > > > as we are, it will continue to be messy and in five years you will > > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > > objective here is to simplify things, bringing some consistency to the > > > > > > different components. Binman was one effort there. I feel that putting > > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > > 2011), is the next step. > > > > > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > > > can be the unifying configuration mechanism through the whole of > > > > > > firmware (except for very early bits) and into the OS, this will set > > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > > > > two months: > > > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > > > have its own nodes/properties in the DT. It is an abuse of the > > > > > > devicetree standard, like the /chosen node but with less history. We > > > > > > should sacrifice efficiency, expedience and expandability on the altar > > > > > > of 'devicetree is a hardware description'. How do we get over that > > > > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > > > > for its own purposes, as well as for booting the OS. I am not saying > > > > > > it always has to have those properties, but with existing features > > > > > > like verified boot, SPL as well as complex firmware images where > > > > > > U-Boot needs to be able to find things in the image, it is essential. > > > > > > So let's just assume that we need this everywhere, since we certainly > > > > > > need it in at least some places. > > > > > > > > > > > > (stop reading here if you disagree, because nothing below will make > > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > > > > OF_CONTROL :-) > > > > > > > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > > > > that to the DTs that are copied over from linux isn't imho. There are > > > > > various reasons for that. First of all syncing device trees is a huge > > > > pain > > > > > and that's probably one of the main reasons our DTs are out of sync for a > > > > > large number of boards. > > > > > > > > This re-sync is only a pain because: > > > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE > > > > NOT SUPPOSED TO. > > > > 2. DTS files are getting closer to being the super stable API that has > > > > been promised now that there's validation tools. > > Agree on both, but still this is the reality we have to deal with right now > > > > > > > > > Some SoCs, like stm32 are doing an amazing job and keeping things in > > > > sync, every release. Others like NXP are violating rule #1. > > > > > > With NXP commitment to SystemReady on some IMX8 boards, I think this is > > > changing, > > > at least for the SystemReady boards. > > > > I'd really like to see some progress (as would the other non-NXP folks > > working on NXP SoCs) in that regard. > > > > > > Still > > > > others like some TI platforms get bit by #2 (I solved one of these, and > > > > need to cycle back to the one you and I talked about on IRC a while > > > > back, I bet it's another node name dash changed to underbar). > > > > > > > > > The point is this was fine in 2011 were we had SPL only, but the reality > > > > > today is completely different. There's previous stage boot loaders (and > > > > > enough cases were vendors prefer those over SPL). If that bootloader > > > > needs > > > > > to use it's own device tree for whatever reason, imposing restrictions > > > > on > > > > > it wrt to the device tree it has to include, and require them to have > > > > > knowledge of U-Boot and it's internal config mechanism makes no sense not > > > > > to mention it doesn't scale at all. > > > > > > > > If you are passing the full device tree around, a few more > > > > nodes/properties aren't going to make the situation worse. If we're > > > > talking about a 60 kilobyte blob one more kilobyte isn't where we call > > > > the line, especially since if we wait another 6 months it'll be a 62 > > > > kilobyte file coming in from Linux instead. > > > > > > This is not about size but about firmware supply chain organization. > > > > That's great since it means we just need the bindings reviewed then > > everyone can pass whatever everyone else needs. > > > > Size here is not my concern. If the bindings u-boot expects gets > upstreamed I am obviously fine with the previous stage bootloader passing > them over. What I strongly disagree, is *demand* the previous stage boot > loader have knowledge about them if they are not in upstream. I also agree that bindings MUST be upstreamed for there to be a reasonable expectation that any other project (or human creating a dts) be adding them, either statically or any sort of run-time modification (think memory information, this gets fixed up at run-time often still). And it may end up being zero "u-boot,FOO" bindings where this is the case. Or it may end up being related to secure / verified boot stuff only.
On Wed, Oct 27, 2021 at 03:48:48PM +0200, François Ozog wrote: > On Wed, 27 Oct 2021 at 15:38, Tom Rini <trini@konsulko.com> wrote: > > > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote: > > > Hi Tom, > > > > > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote: > > > > > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > > > > > Hi Simon, > > > > > > > > > > A bit late to the party, sorry! > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > I really want to see what the binary case looks like since we > > could > > > > then > > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > > could > > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can > > come > > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > > > > don't > > > > > > > use the device tree from build time at run time, ignoring the > > device > > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > > confusing these days. Lots of things to build and it's hard to find > > > > > > the instructions. It doesn't have to be that way, but if we carry > > on > > > > > > as we are, it will continue to be messy and in five years you will > > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > > objective here is to simplify things, bringing some consistency to > > the > > > > > > different components. Binman was one effort there. I feel that > > putting > > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > > 2011), is the next step. > > > > > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > > > can be the unifying configuration mechanism through the whole of > > > > > > firmware (except for very early bits) and into the OS, this will > > set > > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the > > past > > > > > > two months: > > > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > > > have its own nodes/properties in the DT. It is an abuse of the > > > > > > devicetree standard, like the /chosen node but with less history. > > We > > > > > > should sacrifice efficiency, expedience and expandability on the > > altar > > > > > > of 'devicetree is a hardware description'. How do we get over that > > > > > > one? Wel, I just think we need to accept that U-Boot uses > > devicetree > > > > > > for its own purposes, as well as for booting the OS. I am not > > saying > > > > > > it always has to have those properties, but with existing features > > > > > > like verified boot, SPL as well as complex firmware images where > > > > > > U-Boot needs to be able to find things in the image, it is > > essential. > > > > > > So let's just assume that we need this everywhere, since we > > certainly > > > > > > need it in at least some places. > > > > > > > > > > > > (stop reading here if you disagree, because nothing below will make > > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > > > > OF_CONTROL :-) > > > > > > > > > > Having U-Boot keep it's *internal* config state in DTs is fine. > > Adding > > > > > that to the DTs that are copied over from linux isn't imho. There > > are > > > > > various reasons for that. First of all syncing device trees is a > > huge > > > > pain > > > > > and that's probably one of the main reasons our DTs are out of sync > > for a > > > > > large number of boards. > > > > > > > > This re-sync is only a pain because: > > > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE > > > > NOT SUPPOSED TO. > > > > 2. DTS files are getting closer to being the super stable API that has > > > > been promised now that there's validation tools. > > > > > > > > Some SoCs, like stm32 are doing an amazing job and keeping things in > > > > sync, every release. Others like NXP are violating rule #1. > > > > > > With NXP commitment to SystemReady on some IMX8 boards, I think this is > > > changing, > > > at least for the SystemReady boards. > > > > I'd really like to see some progress (as would the other non-NXP folks > > working on NXP SoCs) in that regard. > > > > > > Still > > > > others like some TI platforms get bit by #2 (I solved one of these, and > > > > need to cycle back to the one you and I talked about on IRC a while > > > > back, I bet it's another node name dash changed to underbar). > > > > > > > > > The point is this was fine in 2011 were we had SPL only, but the > > reality > > > > > today is completely different. There's previous stage boot loaders > > (and > > > > > enough cases were vendors prefer those over SPL). If that bootloader > > > > needs > > > > > to use it's own device tree for whatever reason, imposing > > restrictions > > > > on > > > > > it wrt to the device tree it has to include, and require them to > > have > > > > > knowledge of U-Boot and it's internal config mechanism makes no > > sense not > > > > > to mention it doesn't scale at all. > > > > > > > > If you are passing the full device tree around, a few more > > > > nodes/properties aren't going to make the situation worse. If we're > > > > talking about a 60 kilobyte blob one more kilobyte isn't where we call > > > > the line, especially since if we wait another 6 months it'll be a 62 > > > > kilobyte file coming in from Linux instead. > > > > > > This is not about size but about firmware supply chain organization. > > > > That's great since it means we just need the bindings reviewed then > > everyone can pass whatever everyone else needs. > > > > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), > > we > > > > > > have binman definitions, etc. So we need a way to overlay those > > things > > > > > > into the DT. We already support this for in-tree DTs, so IMO this > > is > > > > > > easy. Just require every board to have an in-tree DT. It helps with > > > > > > discoverability and documentation, anyway. That is this series. > > > > > > > > > > Again, the board might decide for it's own reason to provide it's own > > > > DT. > > > > > IMHO U-Boot must be able to cope with that and asking DTs to be > > included > > > > in > > > > > U-Boot source is not the right way to do that, not to mention cases > > were > > > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB > > > > from > > > > > it's flash). > > > > > > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > > > > and worried about step 3) > > > > > > > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > > > > flow only, or boards that sometimes use a flow) which need the DT > > to > > > > > > come from a prior stage. How to handle that? IMO that is only > > going to > > > > > > grow as every man and his dog get into the write-a-bootloader > > > > > > business. > > > > > > > > > > And that's exactly why we have to come up with something that scales, > > > > without > > > > > having to add a bunch of unusable DTs in U-Boot. > > > > > > > > Both of these are solved by having our bindings reviewed and upstreamed > > > > and then what we need included in the authoritative dts files. > > > > > > > There shall be authoritative System Device Trees as vendors are working > > on. > > > Those System Device Trees cover all aspects of a board, not just the > > > Cortex-A part that U-Boot cares about. > > > Out of those system device trees, a tool (lopper) is going to carve out > > the > > > "authoritative dts for the cortex-A". > > > Essentially, that carve out will correspond to what would come out of > > Linux. > > > > s/Linux/software/ > > > > > This scheme will not be generalized, just adopted by vendors on some > > > boards. > > > DT for those board become part of the OS ABI (meaning, the driver > > > developper is constrained). > > > > OK? And is going to pick and choose which valid bindings to implement? > > Or is it going to provide half a node for Linux? No? I assume no. So > > it will also provide whatever bindings we've upstreamed and say need to > > be passed. > > > Until we can agree on a better scheme, Linux will server as the basis for > most of the bindings. Yes, this is the de-facto standard since the beginning. > Some projects, like TF-A maintain their own bindings specifications. I And as I keep saying I believe this to be totally wrong. Unless and only unless the TF-A bindings are for TF-A only to care about, and then it's just one-off do what you guys want non-standard stuff. > guess U-Boot shall do the same. No, U-Boot is going to upstream the bindings that we want to have be considered official. > The U-Boot DT (for properties or whatever purpose) can be stored in a > various of U-Boot decided ways and as part of the TF-A FIP image in the > ad-hoc section: NT_FW_CONFIG. Passing FIP information to U-Boot to retrieve > the NF_FW_CONFIG should be part of the blob_list discussion that started a > while ago. Yes, we'll have to see where things progress about what bindings are needed, and where. > For System Device Tree, the bindings and the master repo will be maintained > in devicetree.org (AFAIK). Interesting, okay.
On Wed, Oct 27, 2021 at 03:15:01PM +0200, François Ozog wrote: > Hi, > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > Hi all, > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > Hi François, > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> > > a écrit : > > > > > > > >> > > > > > > > >> Hi Tom, Bin,François, > > > > > > > >> > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> > > wrote: > > > > > > > >> > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > > > >> > > Hi Simon, > > > > > > > >> > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > sjg@chromium.org> wrote: > > > > > > > >> > > > > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > OF_HOSTFILE so > > > > > > > >> > > > there are only three ways to obtain a devicetree: > > > > > > > >> > > > > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the devicetree > > is built and > > > > > > > >> > > > appended to U-Boot > > > > > > > >> > > > - OF_EMBED - for development purposes, the > > devicetree is embedded in > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > >> > > > - OF_BOARD - the board figures it out on its own > > > > > > > >> > > > > > > > > > > >> > > > The last one is currently set up so that no devicetree > > is needed at all > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, but > > some don't. Some > > > > > > > >> > > > don't even provide instructions on how to boot on the > > board. > > > > > > > >> > > > > > > > > > > >> > > > The problems with this approach are documented at [1]. > > > > > > > >> > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > > OF_SEPARATE. Any board > > > > > > > >> > > > can obtain its devicetree at runtime, even it is has a > > devicetree built > > > > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage > > bootloader and its > > > > > > > >> > > > caller may have a better idea about the hardware > > available in the machine. > > > > > > > >> > > > This is the case with a few QEMU boards, for example. > > > > > > > >> > > > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > should be an > > > > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > >> > > > > > > > > > > >> > > > This series makes this change, adding various missing > > devicetree files > > > > > > > >> > > > (and placeholders) to make the build work. > > > > > > > >> > > > > > > > > > >> > > Adding device trees that are never used sounds like a > > hack to me. > > > > > > > >> > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > > based on > > > > > > > >> > > command line parameters, and the device tree you put in > > this series > > > > > > > >> > > has various hardcoded <phandle> values which normally do > > not show up > > > > > > > >> > > in hand-written dts files. > > > > > > > >> > > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > > >> > > > > > > > > >> > I am also confused and do not like the idea of adding > > device trees for > > > > > > > >> > platforms that are capable of and can / do have a device > > tree to give us > > > > > > > >> > at run time. > > > > > > > >> > > > > > > > >> (I'll just reply to this one email, since the same points > > applies to > > > > > > > >> all replies I think) > > > > > > > >> > > > > > > > >> I have been thinking about this and discussing it with people > > for a > > > > > > > >> few months now. I've been signalling a change like this for > > over a > > > > > > > >> month now, on U-Boot contributor calls and in discussions > > with Linaro > > > > > > > >> people. I sent a patch (below) to try to explain things. I > > hope it is > > > > > > > >> not a surprise! > > > > > > > >> > > > > > > > >> The issue here is that we need a devicetree in-tree in > > U-Boot, to > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, > > OF_BOARD, > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. > > Between > > > > > > > >> Ilias' series and this one we can get ourselves on a stronger > > footing. > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF > > use. > > > > > > > >> For more context: > > > > > > > >> > > > > > > > >> > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > >> > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of > > adding the > > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > > > > >> maintainer would prefer there was no special support even for > > booting > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > >> > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > >> think the path forward might be to run QEMU twice, once to > > get its > > > > > > > >> generated tree and once to give the 'merged' tree with the > > U-Boot > > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > > >> > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > option, not a > > > > > > > >> build-time one. It creates all sorts of problems and > > obscurity which > > > > > > > >> have taken months to unpick. See the above patch for the > > rationale. > > > > > > > >> > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option > > available to > > > > > > > >> any board. At some point in the future it may become a common > > way > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > > devicetree > > > > > > > >> to it. It doesn't make any sense to have people decide > > whether or not > > > > > > > >> to set OF_BOARD at build time, thus affecting how the image > > is put > > > > > > > >> together. We'll end up with different U-Boot build targets > > like > > > > > > > >> capricorn, capricorn_of_board and the like. It should be > > obvious where > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly > > used > > > > > > > >> option, perhaps enabled by most/all boards, so that this sort > > of build > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > If you mean that when boards are by construction providing a > > DTB to U-Boot then I agree very much. But I don’t understand how the patch > > set supports it as it puts dts files for those boards to be built. > > > > > > > >> > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > >> function correctly in whatever runtime environment in which > > it finds > > > > > > > >> itself. > > > > > > > >> > > > > > > > >> Also as binman is pressed into service more and more to build > > the > > > > > > > >> complex firmware images that are becoming fashionable, it > > needs a > > > > > > > >> definition (in the devicetree) that describes how to create > > the image. > > > > > > > >> We can't support that unless we are building a devicetree, > > nor can the > > > > > > > >> running program access the image layout without that > > information. > > > > > > > >> > > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > > >> germane...but of course I am not suggesting doing that, since > > OF_BOARD > > > > > > > >> is, still, enabled. We already use OF_BOARD for various > > boards that > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for > > example > > > > > > > >> (as I said in the cover letter "Most boards do provide one, > > but some > > > > > > > >> don't."). So this series is just completing the picture by > > enforcing > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > > > > > > > I think the key point that will get you closer to where I am on > > this > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > present it > > > > > > > has build-time effects and this is quite wrong. If you go > > through all > > > > > > > the material I have written on this I think I have motivated > > that very > > > > > > > clearly. > > > > > > > > > > > > > > Another big issue is that I believe we need ONE devicetree for > > U-Boot, > > > > > > > not two that get merged by U-Boot. Again I have gone through > > that in a > > > > > > > lot of detail. > > > > > > > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > > > > here's the biggest sticking point. To be clear, you agree that > > U-Boot > > > > > > needs to support being passed a device tree to use, at run time, > > yes? > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > > > > > > > Not at runtime. > > > > > > > > OK. > > > > > > > > > > So is the sticking point here that we really have two classes of > > > > > > devices, one class where we will never ever be given the device > > tree at > > > > > > run time (think BeagleBone Black) and one where we will always be > > given > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > I'm not sure it will be that black and white. I suspect there will be > > > > > (many) boards which can boot happily with the U-Boot devicetree but > > > > > can also accept one at runtime, if provided. For example, you may > > want > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > I'm not sure I see the value in making this a gray area. There's very > > > > much a class of "never" boards. There's also the class of "can" today. > > > > Maybe as part of a developer iterative flow it would be nice to not > > have > > > > to re-flash the prior stage to change a DT, and just do it in U-Boot > > > > until things are happy, but I'm not sure what the use case is for > > > > overriding the previous stage. > > > > > > > > Especially since the pushback on this series I think has all been "why > > > > are we copying in a tree to build with? We don't want to use it at run > > > > time!". And then softer push back like "Well, U-Boot says we have to > > > > include the device tree file here, but we won't use it...". > > > > > > See below. > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > inadvertently) > > > > > provided a way to entirely omit a devicetree from U-Boot, thus making > > > > > things like binman and U-Boot /config impossible, for example. So I > > > > > want to claw that back, so there is always some sort of devicetree in > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > I really want to see what the binary case looks like since we could > > then > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > functionally correct from the hardware/our caller. > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > > use the device tree from build time at run time, ignoring the device > > > > tree provided to us at run time by the caller. > > > > > > Firstly I should say that I find building firmware very messy and > > > confusing these days. Lots of things to build and it's hard to find > > > the instructions. It doesn't have to be that way, but if we carry on > > > as we are, it will continue to be messy and in five years you will > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > objective here is to simplify things, bringing some consistency to the > > > different components. Binman was one effort there. I feel that putting > > > at least the U-Boot house in order, in my role as devicetree > > > maintainer (and as author of devicetree support in U-Boot back in > > > 2011), is the next step. > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > > that know where to grab other known-good binaries of varying licenses > > that are needed to assemble something that boots. > > > > > If we set things up correctly and agree on the bindings, devicetree > > > can be the unifying configuration mechanism through the whole of > > > firmware (except for very early bits) and into the OS, this will set > > > us up very well to deal with the complexity that is coming. > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > two months: > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > have its own nodes/properties in the DT. > > In my view U-Boot shall be able to leverage device tree format (source and > binary) to store its own data. > When you say "the" DT, I always think this is "the" DT that is passed to OS > and in "that" DT, there should be no U-Boot entries. As stated in another I would (and I know I'm repeating myself and emails have crossed, etc, but for future clarity) say it's that no un-official nodes/properties should be passed from one piece of software to another. I mean hell, "u-boot,bootcount" MUST get passed to the OS, so has some idea how many times the system has booted. It's just a long standing item to get that bootcount driver / binding unblocked and merged finally. But that's a different tangent to get lost on. > mail thread, I also refer to a place in a FIP where that dynamic config DT > is meant to be stored: NT_FW_CONFIG. > But there can be U-Boot defined bindings in "a" control/dynamic config DT; > Trusted Firmware does that. Maybe I just need to come out and say if "everyone" has decided how U-Boot needs to work, but also myself (head custodian) and Simon (head DM custodian, device tree in U-Boot custodian) aren't 100% on board with everything, maybe some step back and re-evaluation needs to be taken? And I'm not saying we're the final word only here either, there has been and needs to continue to be good faith discussions. It should also be clear at this point that he and I aren't on the same page on everything, for example :) > > It is an abuse of the > > > devicetree standard, like the /chosen node but with less history. We > > > should sacrifice efficiency, expedience and expandability on the altar > > > of 'devicetree is a hardware description'. How do we get over that > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > for its own purposes, as well as for booting the OS. I am not saying > > > > Yes, we need to have properties present in the device tree, and just > > like how "linux," is a valid vendor prefix for the linux kernel (but not > > used I would expect by the BSD families) we have cases that need > > "u-boot," properties. > > > > > it always has to have those properties, but with existing features > > > like verified boot, SPL as well as complex firmware images where > > > U-Boot needs to be able to find things in the image, it is essential. > > > So let's just assume that we need this everywhere, since we certainly > > > need it in at least some places. > > > > No, we can't / shouldn't assume we need this everywhere. A lot of > > places? Yes. But some features are going to be optional. A valid must > > be supported use case is something like a Pi where the hardware gives us > > a device tree, the tree is correct and some features in U-Boot aren't > > needed (SPL) nor possibly supported immediately (verified boot). We can > > go off on a tangent about how useful it would be to have HW platforms > > that are both common and can demonstrate a number of features, but > > that's its own problem to solve. > > > > > (stop reading here if you disagree, because nothing below will make > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > OF_CONTROL :-) > > > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > have binman definitions, etc. So we need a way to overlay those things > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > easy. Just require every board to have an in-tree DT. It helps with > > > discoverability and documentation, anyway. That is this series. > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > and worried about step 3) > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > flow only, or boards that sometimes use a flow) which need the DT to > > > come from a prior stage. How to handle that? IMO that is only going to > > > grow as every man and his dog get into the write-a-bootloader > > > business. We need a way to provide the U-Boot nodes/properties in a > > > form that the prior stage can consume and integrate with its build > > > system. Is TF-A the only thing being discussed here? If so, let's just > > > do it. We have the u-boot.dtsi and we can use binman to put the image > > > together, for example. Or we can get clever and create some sort of > > > overlay dtb. > > > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > > then it will need to build it in and use two devicetrees, one internal > > > and one from the prior stage....well that is not very efficient and it > > > is going to be confusing for people to figure out what U-Boot is > > > actually doing. But we actually already do that in a lot of cases > > > where U-Boot passes a DT to the kernel which is different to the one > > > it uses. So perhaps we have three devicetrees? OMG. b) Well then > > > U-Boot can have its own small devicetree with its bits and then U-Boot > > > can merge the two when it starts. Again that is not very efficient. > > Does not need to merge the two. hence it does not have any influence on > efficiency. > For properties access, trusted firmware has defined an abstract way to get > them: > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html That's interesting, but I also think fconf_load_config(), etc are the efficiency and additional overhead Simon is talking about being worried about. > The properties are currently implemented as DT but TF.ORG could decide to > move to CBOR. > The API will remain so that a change in backend will not influence existing > code. > I think you are too focused on "THE" device tree. "THE" device tree that is > passed to the OS > shall be hardware description and not a hacky place to fit any piece of > metadata. No, but it is the place to put well defined metadata. > I would argue that /chosen shall not even be there as most if not all > information can be passed as OS command line. And actually for the UEFI > contract, /chosen should go empty. Shoving a bunch of stuff to the kernel command line sounds pretty hacky to me. But I'll just assume it's already been given the official Not Hacky stamp of approval since after all, there's not a long standing cleaner path to do anything like that on x86, and we must all mirror the x86 world. > > It > > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > > its public key from there or to enable/disable the console), so > > > unified firmware config is not possible. It will get very confusing, > > > particularly for debugging U-Boot. c) Some other scheme to avoid > > > accepting step 3...please stop! > > > > How the nodes should get there is how the rest of the nodes in a system > > get there. Bindings are submitted and reviewed. The authoritative > > source of the dtses in question then has them, like any other property. > > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > > whole cloth. What about that? Well, we are just going to have to deal > > > with that. We can easily merge in the U-Boot nodes/properties and > > > update the U-Boot CI scripts to do this, as needed, e.g. with > > > qemu-riscv64_spl. It's only one use case, although Xen might do > > > something similar. > > > > > > To my mind, that deals with both the build-time and run-time issues. > > > We have a discoverable DT in U-Boot, which should be considered the > > > source of truth for most boards. We can sync it with Linux > > > automatically with the tooling that I hope Rob Herring will come up > > > with. We can use an empty one where there really is no default, > > > although I'd argue that is making perfect an enemy of the good. > > > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > > and pick them up from somewhere else, we can do that with sufficient > > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > > > For SystemReady compliant boards, this has to come much faster. > Do you think distros will keep providing DTs for ever? I bet not. Since it seems like it'll be a long time before people stop producing SBCs that lack on-board flash storage for the world firmware, yeah, I don't know when distributions will stop shipping DTBs. Maybe a year or two after the last popular SBC comes out and distros are comfortable shoving people that have that hardware off to some other community to support?
On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote: [snip] > One passed to U-Boot for fixups and further passed to the OS. This > devicetree may originate from a prior boot stage, from a file loaded by > U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command. I assume systemd-boot is implementing the same logic that extlinux.conf has used for forever, yes? > This devicetree will not contain any U-Boot specific information. To repeat, it must only have official bindings, yes, regardless of what project they come from.
On 10/27/21 16:55, Tom Rini wrote: > On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote: > > [snip] >> One passed to U-Boot for fixups and further passed to the OS. This >> devicetree may originate from a prior boot stage, from a file loaded by >> U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command. > > I assume systemd-boot is implementing the same logic that extlinux.conf > has used for forever, yes? It is loading the file and then calls U-Boot's implementation of the EFI Device Tree Fixup Protocol for fixups before passing the device-tree to the OS. > >> This devicetree will not contain any U-Boot specific information. > > To repeat, it must only have official bindings, yes, regardless of what > project they come from. > Don't expect prior firmware stages to provide any U-Boot specific stuff whatever official or non-official U-Boot specific bindings exist. Best regards Heinrich
> From: François Ozog <francois.ozog@linaro.org> > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > Hi, > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > Hi all, > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > Hi François, > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> > > a écrit : > > > > > > > >> > > > > > > > >> Hi Tom, Bin,François, > > > > > > > >> > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> > > wrote: > > > > > > > >> > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > > > >> > > Hi Simon, > > > > > > > >> > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > sjg@chromium.org> wrote: > > > > > > > >> > > > > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > OF_HOSTFILE so > > > > > > > >> > > > there are only three ways to obtain a devicetree: > > > > > > > >> > > > > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the devicetree > > is built and > > > > > > > >> > > > appended to U-Boot > > > > > > > >> > > > - OF_EMBED - for development purposes, the > > devicetree is embedded in > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > >> > > > - OF_BOARD - the board figures it out on its own > > > > > > > >> > > > > > > > > > > >> > > > The last one is currently set up so that no devicetree > > is needed at all > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, but > > some don't. Some > > > > > > > >> > > > don't even provide instructions on how to boot on the > > board. > > > > > > > >> > > > > > > > > > > >> > > > The problems with this approach are documented at [1]. > > > > > > > >> > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > > OF_SEPARATE. Any board > > > > > > > >> > > > can obtain its devicetree at runtime, even it is has a > > devicetree built > > > > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage > > bootloader and its > > > > > > > >> > > > caller may have a better idea about the hardware > > available in the machine. > > > > > > > >> > > > This is the case with a few QEMU boards, for example. > > > > > > > >> > > > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > should be an > > > > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > >> > > > > > > > > > > >> > > > This series makes this change, adding various missing > > devicetree files > > > > > > > >> > > > (and placeholders) to make the build work. > > > > > > > >> > > > > > > > > > >> > > Adding device trees that are never used sounds like a > > hack to me. > > > > > > > >> > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > > based on > > > > > > > >> > > command line parameters, and the device tree you put in > > this series > > > > > > > >> > > has various hardcoded <phandle> values which normally do > > not show up > > > > > > > >> > > in hand-written dts files. > > > > > > > >> > > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > > >> > > > > > > > > >> > I am also confused and do not like the idea of adding > > device trees for > > > > > > > >> > platforms that are capable of and can / do have a device > > tree to give us > > > > > > > >> > at run time. > > > > > > > >> > > > > > > > >> (I'll just reply to this one email, since the same points > > applies to > > > > > > > >> all replies I think) > > > > > > > >> > > > > > > > >> I have been thinking about this and discussing it with people > > for a > > > > > > > >> few months now. I've been signalling a change like this for > > over a > > > > > > > >> month now, on U-Boot contributor calls and in discussions > > with Linaro > > > > > > > >> people. I sent a patch (below) to try to explain things. I > > hope it is > > > > > > > >> not a surprise! > > > > > > > >> > > > > > > > >> The issue here is that we need a devicetree in-tree in > > U-Boot, to > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, > > OF_BOARD, > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. > > Between > > > > > > > >> Ilias' series and this one we can get ourselves on a stronger > > footing. > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF > > use. > > > > > > > >> For more context: > > > > > > > >> > > > > > > > >> > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > >> > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of > > adding the > > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > > > > >> maintainer would prefer there was no special support even for > > booting > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > >> > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > >> think the path forward might be to run QEMU twice, once to > > get its > > > > > > > >> generated tree and once to give the 'merged' tree with the > > U-Boot > > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > > >> > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > option, not a > > > > > > > >> build-time one. It creates all sorts of problems and > > obscurity which > > > > > > > >> have taken months to unpick. See the above patch for the > > rationale. > > > > > > > >> > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option > > available to > > > > > > > >> any board. At some point in the future it may become a common > > way > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > > devicetree > > > > > > > >> to it. It doesn't make any sense to have people decide > > whether or not > > > > > > > >> to set OF_BOARD at build time, thus affecting how the image > > is put > > > > > > > >> together. We'll end up with different U-Boot build targets > > like > > > > > > > >> capricorn, capricorn_of_board and the like. It should be > > obvious where > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly > > used > > > > > > > >> option, perhaps enabled by most/all boards, so that this sort > > of build > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > If you mean that when boards are by construction providing a > > DTB to U-Boot then I agree very much. But I don’t understand how the patch > > set supports it as it puts dts files for those boards to be built. > > > > > > > >> > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > >> function correctly in whatever runtime environment in which > > it finds > > > > > > > >> itself. > > > > > > > >> > > > > > > > >> Also as binman is pressed into service more and more to build > > the > > > > > > > >> complex firmware images that are becoming fashionable, it > > needs a > > > > > > > >> definition (in the devicetree) that describes how to create > > the image. > > > > > > > >> We can't support that unless we are building a devicetree, > > nor can the > > > > > > > >> running program access the image layout without that > > information. > > > > > > > >> > > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > > >> germane...but of course I am not suggesting doing that, since > > OF_BOARD > > > > > > > >> is, still, enabled. We already use OF_BOARD for various > > boards that > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for > > example > > > > > > > >> (as I said in the cover letter "Most boards do provide one, > > but some > > > > > > > >> don't."). So this series is just completing the picture by > > enforcing > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > > > > > > > I think the key point that will get you closer to where I am on > > this > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > present it > > > > > > > has build-time effects and this is quite wrong. If you go > > through all > > > > > > > the material I have written on this I think I have motivated > > that very > > > > > > > clearly. > > > > > > > > > > > > > > Another big issue is that I believe we need ONE devicetree for > > U-Boot, > > > > > > > not two that get merged by U-Boot. Again I have gone through > > that in a > > > > > > > lot of detail. > > > > > > > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > > > > here's the biggest sticking point. To be clear, you agree that > > U-Boot > > > > > > needs to support being passed a device tree to use, at run time, > > yes? > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > > > > > > > Not at runtime. > > > > > > > > OK. > > > > > > > > > > So is the sticking point here that we really have two classes of > > > > > > devices, one class where we will never ever be given the device > > tree at > > > > > > run time (think BeagleBone Black) and one where we will always be > > given > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > I'm not sure it will be that black and white. I suspect there will be > > > > > (many) boards which can boot happily with the U-Boot devicetree but > > > > > can also accept one at runtime, if provided. For example, you may > > want > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > I'm not sure I see the value in making this a gray area. There's very > > > > much a class of "never" boards. There's also the class of "can" today. > > > > Maybe as part of a developer iterative flow it would be nice to not > > have > > > > to re-flash the prior stage to change a DT, and just do it in U-Boot > > > > until things are happy, but I'm not sure what the use case is for > > > > overriding the previous stage. > > > > > > > > Especially since the pushback on this series I think has all been "why > > > > are we copying in a tree to build with? We don't want to use it at run > > > > time!". And then softer push back like "Well, U-Boot says we have to > > > > include the device tree file here, but we won't use it...". > > > > > > See below. > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > inadvertently) > > > > > provided a way to entirely omit a devicetree from U-Boot, thus making > > > > > things like binman and U-Boot /config impossible, for example. So I > > > > > want to claw that back, so there is always some sort of devicetree in > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > I really want to see what the binary case looks like since we could > > then > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > functionally correct from the hardware/our caller. > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > > use the device tree from build time at run time, ignoring the device > > > > tree provided to us at run time by the caller. > > > > > > Firstly I should say that I find building firmware very messy and > > > confusing these days. Lots of things to build and it's hard to find > > > the instructions. It doesn't have to be that way, but if we carry on > > > as we are, it will continue to be messy and in five years you will > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > objective here is to simplify things, bringing some consistency to the > > > different components. Binman was one effort there. I feel that putting > > > at least the U-Boot house in order, in my role as devicetree > > > maintainer (and as author of devicetree support in U-Boot back in > > > 2011), is the next step. > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > > that know where to grab other known-good binaries of varying licenses > > that are needed to assemble something that boots. > > > > > If we set things up correctly and agree on the bindings, devicetree > > > can be the unifying configuration mechanism through the whole of > > > firmware (except for very early bits) and into the OS, this will set > > > us up very well to deal with the complexity that is coming. > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > two months: > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > have its own nodes/properties in the DT. > > In my view U-Boot shall be able to leverage device tree format (source and > binary) to store its own data. > When you say "the" DT, I always think this is "the" DT that is passed to OS > and in "that" DT, there should be no U-Boot entries. Why not? As long as the device tree validates, it is perfectly fine to have additional nodes and properties present. The propertiesand nodes will be simply ignored by the OS. OpenBSD will print: "binman" not configured for the binman node that some of the U-Boot board targets now have, but it doesn't really make a difference. If there is a proper binding for that node, I could simply filter it out. Or we have U-Boot filter it out before the DT gets passed along like Tom suggests.
Hi Mark, On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > From: François Ozog <francois.ozog@linaro.org> > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > Hi, > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > Hi all, > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > > Hi François, > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> > > > a écrit : > > > > > > > > >> > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > >> > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> > > > wrote: > > > > > > > > >> > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > > > > >> > > Hi Simon, > > > > > > > > >> > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > > sjg@chromium.org> wrote: > > > > > > > > >> > > > > > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > OF_HOSTFILE so > > > > > > > > >> > > > there are only three ways to obtain a devicetree: > > > > > > > > >> > > > > > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the devicetree > > > is built and > > > > > > > > >> > > > appended to U-Boot > > > > > > > > >> > > > - OF_EMBED - for development purposes, the > > > devicetree is embedded in > > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > > >> > > > - OF_BOARD - the board figures it out on its own > > > > > > > > >> > > > > > > > > > > > >> > > > The last one is currently set up so that no devicetree > > > is needed at all > > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, but > > > some don't. Some > > > > > > > > >> > > > don't even provide instructions on how to boot on the > > > board. > > > > > > > > >> > > > > > > > > > > > >> > > > The problems with this approach are documented at [1]. > > > > > > > > >> > > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > > > OF_SEPARATE. Any board > > > > > > > > >> > > > can obtain its devicetree at runtime, even it is has a > > > devicetree built > > > > > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage > > > bootloader and its > > > > > > > > >> > > > caller may have a better idea about the hardware > > > available in the machine. > > > > > > > > >> > > > This is the case with a few QEMU boards, for example. > > > > > > > > >> > > > > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > > should be an > > > > > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > >> > > > > > > > > > > > >> > > > This series makes this change, adding various missing > > > devicetree files > > > > > > > > >> > > > (and placeholders) to make the build work. > > > > > > > > >> > > > > > > > > > > >> > > Adding device trees that are never used sounds like a > > > hack to me. > > > > > > > > >> > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > > > based on > > > > > > > > >> > > command line parameters, and the device tree you put in > > > this series > > > > > > > > >> > > has various hardcoded <phandle> values which normally do > > > not show up > > > > > > > > >> > > in hand-written dts files. > > > > > > > > >> > > > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > > > >> > > > > > > > > > >> > I am also confused and do not like the idea of adding > > > device trees for > > > > > > > > >> > platforms that are capable of and can / do have a device > > > tree to give us > > > > > > > > >> > at run time. > > > > > > > > >> > > > > > > > > >> (I'll just reply to this one email, since the same points > > > applies to > > > > > > > > >> all replies I think) > > > > > > > > >> > > > > > > > > >> I have been thinking about this and discussing it with people > > > for a > > > > > > > > >> few months now. I've been signalling a change like this for > > > over a > > > > > > > > >> month now, on U-Boot contributor calls and in discussions > > > with Linaro > > > > > > > > >> people. I sent a patch (below) to try to explain things. I > > > hope it is > > > > > > > > >> not a surprise! > > > > > > > > >> > > > > > > > > >> The issue here is that we need a devicetree in-tree in > > > U-Boot, to > > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, > > > OF_BOARD, > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. > > > Between > > > > > > > > >> Ilias' series and this one we can get ourselves on a stronger > > > footing. > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF > > > use. > > > > > > > > >> For more context: > > > > > > > > >> > > > > > > > > >> > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > >> > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of > > > adding the > > > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > > > > > >> maintainer would prefer there was no special support even for > > > booting > > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > > >> > > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > > >> think the path forward might be to run QEMU twice, once to > > > get its > > > > > > > > >> generated tree and once to give the 'merged' tree with the > > > U-Boot > > > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > > > >> > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > > option, not a > > > > > > > > >> build-time one. It creates all sorts of problems and > > > obscurity which > > > > > > > > >> have taken months to unpick. See the above patch for the > > > rationale. > > > > > > > > >> > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option > > > available to > > > > > > > > >> any board. At some point in the future it may become a common > > > way > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > > > devicetree > > > > > > > > >> to it. It doesn't make any sense to have people decide > > > whether or not > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the image > > > is put > > > > > > > > >> together. We'll end up with different U-Boot build targets > > > like > > > > > > > > >> capricorn, capricorn_of_board and the like. It should be > > > obvious where > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly > > > used > > > > > > > > >> option, perhaps enabled by most/all boards, so that this sort > > > of build > > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > > > If you mean that when boards are by construction providing a > > > DTB to U-Boot then I agree very much. But I don’t understand how the patch > > > set supports it as it puts dts files for those boards to be built. > > > > > > > > >> > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > >> function correctly in whatever runtime environment in which > > > it finds > > > > > > > > >> itself. > > > > > > > > >> > > > > > > > > >> Also as binman is pressed into service more and more to build > > > the > > > > > > > > >> complex firmware images that are becoming fashionable, it > > > needs a > > > > > > > > >> definition (in the devicetree) that describes how to create > > > the image. > > > > > > > > >> We can't support that unless we are building a devicetree, > > > nor can the > > > > > > > > >> running program access the image layout without that > > > information. > > > > > > > > >> > > > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > > > >> germane...but of course I am not suggesting doing that, since > > > OF_BOARD > > > > > > > > >> is, still, enabled. We already use OF_BOARD for various > > > boards that > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for > > > example > > > > > > > > >> (as I said in the cover letter "Most boards do provide one, > > > but some > > > > > > > > >> don't."). So this series is just completing the picture by > > > enforcing > > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > > > > > > > > > I think the key point that will get you closer to where I am on > > > this > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > > present it > > > > > > > > has build-time effects and this is quite wrong. If you go > > > through all > > > > > > > > the material I have written on this I think I have motivated > > > that very > > > > > > > > clearly. > > > > > > > > > > > > > > > > Another big issue is that I believe we need ONE devicetree for > > > U-Boot, > > > > > > > > not two that get merged by U-Boot. Again I have gone through > > > that in a > > > > > > > > lot of detail. > > > > > > > > > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > > > > > here's the biggest sticking point. To be clear, you agree that > > > U-Boot > > > > > > > needs to support being passed a device tree to use, at run time, > > > yes? > > > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > > > > > > > > > Not at runtime. > > > > > > > > > > OK. > > > > > > > > > > > > So is the sticking point here that we really have two classes of > > > > > > > devices, one class where we will never ever be given the device > > > tree at > > > > > > > run time (think BeagleBone Black) and one where we will always be > > > given > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect there will be > > > > > > (many) boards which can boot happily with the U-Boot devicetree but > > > > > > can also accept one at runtime, if provided. For example, you may > > > want > > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > > > I'm not sure I see the value in making this a gray area. There's very > > > > > much a class of "never" boards. There's also the class of "can" today. > > > > > Maybe as part of a developer iterative flow it would be nice to not > > > have > > > > > to re-flash the prior stage to change a DT, and just do it in U-Boot > > > > > until things are happy, but I'm not sure what the use case is for > > > > > overriding the previous stage. > > > > > > > > > > Especially since the pushback on this series I think has all been "why > > > > > are we copying in a tree to build with? We don't want to use it at run > > > > > time!". And then softer push back like "Well, U-Boot says we have to > > > > > include the device tree file here, but we won't use it...". > > > > > > > > See below. > > > > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > > inadvertently) > > > > > > provided a way to entirely omit a devicetree from U-Boot, thus making > > > > > > things like binman and U-Boot /config impossible, for example. So I > > > > > > want to claw that back, so there is always some sort of devicetree in > > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > > > I really want to see what the binary case looks like since we could > > > then > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > > > use the device tree from build time at run time, ignoring the device > > > > > tree provided to us at run time by the caller. > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > confusing these days. Lots of things to build and it's hard to find > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > as we are, it will continue to be messy and in five years you will > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > objective here is to simplify things, bringing some consistency to the > > > > different components. Binman was one effort there. I feel that putting > > > > at least the U-Boot house in order, in my role as devicetree > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > 2011), is the next step. > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > > > that know where to grab other known-good binaries of varying licenses > > > that are needed to assemble something that boots. > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > can be the unifying configuration mechanism through the whole of > > > > firmware (except for very early bits) and into the OS, this will set > > > > us up very well to deal with the complexity that is coming. > > > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > > two months: > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > have its own nodes/properties in the DT. > > > > In my view U-Boot shall be able to leverage device tree format (source and > > binary) to store its own data. > > When you say "the" DT, I always think this is "the" DT that is passed to OS > > and in "that" DT, there should be no U-Boot entries. > > Why not? As long as the device tree validates, it is perfectly fine > to have additional nodes and properties present. The propertiesand > nodes will be simply ignored by the OS. > > OpenBSD will print: > > "binman" not configured > > for the binman node that some of the U-Boot board targets now have, > but it doesn't really make a difference. If there is a proper binding > for that node, I could simply filter it out. Or we have U-Boot filter > it out before the DT gets passed along like Tom suggests. Just on that point, I believe the binman falls into the same bucket that Tom is talking about here, in that it should be a standard binding. Ideally I would like this to become a standard format so that anything in firmware can use it to find stuff. I believe it is a good and extensible way to describe the structure of firmware across all projects. Does "not configured" mean that it did not find the compatible string? We could add one of those, for now, perhaps. Regards, Simon
Hi Mark, On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > From: François Ozog <francois.ozog@linaro.org> > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > Hi, > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > Hi all, > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> > wrote: > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > > Hi François, > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > sjg@chromium.org> > > > a écrit : > > > > > > > > >> > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > >> > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > trini@konsulko.com> > > > wrote: > > > > > > > > >> > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > wrote: > > > > > > > > >> > > Hi Simon, > > > > > > > > >> > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > > sjg@chromium.org> wrote: > > > > > > > > >> > > > > > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE > and > > > OF_HOSTFILE so > > > > > > > > >> > > > there are only three ways to obtain a devicetree: > > > > > > > > >> > > > > > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the > devicetree > > > is built and > > > > > > > > >> > > > appended to U-Boot > > > > > > > > >> > > > - OF_EMBED - for development purposes, the > > > devicetree is embedded in > > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > > >> > > > - OF_BOARD - the board figures it out on its own > > > > > > > > >> > > > > > > > > > > > >> > > > The last one is currently set up so that no > devicetree > > > is needed at all > > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, but > > > some don't. Some > > > > > > > > >> > > > don't even provide instructions on how to boot on > the > > > board. > > > > > > > > >> > > > > > > > > > > > >> > > > The problems with this approach are documented at > [1]. > > > > > > > > >> > > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > > > OF_SEPARATE. Any board > > > > > > > > >> > > > can obtain its devicetree at runtime, even it is > has a > > > devicetree built > > > > > > > > >> > > > in U-Boot. This is because U-Boot may be a > second-stage > > > bootloader and its > > > > > > > > >> > > > caller may have a better idea about the hardware > > > available in the machine. > > > > > > > > >> > > > This is the case with a few QEMU boards, for > example. > > > > > > > > >> > > > > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a > 'choice'. It > > > should be an > > > > > > > > >> > > > option, available with either OF_SEPARATE or > OF_EMBED. > > > > > > > > >> > > > > > > > > > > > >> > > > This series makes this change, adding various > missing > > > devicetree files > > > > > > > > >> > > > (and placeholders) to make the build work. > > > > > > > > >> > > > > > > > > > > >> > > Adding device trees that are never used sounds like a > > > hack to me. > > > > > > > > >> > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the > fly > > > based on > > > > > > > > >> > > command line parameters, and the device tree you put > in > > > this series > > > > > > > > >> > > has various hardcoded <phandle> values which normally > do > > > not show up > > > > > > > > >> > > in hand-written dts files. > > > > > > > > >> > > > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > > > >> > > > > > > > > > >> > I am also confused and do not like the idea of adding > > > device trees for > > > > > > > > >> > platforms that are capable of and can / do have a device > > > tree to give us > > > > > > > > >> > at run time. > > > > > > > > >> > > > > > > > > >> (I'll just reply to this one email, since the same points > > > applies to > > > > > > > > >> all replies I think) > > > > > > > > >> > > > > > > > > >> I have been thinking about this and discussing it with > people > > > for a > > > > > > > > >> few months now. I've been signalling a change like this > for > > > over a > > > > > > > > >> month now, on U-Boot contributor calls and in discussions > > > with Linaro > > > > > > > > >> people. I sent a patch (below) to try to explain things. I > > > hope it is > > > > > > > > >> not a surprise! > > > > > > > > >> > > > > > > > > >> The issue here is that we need a devicetree in-tree in > > > U-Boot, to > > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, > > > OF_BOARD, > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. > > > Between > > > > > > > > >> Ilias' series and this one we can get ourselves on a > stronger > > > footing. > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF > > > use. > > > > > > > > >> For more context: > > > > > > > > >> > > > > > > > > >> > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > >> > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of > > > adding the > > > > > > > > >> u-boot.dtsi but there was not much interest there (in > fact the > > > > > > > > >> maintainer would prefer there was no special support even > for > > > booting > > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > > >> > > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > > >> think the path forward might be to run QEMU twice, once to > > > get its > > > > > > > > >> generated tree and once to give the 'merged' tree with the > > > U-Boot > > > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > > > >> > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > > option, not a > > > > > > > > >> build-time one. It creates all sorts of problems and > > > obscurity which > > > > > > > > >> have taken months to unpick. See the above patch for the > > > rationale. > > > > > > > > >> > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option > > > available to > > > > > > > > >> any board. At some point in the future it may become a > common > > > way > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > > > devicetree > > > > > > > > >> to it. It doesn't make any sense to have people decide > > > whether or not > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the > image > > > is put > > > > > > > > >> together. We'll end up with different U-Boot build targets > > > like > > > > > > > > >> capricorn, capricorn_of_board and the like. It should be > > > obvious where > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a > commonly > > > used > > > > > > > > >> option, perhaps enabled by most/all boards, so that this > sort > > > of build > > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > > > If you mean that when boards are by construction providing > a > > > DTB to U-Boot then I agree very much. But I don’t understand how the > patch > > > set supports it as it puts dts files for those boards to be built. > > > > > > > > >> > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > >> function correctly in whatever runtime environment in > which > > > it finds > > > > > > > > >> itself. > > > > > > > > >> > > > > > > > > >> Also as binman is pressed into service more and more to > build > > > the > > > > > > > > >> complex firmware images that are becoming fashionable, it > > > needs a > > > > > > > > >> definition (in the devicetree) that describes how to > create > > > the image. > > > > > > > > >> We can't support that unless we are building a devicetree, > > > nor can the > > > > > > > > >> running program access the image layout without that > > > information. > > > > > > > > >> > > > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > > > >> germane...but of course I am not suggesting doing that, > since > > > OF_BOARD > > > > > > > > >> is, still, enabled. We already use OF_BOARD for various > > > boards that > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, > for > > > example > > > > > > > > >> (as I said in the cover letter "Most boards do provide > one, > > > but some > > > > > > > > >> don't."). So this series is just completing the picture by > > > enforcing > > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the > default. > > > > > > > > > > > > > > > > I think the key point that will get you closer to where I am > on > > > this > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > > present it > > > > > > > > has build-time effects and this is quite wrong. If you go > > > through all > > > > > > > > the material I have written on this I think I have motivated > > > that very > > > > > > > > clearly. > > > > > > > > > > > > > > > > Another big issue is that I believe we need ONE devicetree > for > > > U-Boot, > > > > > > > > not two that get merged by U-Boot. Again I have gone through > > > that in a > > > > > > > > lot of detail. > > > > > > > > > > > > > > I have a long long reply to your first reply here saved, but, > maybe > > > > > > > here's the biggest sticking point. To be clear, you agree that > > > U-Boot > > > > > > > needs to support being passed a device tree to use, at run > time, > > > yes? > > > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we built > in? > > > > > > > > > > > > Not at runtime. > > > > > > > > > > OK. > > > > > > > > > > > > So is the sticking point here that we really have two classes > of > > > > > > > devices, one class where we will never ever be given the device > > > tree at > > > > > > > run time (think BeagleBone Black) and one where we will always > be > > > given > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect there > will be > > > > > > (many) boards which can boot happily with the U-Boot devicetree > but > > > > > > can also accept one at runtime, if provided. For example, you may > > > want > > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > > > I'm not sure I see the value in making this a gray area. There's > very > > > > > much a class of "never" boards. There's also the class of "can" > today. > > > > > Maybe as part of a developer iterative flow it would be nice to not > > > have > > > > > to re-flash the prior stage to change a DT, and just do it in > U-Boot > > > > > until things are happy, but I'm not sure what the use case is for > > > > > overriding the previous stage. > > > > > > > > > > Especially since the pushback on this series I think has all been > "why > > > > > are we copying in a tree to build with? We don't want to use it > at run > > > > > time!". And then softer push back like "Well, U-Boot says we have > to > > > > > include the device tree file here, but we won't use it...". > > > > > > > > See below. > > > > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > > inadvertently) > > > > > > provided a way to entirely omit a devicetree from U-Boot, thus > making > > > > > > things like binman and U-Boot /config impossible, for example. > So I > > > > > > want to claw that back, so there is always some sort of > devicetree in > > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > > > I really want to see what the binary case looks like since we could > > > then > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > could > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > don't > > > > > use the device tree from build time at run time, ignoring the > device > > > > > tree provided to us at run time by the caller. > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > confusing these days. Lots of things to build and it's hard to find > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > as we are, it will continue to be messy and in five years you will > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > objective here is to simplify things, bringing some consistency to > the > > > > different components. Binman was one effort there. I feel that > putting > > > > at least the U-Boot house in order, in my role as devicetree > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > 2011), is the next step. > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > > > that know where to grab other known-good binaries of varying licenses > > > that are needed to assemble something that boots. > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > can be the unifying configuration mechanism through the whole of > > > > firmware (except for very early bits) and into the OS, this will set > > > > us up very well to deal with the complexity that is coming. > > > > > > > > Anyway, here are the mental steps that I've gone through over the > past > > > > two months: > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > have its own nodes/properties in the DT. > > > > In my view U-Boot shall be able to leverage device tree format (source > and > > binary) to store its own data. > > When you say "the" DT, I always think this is "the" DT that is passed to > OS > > and in "that" DT, there should be no U-Boot entries. > > Why not? As long as the device tree validates, it is perfectly fine > to have additional nodes and properties present. The propertiesand > nodes will be simply ignored by the OS. > > Because of the way we want to organize the firmware supply chain: when the board is built, it is "attached" a device tree. At that moment, we don't know what "non trusted firmware" will be used. It could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2 (yes it works with DT). And we aim at keeping device tree as close to the original intent: hardware description only. It's not because we can stuff anything in the DT and that it is simple to do that we should. Driver parameters shall be in the OS facility built for that purpose. Using device tree has been an ugly habit. > OpenBSD will print: > > "binman" not configured > > for the binman node that some of the U-Boot board targets now have, > but it doesn't really make a difference. If there is a proper binding > for that node, I could simply filter it out. Or we have U-Boot filter > it out before the DT gets passed along like Tom suggests. >
On Wed, Oct 27, 2021 at 05:02:39PM +0200, Heinrich Schuchardt wrote: > On 10/27/21 16:55, Tom Rini wrote: > > On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote: > > > > [snip] > > > One passed to U-Boot for fixups and further passed to the OS. This > > > devicetree may originate from a prior boot stage, from a file loaded by > > > U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command. > > > > I assume systemd-boot is implementing the same logic that extlinux.conf > > has used for forever, yes? > > It is loading the file and then calls U-Boot's implementation of the EFI > Device Tree Fixup Protocol for fixups before passing the device-tree to the > OS. So it's using https://systemd.io/BOOT_LOADER_SPECIFICATION/ OK. > > > This devicetree will not contain any U-Boot specific information. > > > > To repeat, it must only have official bindings, yes, regardless of what > > project they come from. > > > > Don't expect prior firmware stages to provide any U-Boot specific stuff > whatever official or non-official U-Boot specific bindings exist. Failure to implement official bindings may result in failure to boot, which would be pretty silly.
On Wed, Oct 27, 2021 at 09:24:25AM -0600, Simon Glass wrote: > Hi Mark, > > On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > From: François Ozog <francois.ozog@linaro.org> > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > Hi, > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > Hi all, > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> > > > > a écrit : > > > > > > > > > >> > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > >> > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> > > > > wrote: > > > > > > > > > >> > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > > > > > >> > > Hi Simon, > > > > > > > > > >> > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > > > sjg@chromium.org> wrote: > > > > > > > > > >> > > > > > > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > OF_HOSTFILE so > > > > > > > > > >> > > > there are only three ways to obtain a devicetree: > > > > > > > > > >> > > > > > > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the devicetree > > > > is built and > > > > > > > > > >> > > > appended to U-Boot > > > > > > > > > >> > > > - OF_EMBED - for development purposes, the > > > > devicetree is embedded in > > > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > > > >> > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > >> > > > > > > > > > > > > >> > > > The last one is currently set up so that no devicetree > > > > is needed at all > > > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, but > > > > some don't. Some > > > > > > > > > >> > > > don't even provide instructions on how to boot on the > > > > board. > > > > > > > > > >> > > > > > > > > > > > > >> > > > The problems with this approach are documented at [1]. > > > > > > > > > >> > > > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > > > > OF_SEPARATE. Any board > > > > > > > > > >> > > > can obtain its devicetree at runtime, even it is has a > > > > devicetree built > > > > > > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage > > > > bootloader and its > > > > > > > > > >> > > > caller may have a better idea about the hardware > > > > available in the machine. > > > > > > > > > >> > > > This is the case with a few QEMU boards, for example. > > > > > > > > > >> > > > > > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > > > should be an > > > > > > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > >> > > > > > > > > > > > > >> > > > This series makes this change, adding various missing > > > > devicetree files > > > > > > > > > >> > > > (and placeholders) to make the build work. > > > > > > > > > >> > > > > > > > > > > > >> > > Adding device trees that are never used sounds like a > > > > hack to me. > > > > > > > > > >> > > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > > > > based on > > > > > > > > > >> > > command line parameters, and the device tree you put in > > > > this series > > > > > > > > > >> > > has various hardcoded <phandle> values which normally do > > > > not show up > > > > > > > > > >> > > in hand-written dts files. > > > > > > > > > >> > > > > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > > > > >> > > > > > > > > > > >> > I am also confused and do not like the idea of adding > > > > device trees for > > > > > > > > > >> > platforms that are capable of and can / do have a device > > > > tree to give us > > > > > > > > > >> > at run time. > > > > > > > > > >> > > > > > > > > > >> (I'll just reply to this one email, since the same points > > > > applies to > > > > > > > > > >> all replies I think) > > > > > > > > > >> > > > > > > > > > >> I have been thinking about this and discussing it with people > > > > for a > > > > > > > > > >> few months now. I've been signalling a change like this for > > > > over a > > > > > > > > > >> month now, on U-Boot contributor calls and in discussions > > > > with Linaro > > > > > > > > > >> people. I sent a patch (below) to try to explain things. I > > > > hope it is > > > > > > > > > >> not a surprise! > > > > > > > > > >> > > > > > > > > > >> The issue here is that we need a devicetree in-tree in > > > > U-Boot, to > > > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, > > > > OF_BOARD, > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. > > > > Between > > > > > > > > > >> Ilias' series and this one we can get ourselves on a stronger > > > > footing. > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF > > > > use. > > > > > > > > > >> For more context: > > > > > > > > > >> > > > > > > > > > >> > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > >> > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of > > > > adding the > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > > > > > > >> maintainer would prefer there was no special support even for > > > > booting > > > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > > > >> > > > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > > > >> think the path forward might be to run QEMU twice, once to > > > > get its > > > > > > > > > >> generated tree and once to give the 'merged' tree with the > > > > U-Boot > > > > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > > > > >> > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > > > option, not a > > > > > > > > > >> build-time one. It creates all sorts of problems and > > > > obscurity which > > > > > > > > > >> have taken months to unpick. See the above patch for the > > > > rationale. > > > > > > > > > >> > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option > > > > available to > > > > > > > > > >> any board. At some point in the future it may become a common > > > > way > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > > > > devicetree > > > > > > > > > >> to it. It doesn't make any sense to have people decide > > > > whether or not > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the image > > > > is put > > > > > > > > > >> together. We'll end up with different U-Boot build targets > > > > like > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should be > > > > obvious where > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly > > > > used > > > > > > > > > >> option, perhaps enabled by most/all boards, so that this sort > > > > of build > > > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > > > > > If you mean that when boards are by construction providing a > > > > DTB to U-Boot then I agree very much. But I don’t understand how the patch > > > > set supports it as it puts dts files for those boards to be built. > > > > > > > > > >> > > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > > >> function correctly in whatever runtime environment in which > > > > it finds > > > > > > > > > >> itself. > > > > > > > > > >> > > > > > > > > > >> Also as binman is pressed into service more and more to build > > > > the > > > > > > > > > >> complex firmware images that are becoming fashionable, it > > > > needs a > > > > > > > > > >> definition (in the devicetree) that describes how to create > > > > the image. > > > > > > > > > >> We can't support that unless we are building a devicetree, > > > > nor can the > > > > > > > > > >> running program access the image layout without that > > > > information. > > > > > > > > > >> > > > > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > > > > >> germane...but of course I am not suggesting doing that, since > > > > OF_BOARD > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for various > > > > boards that > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for > > > > example > > > > > > > > > >> (as I said in the cover letter "Most boards do provide one, > > > > but some > > > > > > > > > >> don't."). So this series is just completing the picture by > > > > enforcing > > > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default. > > > > > > > > > > > > > > > > > > I think the key point that will get you closer to where I am on > > > > this > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > > > present it > > > > > > > > > has build-time effects and this is quite wrong. If you go > > > > through all > > > > > > > > > the material I have written on this I think I have motivated > > > > that very > > > > > > > > > clearly. > > > > > > > > > > > > > > > > > > Another big issue is that I believe we need ONE devicetree for > > > > U-Boot, > > > > > > > > > not two that get merged by U-Boot. Again I have gone through > > > > that in a > > > > > > > > > lot of detail. > > > > > > > > > > > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > > > > > > here's the biggest sticking point. To be clear, you agree that > > > > U-Boot > > > > > > > > needs to support being passed a device tree to use, at run time, > > > > yes? > > > > > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > > > > > > > > > > > Not at runtime. > > > > > > > > > > > > OK. > > > > > > > > > > > > > > So is the sticking point here that we really have two classes of > > > > > > > > devices, one class where we will never ever be given the device > > > > tree at > > > > > > > > run time (think BeagleBone Black) and one where we will always be > > > > given > > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect there will be > > > > > > > (many) boards which can boot happily with the U-Boot devicetree but > > > > > > > can also accept one at runtime, if provided. For example, you may > > > > want > > > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > > > > > I'm not sure I see the value in making this a gray area. There's very > > > > > > much a class of "never" boards. There's also the class of "can" today. > > > > > > Maybe as part of a developer iterative flow it would be nice to not > > > > have > > > > > > to re-flash the prior stage to change a DT, and just do it in U-Boot > > > > > > until things are happy, but I'm not sure what the use case is for > > > > > > overriding the previous stage. > > > > > > > > > > > > Especially since the pushback on this series I think has all been "why > > > > > > are we copying in a tree to build with? We don't want to use it at run > > > > > > time!". And then softer push back like "Well, U-Boot says we have to > > > > > > include the device tree file here, but we won't use it...". > > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > > > inadvertently) > > > > > > > provided a way to entirely omit a devicetree from U-Boot, thus making > > > > > > > things like binman and U-Boot /config impossible, for example. So I > > > > > > > want to claw that back, so there is always some sort of devicetree in > > > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > > > > > I really want to see what the binary case looks like since we could > > > > then > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > > > > use the device tree from build time at run time, ignoring the device > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > confusing these days. Lots of things to build and it's hard to find > > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > > as we are, it will continue to be messy and in five years you will > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > objective here is to simplify things, bringing some consistency to the > > > > > different components. Binman was one effort there. I feel that putting > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > 2011), is the next step. > > > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > > > > that know where to grab other known-good binaries of varying licenses > > > > that are needed to assemble something that boots. > > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > > can be the unifying configuration mechanism through the whole of > > > > > firmware (except for very early bits) and into the OS, this will set > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > > > two months: > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > > have its own nodes/properties in the DT. > > > > > > In my view U-Boot shall be able to leverage device tree format (source and > > > binary) to store its own data. > > > When you say "the" DT, I always think this is "the" DT that is passed to OS > > > and in "that" DT, there should be no U-Boot entries. > > > > Why not? As long as the device tree validates, it is perfectly fine > > to have additional nodes and properties present. The propertiesand > > nodes will be simply ignored by the OS. > > > > OpenBSD will print: > > > > "binman" not configured > > > > for the binman node that some of the U-Boot board targets now have, > > but it doesn't really make a difference. If there is a proper binding > > for that node, I could simply filter it out. Or we have U-Boot filter > > it out before the DT gets passed along like Tom suggests. > > Just on that point, I believe the binman falls into the same bucket > that Tom is talking about here, in that it should be a standard > binding. Ideally I would like this to become a standard format so that > anything in firmware can use it to find stuff. I believe it is a good > and extensible way to describe the structure of firmware across all > projects. And at the risk of getting lost on specific details, if we look at: https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html it says "In the future, it may be provided as part of a device blob, along with the rest of the information about images to load." which is one of the things the binman node solves, so we should probably solve this problem once, for everyone rather than per-project.
Hi Tom Le mer. 27 oct. 2021 à 20:06, Tom Rini <trini@konsulko.com> a écrit : > On Wed, Oct 27, 2021 at 09:24:25AM -0600, Simon Glass wrote: > > Hi Mark, > > > > On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl> > wrote: > > > > > > > From: François Ozog <francois.ozog@linaro.org> > > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > > > Hi, > > > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > > Hi all, > > > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> > wrote: > > > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> > wrote: > > > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass > wrote: > > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > sjg@chromium.org> > > > > > a écrit : > > > > > > > > > > >> > > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > > >> > > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > trini@konsulko.com> > > > > > wrote: > > > > > > > > > > >> > > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > wrote: > > > > > > > > > > >> > > Hi Simon, > > > > > > > > > > >> > > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > > > > sjg@chromium.org> wrote: > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > With Ilias' efforts we have dropped > OF_PRIOR_STAGE and > > > > > OF_HOSTFILE so > > > > > > > > > > >> > > > there are only three ways to obtain a > devicetree: > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the > devicetree > > > > > is built and > > > > > > > > > > >> > > > appended to U-Boot > > > > > > > > > > >> > > > - OF_EMBED - for development purposes, the > > > > > devicetree is embedded in > > > > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > > > > >> > > > - OF_BOARD - the board figures it out on its > own > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > The last one is currently set up so that no > devicetree > > > > > is needed at all > > > > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, > but > > > > > some don't. Some > > > > > > > > > > >> > > > don't even provide instructions on how to boot > on the > > > > > board. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > The problems with this approach are documented > at [1]. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct > from > > > > > OF_SEPARATE. Any board > > > > > > > > > > >> > > > can obtain its devicetree at runtime, even it > is has a > > > > > devicetree built > > > > > > > > > > >> > > > in U-Boot. This is because U-Boot may be a > second-stage > > > > > bootloader and its > > > > > > > > > > >> > > > caller may have a better idea about the hardware > > > > > available in the machine. > > > > > > > > > > >> > > > This is the case with a few QEMU boards, for > example. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a > 'choice'. It > > > > > should be an > > > > > > > > > > >> > > > option, available with either OF_SEPARATE or > OF_EMBED. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > This series makes this change, adding various > missing > > > > > devicetree files > > > > > > > > > > >> > > > (and placeholders) to make the build work. > > > > > > > > > > >> > > > > > > > > > > > > >> > > Adding device trees that are never used sounds > like a > > > > > hack to me. > > > > > > > > > > >> > > > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on > the fly > > > > > based on > > > > > > > > > > >> > > command line parameters, and the device tree you > put in > > > > > this series > > > > > > > > > > >> > > has various hardcoded <phandle> values which > normally do > > > > > not show up > > > > > > > > > > >> > > in hand-written dts files. > > > > > > > > > > >> > > > > > > > > > > > > >> > > I am not sure I understand the whole point of > this. > > > > > > > > > > >> > > > > > > > > > > > >> > I am also confused and do not like the idea of > adding > > > > > device trees for > > > > > > > > > > >> > platforms that are capable of and can / do have a > device > > > > > tree to give us > > > > > > > > > > >> > at run time. > > > > > > > > > > >> > > > > > > > > > > >> (I'll just reply to this one email, since the same > points > > > > > applies to > > > > > > > > > > >> all replies I think) > > > > > > > > > > >> > > > > > > > > > > >> I have been thinking about this and discussing it > with people > > > > > for a > > > > > > > > > > >> few months now. I've been signalling a change like > this for > > > > > over a > > > > > > > > > > >> month now, on U-Boot contributor calls and in > discussions > > > > > with Linaro > > > > > > > > > > >> people. I sent a patch (below) to try to explain > things. I > > > > > hope it is > > > > > > > > > > >> not a surprise! > > > > > > > > > > >> > > > > > > > > > > >> The issue here is that we need a devicetree in-tree in > > > > > U-Boot, to > > > > > > > > > > >> avoid the mess that has been created by > OF_PRIOR_STAGE, > > > > > OF_BOARD, > > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, > OF_HOSTFILE. > > > > > Between > > > > > > > > > > >> Ilias' series and this one we can get ourselves on a > stronger > > > > > footing. > > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for > debugging/ELF > > > > > use. > > > > > > > > > > >> For more context: > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > >> > > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way > of > > > > > adding the > > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in > fact the > > > > > > > > > > >> maintainer would prefer there was no special support > even for > > > > > booting > > > > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > > > > >> > > > > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > > > > >> think the path forward might be to run QEMU twice, > once to > > > > > get its > > > > > > > > > > >> generated tree and once to give the 'merged' tree > with the > > > > > U-Boot > > > > > > > > > > >> properties in it, if people want to use U-Boot > features. > > > > > > > > > > >> > > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > > > > option, not a > > > > > > > > > > >> build-time one. It creates all sorts of problems and > > > > > obscurity which > > > > > > > > > > >> have taken months to unpick. See the above patch for > the > > > > > rationale. > > > > > > > > > > >> > > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an > option > > > > > available to > > > > > > > > > > >> any board. At some point in the future it may become > a common > > > > > way > > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and > providing a > > > > > devicetree > > > > > > > > > > >> to it. It doesn't make any sense to have people decide > > > > > whether or not > > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the > image > > > > > is put > > > > > > > > > > >> together. We'll end up with different U-Boot build > targets > > > > > like > > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should > be > > > > > obvious where > > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a > commonly > > > > > used > > > > > > > > > > >> option, perhaps enabled by most/all boards, so that > this sort > > > > > of build > > > > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > > > > > > > If you mean that when boards are by construction > providing a > > > > > DTB to U-Boot then I agree very much. But I don’t understand how > the patch > > > > > set supports it as it puts dts files for those boards to be built. > > > > > > > > > > >> > > > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > > > >> function correctly in whatever runtime environment in > which > > > > > it finds > > > > > > > > > > >> itself. > > > > > > > > > > >> > > > > > > > > > > >> Also as binman is pressed into service more and more > to build > > > > > the > > > > > > > > > > >> complex firmware images that are becoming > fashionable, it > > > > > needs a > > > > > > > > > > >> definition (in the devicetree) that describes how to > create > > > > > the image. > > > > > > > > > > >> We can't support that unless we are building a > devicetree, > > > > > nor can the > > > > > > > > > > >> running program access the image layout without that > > > > > information. > > > > > > > > > > >> > > > > > > > > > > >> François's point about 'don't use this with any > kernel' is > > > > > > > > > > >> germane...but of course I am not suggesting doing > that, since > > > > > OF_BOARD > > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for > various > > > > > boards that > > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and > 3, for > > > > > example > > > > > > > > > > >> (as I said in the cover letter "Most boards do > provide one, > > > > > but some > > > > > > > > > > >> don't."). So this series is just completing the > picture by > > > > > enforcing > > > > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the > default. > > > > > > > > > > > > > > > > > > > > I think the key point that will get you closer to where > I am on > > > > > this > > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > > > > present it > > > > > > > > > > has build-time effects and this is quite wrong. If you go > > > > > through all > > > > > > > > > > the material I have written on this I think I have > motivated > > > > > that very > > > > > > > > > > clearly. > > > > > > > > > > > > > > > > > > > > Another big issue is that I believe we need ONE > devicetree for > > > > > U-Boot, > > > > > > > > > > not two that get merged by U-Boot. Again I have gone > through > > > > > that in a > > > > > > > > > > lot of detail. > > > > > > > > > > > > > > > > > > I have a long long reply to your first reply here saved, > but, maybe > > > > > > > > > here's the biggest sticking point. To be clear, you agree > that > > > > > U-Boot > > > > > > > > > needs to support being passed a device tree to use, at run > time, > > > > > yes? > > > > > > > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we > built in? > > > > > > > > > > > > > > > > Not at runtime. > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > So is the sticking point here that we really have two > classes of > > > > > > > > > devices, one class where we will never ever be given the > device > > > > > tree at > > > > > > > > > run time (think BeagleBone Black) and one where we will > always be > > > > > given > > > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect > there will be > > > > > > > > (many) boards which can boot happily with the U-Boot > devicetree but > > > > > > > > can also accept one at runtime, if provided. For example, > you may > > > > > want > > > > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > > > > > > > I'm not sure I see the value in making this a gray area. > There's very > > > > > > > much a class of "never" boards. There's also the class of > "can" today. > > > > > > > Maybe as part of a developer iterative flow it would be nice > to not > > > > > have > > > > > > > to re-flash the prior stage to change a DT, and just do it in > U-Boot > > > > > > > until things are happy, but I'm not sure what the use case is > for > > > > > > > overriding the previous stage. > > > > > > > > > > > > > > Especially since the pushback on this series I think has all > been "why > > > > > > > are we copying in a tree to build with? We don't want to use > it at run > > > > > > > time!". And then softer push back like "Well, U-Boot says we > have to > > > > > > > include the device tree file here, but we won't use it...". > > > > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > > > > inadvertently) > > > > > > > > provided a way to entirely omit a devicetree from U-Boot, > thus making > > > > > > > > things like binman and U-Boot /config impossible, for > example. So I > > > > > > > > want to claw that back, so there is always some sort of > devicetree in > > > > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > > > > > > > I really want to see what the binary case looks like since we > could > > > > > then > > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > could > > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can > come > > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we > also don't > > > > > > > use the device tree from build time at run time, ignoring the > device > > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > > confusing these days. Lots of things to build and it's hard to > find > > > > > > the instructions. It doesn't have to be that way, but if we > carry on > > > > > > as we are, it will continue to be messy and in five years you > will > > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > > objective here is to simplify things, bringing some consistency > to the > > > > > > different components. Binman was one effort there. I feel that > putting > > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > > 2011), is the next step. > > > > > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh > scripts > > > > > that know where to grab other known-good binaries of varying > licenses > > > > > that are needed to assemble something that boots. > > > > > > > > > > > If we set things up correctly and agree on the bindings, > devicetree > > > > > > can be the unifying configuration mechanism through the whole of > > > > > > firmware (except for very early bits) and into the OS, this will > set > > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > > > Anyway, here are the mental steps that I've gone through over > the past > > > > > > two months: > > > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed > to > > > > > > have its own nodes/properties in the DT. > > > > > > > > In my view U-Boot shall be able to leverage device tree format > (source and > > > > binary) to store its own data. > > > > When you say "the" DT, I always think this is "the" DT that is > passed to OS > > > > and in "that" DT, there should be no U-Boot entries. > > > > > > Why not? As long as the device tree validates, it is perfectly fine > > > to have additional nodes and properties present. The propertiesand > > > nodes will be simply ignored by the OS. > > > > > > OpenBSD will print: > > > > > > "binman" not configured > > > > > > for the binman node that some of the U-Boot board targets now have, > > > but it doesn't really make a difference. If there is a proper binding > > > for that node, I could simply filter it out. Or we have U-Boot filter > > > it out before the DT gets passed along like Tom suggests. > > > > Just on that point, I believe the binman falls into the same bucket > > that Tom is talking about here, in that it should be a standard > > binding. Ideally I would like this to become a standard format so that > > anything in firmware can use it to find stuff. I believe it is a good > > and extensible way to describe the structure of firmware across all > > projects. > > And at the risk of getting lost on specific details, if we look at: > > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html > it says "In the future, it may be provided as part of a device blob, > along with the rest of the information about images to load." which is > one of the things the binman node solves, so we should probably solve > this problem once, for everyone rather than per-project. > i wish we could. We need RISC-V input here. > > -- > Tom >
On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote: > Hi Mark, > > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > From: François Ozog <francois.ozog@linaro.org> > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > Hi, > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > Hi all, > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> > > wrote: > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > > sjg@chromium.org> > > > > a écrit : > > > > > > > > > >> > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > >> > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > > trini@konsulko.com> > > > > wrote: > > > > > > > > > >> > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > > wrote: > > > > > > > > > >> > > Hi Simon, > > > > > > > > > >> > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > > > sjg@chromium.org> wrote: > > > > > > > > > >> > > > > > > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE > > and > > > > OF_HOSTFILE so > > > > > > > > > >> > > > there are only three ways to obtain a devicetree: > > > > > > > > > >> > > > > > > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the > > devicetree > > > > is built and > > > > > > > > > >> > > > appended to U-Boot > > > > > > > > > >> > > > - OF_EMBED - for development purposes, the > > > > devicetree is embedded in > > > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > > > >> > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > >> > > > > > > > > > > > > >> > > > The last one is currently set up so that no > > devicetree > > > > is needed at all > > > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, but > > > > some don't. Some > > > > > > > > > >> > > > don't even provide instructions on how to boot on > > the > > > > board. > > > > > > > > > >> > > > > > > > > > > > > >> > > > The problems with this approach are documented at > > [1]. > > > > > > > > > >> > > > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > > > > OF_SEPARATE. Any board > > > > > > > > > >> > > > can obtain its devicetree at runtime, even it is > > has a > > > > devicetree built > > > > > > > > > >> > > > in U-Boot. This is because U-Boot may be a > > second-stage > > > > bootloader and its > > > > > > > > > >> > > > caller may have a better idea about the hardware > > > > available in the machine. > > > > > > > > > >> > > > This is the case with a few QEMU boards, for > > example. > > > > > > > > > >> > > > > > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a > > 'choice'. It > > > > should be an > > > > > > > > > >> > > > option, available with either OF_SEPARATE or > > OF_EMBED. > > > > > > > > > >> > > > > > > > > > > > > >> > > > This series makes this change, adding various > > missing > > > > devicetree files > > > > > > > > > >> > > > (and placeholders) to make the build work. > > > > > > > > > >> > > > > > > > > > > > >> > > Adding device trees that are never used sounds like a > > > > hack to me. > > > > > > > > > >> > > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the > > fly > > > > based on > > > > > > > > > >> > > command line parameters, and the device tree you put > > in > > > > this series > > > > > > > > > >> > > has various hardcoded <phandle> values which normally > > do > > > > not show up > > > > > > > > > >> > > in hand-written dts files. > > > > > > > > > >> > > > > > > > > > > > >> > > I am not sure I understand the whole point of this. > > > > > > > > > >> > > > > > > > > > > >> > I am also confused and do not like the idea of adding > > > > device trees for > > > > > > > > > >> > platforms that are capable of and can / do have a device > > > > tree to give us > > > > > > > > > >> > at run time. > > > > > > > > > >> > > > > > > > > > >> (I'll just reply to this one email, since the same points > > > > applies to > > > > > > > > > >> all replies I think) > > > > > > > > > >> > > > > > > > > > >> I have been thinking about this and discussing it with > > people > > > > for a > > > > > > > > > >> few months now. I've been signalling a change like this > > for > > > > over a > > > > > > > > > >> month now, on U-Boot contributor calls and in discussions > > > > with Linaro > > > > > > > > > >> people. I sent a patch (below) to try to explain things. I > > > > hope it is > > > > > > > > > >> not a surprise! > > > > > > > > > >> > > > > > > > > > >> The issue here is that we need a devicetree in-tree in > > > > U-Boot, to > > > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, > > > > OF_BOARD, > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. > > > > Between > > > > > > > > > >> Ilias' series and this one we can get ourselves on a > > stronger > > > > footing. > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF > > > > use. > > > > > > > > > >> For more context: > > > > > > > > > >> > > > > > > > > > >> > > > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > >> > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of > > > > adding the > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in > > fact the > > > > > > > > > >> maintainer would prefer there was no special support even > > for > > > > booting > > > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > > > >> > > > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > > > >> think the path forward might be to run QEMU twice, once to > > > > get its > > > > > > > > > >> generated tree and once to give the 'merged' tree with the > > > > U-Boot > > > > > > > > > >> properties in it, if people want to use U-Boot features. > > > > > > > > > >> > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > > > option, not a > > > > > > > > > >> build-time one. It creates all sorts of problems and > > > > obscurity which > > > > > > > > > >> have taken months to unpick. See the above patch for the > > > > rationale. > > > > > > > > > >> > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option > > > > available to > > > > > > > > > >> any board. At some point in the future it may become a > > common > > > > way > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a > > > > devicetree > > > > > > > > > >> to it. It doesn't make any sense to have people decide > > > > whether or not > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the > > image > > > > is put > > > > > > > > > >> together. We'll end up with different U-Boot build targets > > > > like > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should be > > > > obvious where > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a > > commonly > > > > used > > > > > > > > > >> option, perhaps enabled by most/all boards, so that this > > sort > > > > of build > > > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > > > > > If you mean that when boards are by construction providing > > a > > > > DTB to U-Boot then I agree very much. But I don’t understand how the > > patch > > > > set supports it as it puts dts files for those boards to be built. > > > > > > > > > >> > > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > > >> function correctly in whatever runtime environment in > > which > > > > it finds > > > > > > > > > >> itself. > > > > > > > > > >> > > > > > > > > > >> Also as binman is pressed into service more and more to > > build > > > > the > > > > > > > > > >> complex firmware images that are becoming fashionable, it > > > > needs a > > > > > > > > > >> definition (in the devicetree) that describes how to > > create > > > > the image. > > > > > > > > > >> We can't support that unless we are building a devicetree, > > > > nor can the > > > > > > > > > >> running program access the image layout without that > > > > information. > > > > > > > > > >> > > > > > > > > > >> François's point about 'don't use this with any kernel' is > > > > > > > > > >> germane...but of course I am not suggesting doing that, > > since > > > > OF_BOARD > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for various > > > > boards that > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, > > for > > > > example > > > > > > > > > >> (as I said in the cover letter "Most boards do provide > > one, > > > > but some > > > > > > > > > >> don't."). So this series is just completing the picture by > > > > enforcing > > > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the > > default. > > > > > > > > > > > > > > > > > > I think the key point that will get you closer to where I am > > on > > > > this > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > > > present it > > > > > > > > > has build-time effects and this is quite wrong. If you go > > > > through all > > > > > > > > > the material I have written on this I think I have motivated > > > > that very > > > > > > > > > clearly. > > > > > > > > > > > > > > > > > > Another big issue is that I believe we need ONE devicetree > > for > > > > U-Boot, > > > > > > > > > not two that get merged by U-Boot. Again I have gone through > > > > that in a > > > > > > > > > lot of detail. > > > > > > > > > > > > > > > > I have a long long reply to your first reply here saved, but, > > maybe > > > > > > > > here's the biggest sticking point. To be clear, you agree that > > > > U-Boot > > > > > > > > needs to support being passed a device tree to use, at run > > time, > > > > yes? > > > > > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we built > > in? > > > > > > > > > > > > > > Not at runtime. > > > > > > > > > > > > OK. > > > > > > > > > > > > > > So is the sticking point here that we really have two classes > > of > > > > > > > > devices, one class where we will never ever be given the device > > > > tree at > > > > > > > > run time (think BeagleBone Black) and one where we will always > > be > > > > given > > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect there > > will be > > > > > > > (many) boards which can boot happily with the U-Boot devicetree > > but > > > > > > > can also accept one at runtime, if provided. For example, you may > > > > want > > > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > > > > > I'm not sure I see the value in making this a gray area. There's > > very > > > > > > much a class of "never" boards. There's also the class of "can" > > today. > > > > > > Maybe as part of a developer iterative flow it would be nice to not > > > > have > > > > > > to re-flash the prior stage to change a DT, and just do it in > > U-Boot > > > > > > until things are happy, but I'm not sure what the use case is for > > > > > > overriding the previous stage. > > > > > > > > > > > > Especially since the pushback on this series I think has all been > > "why > > > > > > are we copying in a tree to build with? We don't want to use it > > at run > > > > > > time!". And then softer push back like "Well, U-Boot says we have > > to > > > > > > include the device tree file here, but we won't use it...". > > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > > > inadvertently) > > > > > > > provided a way to entirely omit a devicetree from U-Boot, thus > > making > > > > > > > things like binman and U-Boot /config impossible, for example. > > So I > > > > > > > want to claw that back, so there is always some sort of > > devicetree in > > > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > > > > > I really want to see what the binary case looks like since we could > > > > then > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > > could > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > > don't > > > > > > use the device tree from build time at run time, ignoring the > > device > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > confusing these days. Lots of things to build and it's hard to find > > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > > as we are, it will continue to be messy and in five years you will > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > objective here is to simplify things, bringing some consistency to > > the > > > > > different components. Binman was one effort there. I feel that > > putting > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > 2011), is the next step. > > > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts > > > > that know where to grab other known-good binaries of varying licenses > > > > that are needed to assemble something that boots. > > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > > can be the unifying configuration mechanism through the whole of > > > > > firmware (except for very early bits) and into the OS, this will set > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the > > past > > > > > two months: > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > > have its own nodes/properties in the DT. > > > > > > In my view U-Boot shall be able to leverage device tree format (source > > and > > > binary) to store its own data. > > > When you say "the" DT, I always think this is "the" DT that is passed to > > OS > > > and in "that" DT, there should be no U-Boot entries. > > > > Why not? As long as the device tree validates, it is perfectly fine > > to have additional nodes and properties present. The propertiesand > > nodes will be simply ignored by the OS. > > Because of the way we want to organize the firmware supply chain: when the > board is built, it is "attached" a device tree. > At that moment, we don't know what "non trusted firmware" will be used. It > could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2 (yes > it works with DT). > And we aim at keeping device tree as close to the original intent: hardware > description only. It's not because we can stuff anything in the DT and that > it is simple to do that we should. > Driver parameters shall be in the OS facility built for that purpose. Using > device tree has been an ugly habit. So we're going to continue to re-litigate what does and doesn't live in the device tree for forever, aren't we? To continue to be clear, I'm not saying that non-upstream bindings should be present. But for example, Simon is working on the "U-Boot config node" binding, which is going to get re-spun next as /options/ as I read the thread right. Populate it and anyone can read it, and probably be getting information that's useful to U-Boot or LinuxBoot or EDK2 or anyone else. That's why I keep repeating that projects need to push bindings upstream. I'll repeat my comment about https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html and the binman node both noting a common problem to solve. In so far as there's objections to "U-Boot" nodes, it seems to me like it comes down to "shouldn't need U-Boot internals expressed in DT nor added to the DTB by someone else". And I've not objected to that either. But I think we do have a subset of "how do we express ..." issues that have come down to "well, we buried the bodies over at ... before". And it's time to dig them up and give them a proper burial perhaps now :)
> From: Simon Glass <sjg@chromium.org> > Date: Wed, 27 Oct 2021 09:24:25 -0600 > > Hi Mark, > > On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > From: François Ozog <francois.ozog@linaro.org> > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > In my view U-Boot shall be able to leverage device tree format > > > (source and binary) to store its own data. When you say "the" > > > DT, I always think this is "the" DT that is passed to OS and in > > > "that" DT, there should be no U-Boot entries. > > > > Why not? As long as the device tree validates, it is perfectly fine > > to have additional nodes and properties present. The propertiesand > > nodes will be simply ignored by the OS. > > > > OpenBSD will print: > > > > "binman" not configured > > > > for the binman node that some of the U-Boot board targets now have, > > but it doesn't really make a difference. If there is a proper binding > > for that node, I could simply filter it out. Or we have U-Boot filter > > it out before the DT gets passed along like Tom suggests. > > Just on that point, I believe the binman falls into the same bucket > that Tom is talking about here, in that it should be a standard > binding. Ideally I would like this to become a standard format so that > anything in firmware can use it to find stuff. I believe it is a good > and extensible way to describe the structure of firmware across all > projects. Oh, I agree that it is a reasonable thing to have a description of the structure of the firmware in the device tree. > Does "not configured" mean that it did not find the compatible string? > We could add one of those, for now, perhaps. "not configured" just means that no device driver attached to the node. Usually that is because we don't have a device driver for the device corresponding to the node yet. But in the case of the "binman" node it doesn't really make sense for a device driver to attach. In such a case we tend to filter out the node such that the "not configured" line isn't printed. That can be done either by name or by compatible string. So an "official" binding would help here and it should either use a standardized name (that shouldn't be used for other purposes then) or it should use defined a compatible string. Anyway, this is not really critical. I just brought it up to illustrate that such nodes are mostly harmless.
Hi Tom Le mer. 27 oct. 2021 à 21:06, Tom Rini <trini@konsulko.com> a écrit : > On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote: > > Hi Mark, > > > > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl> > wrote: > > > > > > From: François Ozog <francois.ozog@linaro.org> > > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > > > Hi, > > > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > > Hi all, > > > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> > wrote: > > > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> > > > wrote: > > > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass > wrote: > > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > > > sjg@chromium.org> > > > > > a écrit : > > > > > > > > > > >> > > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > > >> > > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > > > trini@konsulko.com> > > > > > wrote: > > > > > > > > > > >> > > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > > > wrote: > > > > > > > > > > >> > > Hi Simon, > > > > > > > > > > >> > > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > > > > sjg@chromium.org> wrote: > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > With Ilias' efforts we have dropped > OF_PRIOR_STAGE > > > and > > > > > OF_HOSTFILE so > > > > > > > > > > >> > > > there are only three ways to obtain a > devicetree: > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the > > > devicetree > > > > > is built and > > > > > > > > > > >> > > > appended to U-Boot > > > > > > > > > > >> > > > - OF_EMBED - for development purposes, the > > > > > devicetree is embedded in > > > > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > > > > >> > > > - OF_BOARD - the board figures it out on its > own > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > The last one is currently set up so that no > > > devicetree > > > > > is needed at all > > > > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, > but > > > > > some don't. Some > > > > > > > > > > >> > > > don't even provide instructions on how to boot > on > > > the > > > > > board. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > The problems with this approach are documented > at > > > [1]. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct > from > > > > > OF_SEPARATE. Any board > > > > > > > > > > >> > > > can obtain its devicetree at runtime, even it is > > > has a > > > > > devicetree built > > > > > > > > > > >> > > > in U-Boot. This is because U-Boot may be a > > > second-stage > > > > > bootloader and its > > > > > > > > > > >> > > > caller may have a better idea about the hardware > > > > > available in the machine. > > > > > > > > > > >> > > > This is the case with a few QEMU boards, for > > > example. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a > > > 'choice'. It > > > > > should be an > > > > > > > > > > >> > > > option, available with either OF_SEPARATE or > > > OF_EMBED. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > This series makes this change, adding various > > > missing > > > > > devicetree files > > > > > > > > > > >> > > > (and placeholders) to make the build work. > > > > > > > > > > >> > > > > > > > > > > > > >> > > Adding device trees that are never used sounds > like a > > > > > hack to me. > > > > > > > > > > >> > > > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on > the > > > fly > > > > > based on > > > > > > > > > > >> > > command line parameters, and the device tree you > put > > > in > > > > > this series > > > > > > > > > > >> > > has various hardcoded <phandle> values which > normally > > > do > > > > > not show up > > > > > > > > > > >> > > in hand-written dts files. > > > > > > > > > > >> > > > > > > > > > > > > >> > > I am not sure I understand the whole point of > this. > > > > > > > > > > >> > > > > > > > > > > > >> > I am also confused and do not like the idea of > adding > > > > > device trees for > > > > > > > > > > >> > platforms that are capable of and can / do have a > device > > > > > tree to give us > > > > > > > > > > >> > at run time. > > > > > > > > > > >> > > > > > > > > > > >> (I'll just reply to this one email, since the same > points > > > > > applies to > > > > > > > > > > >> all replies I think) > > > > > > > > > > >> > > > > > > > > > > >> I have been thinking about this and discussing it with > > > people > > > > > for a > > > > > > > > > > >> few months now. I've been signalling a change like > this > > > for > > > > > over a > > > > > > > > > > >> month now, on U-Boot contributor calls and in > discussions > > > > > with Linaro > > > > > > > > > > >> people. I sent a patch (below) to try to explain > things. I > > > > > hope it is > > > > > > > > > > >> not a surprise! > > > > > > > > > > >> > > > > > > > > > > >> The issue here is that we need a devicetree in-tree in > > > > > U-Boot, to > > > > > > > > > > >> avoid the mess that has been created by > OF_PRIOR_STAGE, > > > > > OF_BOARD, > > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, > OF_HOSTFILE. > > > > > Between > > > > > > > > > > >> Ilias' series and this one we can get ourselves on a > > > stronger > > > > > footing. > > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for > debugging/ELF > > > > > use. > > > > > > > > > > >> For more context: > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > >> > > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way > of > > > > > adding the > > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in > > > fact the > > > > > > > > > > >> maintainer would prefer there was no special support > even > > > for > > > > > booting > > > > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > > > > >> > > > > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > > > > >> think the path forward might be to run QEMU twice, > once to > > > > > get its > > > > > > > > > > >> generated tree and once to give the 'merged' tree > with the > > > > > U-Boot > > > > > > > > > > >> properties in it, if people want to use U-Boot > features. > > > > > > > > > > >> > > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > > > > option, not a > > > > > > > > > > >> build-time one. It creates all sorts of problems and > > > > > obscurity which > > > > > > > > > > >> have taken months to unpick. See the above patch for > the > > > > > rationale. > > > > > > > > > > >> > > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an > option > > > > > available to > > > > > > > > > > >> any board. At some point in the future it may become a > > > common > > > > > way > > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and > providing a > > > > > devicetree > > > > > > > > > > >> to it. It doesn't make any sense to have people decide > > > > > whether or not > > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the > > > image > > > > > is put > > > > > > > > > > >> together. We'll end up with different U-Boot build > targets > > > > > like > > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should > be > > > > > obvious where > > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a > > > commonly > > > > > used > > > > > > > > > > >> option, perhaps enabled by most/all boards, so that > this > > > sort > > > > > of build > > > > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > > > > > > > If you mean that when boards are by construction > providing > > > a > > > > > DTB to U-Boot then I agree very much. But I don’t understand how > the > > > patch > > > > > set supports it as it puts dts files for those boards to be built. > > > > > > > > > > >> > > > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > > > >> function correctly in whatever runtime environment in > > > which > > > > > it finds > > > > > > > > > > >> itself. > > > > > > > > > > >> > > > > > > > > > > >> Also as binman is pressed into service more and more > to > > > build > > > > > the > > > > > > > > > > >> complex firmware images that are becoming > fashionable, it > > > > > needs a > > > > > > > > > > >> definition (in the devicetree) that describes how to > > > create > > > > > the image. > > > > > > > > > > >> We can't support that unless we are building a > devicetree, > > > > > nor can the > > > > > > > > > > >> running program access the image layout without that > > > > > information. > > > > > > > > > > >> > > > > > > > > > > >> François's point about 'don't use this with any > kernel' is > > > > > > > > > > >> germane...but of course I am not suggesting doing > that, > > > since > > > > > OF_BOARD > > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for > various > > > > > boards that > > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and > 3, > > > for > > > > > example > > > > > > > > > > >> (as I said in the cover letter "Most boards do provide > > > one, > > > > > but some > > > > > > > > > > >> don't."). So this series is just completing the > picture by > > > > > enforcing > > > > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the > > > default. > > > > > > > > > > > > > > > > > > > > I think the key point that will get you closer to where > I am > > > on > > > > > this > > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > > > > present it > > > > > > > > > > has build-time effects and this is quite wrong. If you go > > > > > through all > > > > > > > > > > the material I have written on this I think I have > motivated > > > > > that very > > > > > > > > > > clearly. > > > > > > > > > > > > > > > > > > > > Another big issue is that I believe we need ONE > devicetree > > > for > > > > > U-Boot, > > > > > > > > > > not two that get merged by U-Boot. Again I have gone > through > > > > > that in a > > > > > > > > > > lot of detail. > > > > > > > > > > > > > > > > > > I have a long long reply to your first reply here saved, > but, > > > maybe > > > > > > > > > here's the biggest sticking point. To be clear, you agree > that > > > > > U-Boot > > > > > > > > > needs to support being passed a device tree to use, at run > > > time, > > > > > yes? > > > > > > > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we > built > > > in? > > > > > > > > > > > > > > > > Not at runtime. > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > So is the sticking point here that we really have two > classes > > > of > > > > > > > > > devices, one class where we will never ever be given the > device > > > > > tree at > > > > > > > > > run time (think BeagleBone Black) and one where we will > always > > > be > > > > > given > > > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect there > > > will be > > > > > > > > (many) boards which can boot happily with the U-Boot > devicetree > > > but > > > > > > > > can also accept one at runtime, if provided. For example, > you may > > > > > want > > > > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > > > > > > > I'm not sure I see the value in making this a gray area. > There's > > > very > > > > > > > much a class of "never" boards. There's also the class of > "can" > > > today. > > > > > > > Maybe as part of a developer iterative flow it would be nice > to not > > > > > have > > > > > > > to re-flash the prior stage to change a DT, and just do it in > > > U-Boot > > > > > > > until things are happy, but I'm not sure what the use case is > for > > > > > > > overriding the previous stage. > > > > > > > > > > > > > > Especially since the pushback on this series I think has all > been > > > "why > > > > > > > are we copying in a tree to build with? We don't want to use > it > > > at run > > > > > > > time!". And then softer push back like "Well, U-Boot says we > have > > > to > > > > > > > include the device tree file here, but we won't use it...". > > > > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > > > > inadvertently) > > > > > > > > provided a way to entirely omit a devicetree from U-Boot, > thus > > > making > > > > > > > > things like binman and U-Boot /config impossible, for > example. > > > So I > > > > > > > > want to claw that back, so there is always some sort of > > > devicetree in > > > > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > > > > > > > I really want to see what the binary case looks like since we > could > > > > > then > > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > > > could > > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can > come > > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we > also > > > don't > > > > > > > use the device tree from build time at run time, ignoring the > > > device > > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > > confusing these days. Lots of things to build and it's hard to > find > > > > > > the instructions. It doesn't have to be that way, but if we > carry on > > > > > > as we are, it will continue to be messy and in five years you > will > > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > > objective here is to simplify things, bringing some consistency > to > > > the > > > > > > different components. Binman was one effort there. I feel that > > > putting > > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > > 2011), is the next step. > > > > > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh > scripts > > > > > that know where to grab other known-good binaries of varying > licenses > > > > > that are needed to assemble something that boots. > > > > > > > > > > > If we set things up correctly and agree on the bindings, > devicetree > > > > > > can be the unifying configuration mechanism through the whole of > > > > > > firmware (except for very early bits) and into the OS, this will > set > > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the > > > past > > > > > > two months: > > > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed > to > > > > > > have its own nodes/properties in the DT. > > > > > > > > In my view U-Boot shall be able to leverage device tree format > (source > > > and > > > > binary) to store its own data. > > > > When you say "the" DT, I always think this is "the" DT that is > passed to > > > OS > > > > and in "that" DT, there should be no U-Boot entries. > > > > > > Why not? As long as the device tree validates, it is perfectly fine > > > to have additional nodes and properties present. The propertiesand > > > nodes will be simply ignored by the OS. > > > > Because of the way we want to organize the firmware supply chain: when > the > > board is built, it is "attached" a device tree. > > At that moment, we don't know what "non trusted firmware" will be used. > It > > could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2 > (yes > > it works with DT). > > And we aim at keeping device tree as close to the original intent: > hardware > > description only. It's not because we can stuff anything in the DT and > that > > it is simple to do that we should. > > Driver parameters shall be in the OS facility built for that purpose. > Using > > device tree has been an ugly habit. > > So we're going to continue to re-litigate what does and doesn't live in > the device tree for forever, aren't we? To continue to be clear, I'm > not saying that non-upstream bindings should be present. But for > example, Simon is working on the "U-Boot config node" binding, which is > going to get re-spun next as /options/ as I read the thread right. > Populate it and anyone can read it, and probably be getting information > that's useful to U-Boot or LinuxBoot or EDK2 or anyone else. That's why > I keep repeating that projects need to push bindings upstream. I'll > repeat my comment about > > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html > and the binman node both noting a common problem to solve. i think you are right. Now tfa is comfortable being its own upstream for the binding specifications. Could U-Boot community be comfortable doing so? Now I also recognize that DT specification state is far from clean. If you want full story on PCI ECAM you need Linux/documentation and IEEE text (kind of hosted on DT.org but not easily browasable to). In the long run it may be much better to have all bindings (including U-Boot ones) in DT.org. We should also have information from Qemu about the DT it generates for all its devices and how it is associated to command line . > > > In so far as there's objections to "U-Boot" nodes, it seems to me like > it comes down to "shouldn't need U-Boot internals expressed in DT nor > added to the DTB by someone else". And I've not objected to that > either. But I think we do have a subset of "how do we express ..." > issues that have come down to "well, we buried the bodies over at ... > before". And it's time to dig them up and give them a proper burial > perhaps now :) > > -- > Tom >
Hi Ilias, On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > Hi Simon, > > A bit late to the party, sorry! (Did you remember the beer? I am replying to this but I don't think it is all that helpful for me to reply to a lot of things on this thread, since I would not be adding much to my cover letter and patches) > > [...] > > > > > > > I really want to see what the binary case looks like since we could then > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > then also do a rpi_arm32_defconfig too. > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > functionally correct from the hardware/our caller. > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > use the device tree from build time at run time, ignoring the device > > > tree provided to us at run time by the caller. > > > > Firstly I should say that I find building firmware very messy and > > confusing these days. Lots of things to build and it's hard to find > > the instructions. It doesn't have to be that way, but if we carry on > > as we are, it will continue to be messy and in five years you will > > need a Ph.D and a lucky charm to boot on any modern board. My > > objective here is to simplify things, bringing some consistency to the > > different components. Binman was one effort there. I feel that putting > > at least the U-Boot house in order, in my role as devicetree > > maintainer (and as author of devicetree support in U-Boot back in > > 2011), is the next step. > > > > If we set things up correctly and agree on the bindings, devicetree > > can be the unifying configuration mechanism through the whole of > > firmware (except for very early bits) and into the OS, this will set > > us up very well to deal with the complexity that is coming. > > > > Anyway, here are the mental steps that I've gone through over the past > > two months: > > > > Step 1: At present, some people think U-Boot is not even allowed to > > have its own nodes/properties in the DT. It is an abuse of the > > devicetree standard, like the /chosen node but with less history. We > > should sacrifice efficiency, expedience and expandability on the altar > > of 'devicetree is a hardware description'. How do we get over that > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > for its own purposes, as well as for booting the OS. I am not saying > > it always has to have those properties, but with existing features > > like verified boot, SPL as well as complex firmware images where > > U-Boot needs to be able to find things in the image, it is essential. > > So let's just assume that we need this everywhere, since we certainly > > need it in at least some places. > > > > (stop reading here if you disagree, because nothing below will make > > any sense...you can still use U-Boot v2011.06 which doesn't have > > OF_CONTROL :-) > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > that to the DTs that are copied over from linux isn't imho. There are > various reasons for that. First of all syncing device trees is a huge pain > and that's probably one of the main reasons our DTs are out of sync for a > large number of boards. > The point is this was fine in 2011 were we had SPL only, but the reality > today is completely different. There's previous stage boot loaders (and > enough cases were vendors prefer those over SPL). If that bootloader needs > to use it's own device tree for whatever reason, imposing restrictions on > it wrt to the device tree it has to include, and require them to have > knowledge of U-Boot and it's internal config mechanism makes no sense not > to mention it doesn't scale at all. I think the solution here may be the binman image packer. It works from a description of the image (i.e. is data-driver) and can collect all the pieces together. The U-Boot properties (and the ones required by TF-A, etc.) can be added at package time. If you think about it, it doesn't matter what properties are in the DT that is put into the firmware image. TF-A, for example, is presumably reading a devicetree from flash, so what does it care if it has some U-Boot properties in it? As to syncing, we have solved this using u-boot.dtsi files in U-Boot, so I think this can be dealt with. > > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > have binman definitions, etc. So we need a way to overlay those things > > into the DT. We already support this for in-tree DTs, so IMO this is > > easy. Just require every board to have an in-tree DT. It helps with > > discoverability and documentation, anyway. That is this series. > > > > Again, the board might decide for it's own reason to provide it's own DT. > IMHO U-Boot must be able to cope with that and asking DTs to be included in > U-Boot source is not the right way to do that, not to mention cases were > that's completely unrealistic (e.g QEMU or a board that reads the DTB from > it's flash). I think you are at step 2. See above for my response. > > > (I think most of us are at the beginning of step 2, unsure about it > > and worried about step 3) > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > flow only, or boards that sometimes use a flow) which need the DT to > > come from a prior stage. How to handle that? IMO that is only going to > > grow as every man and his dog get into the write-a-bootloader > > business. > > And that's exactly why we have to come up with something that scales, without > having to add a bunch of unusable DTs in U-Boot. In what way does this not scale? How are the DTs unusable? If there is a standard binding, we should be fine. > > > We need a way to provide the U-Boot nodes/properties in a > > form that the prior stage can consume and integrate with its build > > system. Is TF-A the only thing being discussed here? If so, let's just > > do it. We have the u-boot.dtsi and we can use binman to put the image > > together, for example. Or we can get clever and create some sort of > > overlay dtb. > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > then it will need to build it in and use two devicetrees, one internal > > and one from the prior stage....well that is not very efficient and it > > is going to be confusing for people to figure out what U-Boot is > > actually doing. But we actually already do that in a lot of cases > > where U-Boot passes a DT to the kernel which is different to the one > > it uses. So perhaps we have three devicetrees? OMG. > > No we don't. That's a moot point. If you separate the DTs U-Boot > provides the internal one and inherits one 'generic'. Linux will be able to use > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the > DT across kernel versions, In which case there's not much you can do to > begin with and that's already a case we have to deal with. Linux actually doesn't care if the U-Boot properties are in the tree, so long as we have proper bindings. My point here is we only need either: a. one devicetree, shared with Linux and U-Boot (and TF-A?) b. two devicetrees, one for use in firmware and one for passing to Linux We don't need to separate out the U-Boot properties into a second (or third) devicetree. There just isn't any point. > > > b) Well then > > U-Boot can have its own small devicetree with its bits and then U-Boot > > can merge the two when it starts. Again that is not very efficient. It > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > its public key from there or to enable/disable the console), so > > unified firmware config is not possible. It will get very confusing, > > particularly for debugging U-Boot. c) Some other scheme to avoid > > accepting step 3...please stop! > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > whole cloth. What about that? Well, we are just going to have to deal > > with that. We can easily merge in the U-Boot nodes/properties and > > update the U-Boot CI scripts to do this, as needed, e.g. with > > qemu-riscv64_spl. It's only one use case, although Xen might do > > something similar. > > > > To my mind, that deals with both the build-time and run-time issues. > > We have a discoverable DT in U-Boot, which should be considered the > > source of truth for most boards. We can sync it with Linux > > automatically with the tooling that I hope Rob Herring will come up > > with. We can use an empty one where there really is no default, > > although I'd argue that is making perfect an enemy of the good. > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > and pick them up from somewhere else, we can do that with sufficient > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > We can start slowly migrating boards and see how that works out. > We could either use 2 device trees as you proposed, or have u-boot merge > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer > if linux gets handed a clean device tree without the u-boot internals in > it, so I think 2 discrete DTs is cleaner overall. I know you would prefer that, but does it really matter in practice? What is the objection, actually? As I mentioned on the call, I think the prior stage should do any merging or fixing up. Trying to do that sort of thing in 'early' code in U-Boot (or any other program, including Linux) is such a pain. With U-Boot, for example, we don't even have any RAM available to do it with half the time and it would dramatically increase the amount of memory needed prior to relocation. It just isn't a very good idea to try to do this in early code. It is also completely unnecessary, once you get past the philosophical objections. If TF-A wants to be in the picture, let it deal with the implications and responsibility thus incurred. TF-A has no right to tell U-Boot how to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter of the size of U-Boot. It duplicates loads of things in there. No one will even *notice* an FDT merge function, which is actually only 70 LOC: /** * overlay_apply_node - Merges a node into the base device tree * @fdt: Base Device Tree blob * @target: Node offset in the base device tree to apply the fragment to * @fdto: Device tree overlay blob * @node: Node offset in the overlay holding the changes to merge * * overlay_apply_node() merges a node into a target base device tree * node pointed. * * This is part of the final step in the device tree overlay * application process, when all the phandles have been adjusted and * resolved and you just have to merge overlay into the base device * tree. * * returns: * 0 on success * Negative error code on failure */ static int overlay_apply_node(void *fdt, int target, void *fdto, int node) { int property; int subnode; fdt_for_each_property_offset(property, fdto, node) { const char *name; const void *prop; int prop_len; int ret; prop = fdt_getprop_by_offset(fdto, property, &name, &prop_len); if (prop_len == -FDT_ERR_NOTFOUND) return -FDT_ERR_INTERNAL; if (prop_len < 0) return prop_len; ret = fdt_setprop(fdt, target, name, prop, prop_len); if (ret) return ret; } fdt_for_each_subnode(subnode, fdto, node) { const char *name = fdt_get_name(fdto, subnode, NULL); int nnode; int ret; nnode = fdt_add_subnode(fdt, target, name); if (nnode == -FDT_ERR_EXISTS) { nnode = fdt_subnode_offset(fdt, target, name); if (nnode == -FDT_ERR_NOTFOUND) return -FDT_ERR_INTERNAL; } if (nnode < 0) return nnode; ret = overlay_apply_node(fdt, nnode, fdto, subnode); if (ret) return ret; } return 0; } > > Regards > /Ilias > > > > To repeat, if we set things up correctly and agree on the bindings, > > devicetree can be the unifying configuration mechanism through the > > whole of firmware (except for very early bits) and into the OS. I feel > > this will set us up very well to deal with the complexity that is > > coming. > > Regards, Simon
Hi Simon, Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit : > Hi Ilias, > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > <ilias.apalodimas@linaro.org> wrote: > > > > Hi Simon, > > > > A bit late to the party, sorry! > > (Did you remember the beer? I am replying to this but I don't think it > is all that helpful for me to reply to a lot of things on this thread, > since I would not be adding much to my cover letter and patches) > > > > > [...] > > > > > > > > > > I really want to see what the binary case looks like since we could > then > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > functionally correct from the hardware/our caller. > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > don't > > > > use the device tree from build time at run time, ignoring the device > > > > tree provided to us at run time by the caller. > > > > > > Firstly I should say that I find building firmware very messy and > > > confusing these days. Lots of things to build and it's hard to find > > > the instructions. It doesn't have to be that way, but if we carry on > > > as we are, it will continue to be messy and in five years you will > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > objective here is to simplify things, bringing some consistency to the > > > different components. Binman was one effort there. I feel that putting > > > at least the U-Boot house in order, in my role as devicetree > > > maintainer (and as author of devicetree support in U-Boot back in > > > 2011), is the next step. > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > can be the unifying configuration mechanism through the whole of > > > firmware (except for very early bits) and into the OS, this will set > > > us up very well to deal with the complexity that is coming. > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > two months: > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > have its own nodes/properties in the DT. It is an abuse of the > > > devicetree standard, like the /chosen node but with less history. We > > > should sacrifice efficiency, expedience and expandability on the altar > > > of 'devicetree is a hardware description'. How do we get over that > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > for its own purposes, as well as for booting the OS. I am not saying > > > it always has to have those properties, but with existing features > > > like verified boot, SPL as well as complex firmware images where > > > U-Boot needs to be able to find things in the image, it is essential. > > > So let's just assume that we need this everywhere, since we certainly > > > need it in at least some places. > > > > > > (stop reading here if you disagree, because nothing below will make > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > OF_CONTROL :-) > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > that to the DTs that are copied over from linux isn't imho. There are > > various reasons for that. First of all syncing device trees is a huge > pain > > and that's probably one of the main reasons our DTs are out of sync for a > > large number of boards. > > The point is this was fine in 2011 were we had SPL only, but the reality > > today is completely different. There's previous stage boot loaders (and > > enough cases were vendors prefer those over SPL). If that bootloader > needs > > to use it's own device tree for whatever reason, imposing restrictions > on > > it wrt to the device tree it has to include, and require them to have > > knowledge of U-Boot and it's internal config mechanism makes no sense not > > to mention it doesn't scale at all. > > I think the solution here may be the binman image packer. It works > from a description of the image (i.e. is data-driver) and can collect > all the pieces together. The U-Boot properties (and the ones required > by TF-A, etc.) can be added at package time. > > If you think about it, it doesn't matter what properties are in the DT > that is put into the firmware image. TF-A, for example, is presumably > reading a devicetree from flash, so what does it care if it has some > U-Boot properties in it? I am going to change my position in all mail threads I participate. I was trying to make patches relevant in the future and conceptually clean. That may not be the most effective position: I should just care about Linaro and its members being able to implement SystemReady concepts. If you mandate U-Boot has nodes in the device tree passed to the OS, we can put DT fragment in the nt_fw_config section of the fip and merge it at boot time. So there is a solution compatible with SystemReady. If you want to put fake, non future proof, DT sources in the dts for platforms that are organized to provide the authoritative DT to U-Boot at runtime, that's kind of your choice (hopefully representing the rest of U-Boot community). There will be quirk code in U-Boot to redo the adaptations on its non authoritative DT that the platform previous stage firmware does (already saw one in the past month); as Mark said there will be issues over time; and it will confuse people about the role of the DT. But I am fine with it as it does not impair Linaro and its members ability to implement SystemReady way of handling DT. > > As to syncing, we have solved this using u-boot.dtsi files in U-Boot, > so I think this can be dealt with. > > > > > > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > have binman definitions, etc. So we need a way to overlay those things > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > easy. Just require every board to have an in-tree DT. It helps with > > > discoverability and documentation, anyway. That is this series. > > > > > > > Again, the board might decide for it's own reason to provide it's own DT. > > IMHO U-Boot must be able to cope with that and asking DTs to be included > in > > U-Boot source is not the right way to do that, not to mention cases were > > that's completely unrealistic (e.g QEMU or a board that reads the DTB > from > > it's flash). > > I think you are at step 2. See above for my response. > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > and worried about step 3) > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > flow only, or boards that sometimes use a flow) which need the DT to > > > come from a prior stage. How to handle that? IMO that is only going to > > > grow as every man and his dog get into the write-a-bootloader > > > business. > > > > And that's exactly why we have to come up with something that scales, > without > > having to add a bunch of unusable DTs in U-Boot. > > In what way does this not scale? How are the DTs unusable? If there is > a standard binding, we should be fine. > > > > > > We need a way to provide the U-Boot nodes/properties in a > > > form that the prior stage can consume and integrate with its build > > > system. Is TF-A the only thing being discussed here? If so, let's just > > > do it. We have the u-boot.dtsi and we can use binman to put the image > > > together, for example. Or we can get clever and create some sort of > > > overlay dtb. > > > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > > then it will need to build it in and use two devicetrees, one internal > > > and one from the prior stage....well that is not very efficient and it > > > is going to be confusing for people to figure out what U-Boot is > > > actually doing. But we actually already do that in a lot of cases > > > where U-Boot passes a DT to the kernel which is different to the one > > > it uses. So perhaps we have three devicetrees? OMG. > > > > No we don't. That's a moot point. If you separate the DTs U-Boot > > provides the internal one and inherits one 'generic'. Linux will be > able to use > > that. So the only case were you'll need 3 DTs is if the *vendor* breaks > the > > DT across kernel versions, In which case there's not much you can do to > > begin with and that's already a case we have to deal with. > > Linux actually doesn't care if the U-Boot properties are in the tree, > so long as we have proper bindings. My point here is we only need > either: > > a. one devicetree, shared with Linux and U-Boot (and TF-A?) > b. two devicetrees, one for use in firmware and one for passing to Linux > > We don't need to separate out the U-Boot properties into a second (or > third) devicetree. There just isn't any point. > > > > > > b) Well then > > > U-Boot can have its own small devicetree with its bits and then U-Boot > > > can merge the two when it starts. Again that is not very efficient. It > > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > > its public key from there or to enable/disable the console), so > > > unified firmware config is not possible. It will get very confusing, > > > particularly for debugging U-Boot. c) Some other scheme to avoid > > > accepting step 3...please stop! > > > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > > whole cloth. What about that? Well, we are just going to have to deal > > > with that. We can easily merge in the U-Boot nodes/properties and > > > update the U-Boot CI scripts to do this, as needed, e.g. with > > > qemu-riscv64_spl. It's only one use case, although Xen might do > > > something similar. > > > > > > To my mind, that deals with both the build-time and run-time issues. > > > We have a discoverable DT in U-Boot, which should be considered the > > > source of truth for most boards. We can sync it with Linux > > > automatically with the tooling that I hope Rob Herring will come up > > > with. We can use an empty one where there really is no default, > > > although I'd argue that is making perfect an enemy of the good. > > > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > > and pick them up from somewhere else, we can do that with sufficient > > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > > > We can start slowly migrating boards and see how that works out. > > We could either use 2 device trees as you proposed, or have u-boot merge > > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd > prefer > > if linux gets handed a clean device tree without the u-boot internals in > > it, so I think 2 discrete DTs is cleaner overall. > > I know you would prefer that, but does it really matter in practice? > What is the objection, actually? > > As I mentioned on the call, I think the prior stage should do any > merging or fixing up. Trying to do that sort of thing in 'early' code > in U-Boot (or any other program, including Linux) is such a pain. With > U-Boot, for example, we don't even have any RAM available to do it > with half the time and it would dramatically increase the amount of > memory needed prior to relocation. It just isn't a very good idea to > try to do this in early code. It is also completely unnecessary, once > you get past the philosophical objections. > > If TF-A wants to be in the picture, let it deal with the implications > and responsibility thus incurred. TF-A has no right to tell U-Boot how > to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter > of the size of U-Boot. It duplicates loads of things in there. No one > will even *notice* an FDT merge function, which is actually only 70 > LOC: > > /** > * overlay_apply_node - Merges a node into the base device tree > * @fdt: Base Device Tree blob > * @target: Node offset in the base device tree to apply the fragment to > * @fdto: Device tree overlay blob > * @node: Node offset in the overlay holding the changes to merge > * > * overlay_apply_node() merges a node into a target base device tree > * node pointed. > * > * This is part of the final step in the device tree overlay > * application process, when all the phandles have been adjusted and > * resolved and you just have to merge overlay into the base device > * tree. > * > * returns: > * 0 on success > * Negative error code on failure > */ > static int overlay_apply_node(void *fdt, int target, > void *fdto, int node) > { > int property; > int subnode; > > fdt_for_each_property_offset(property, fdto, node) { > const char *name; > const void *prop; > int prop_len; > int ret; > > prop = fdt_getprop_by_offset(fdto, property, &name, > &prop_len); > if (prop_len == -FDT_ERR_NOTFOUND) > return -FDT_ERR_INTERNAL; > if (prop_len < 0) > return prop_len; > > ret = fdt_setprop(fdt, target, name, prop, prop_len); > if (ret) > return ret; > } > > fdt_for_each_subnode(subnode, fdto, node) { > const char *name = fdt_get_name(fdto, subnode, NULL); > int nnode; > int ret; > > nnode = fdt_add_subnode(fdt, target, name); > if (nnode == -FDT_ERR_EXISTS) { > nnode = fdt_subnode_offset(fdt, target, name); > if (nnode == -FDT_ERR_NOTFOUND) > return -FDT_ERR_INTERNAL; > } > > if (nnode < 0) > return nnode; > > ret = overlay_apply_node(fdt, nnode, fdto, subnode); > if (ret) > return ret; > } > > return 0; > > > > } > > > > > > Regards > > /Ilias > > > > > > To repeat, if we set things up correctly and agree on the bindings, > > > devicetree can be the unifying configuration mechanism through the > > > whole of firmware (except for very early bits) and into the OS. I feel > > > this will set us up very well to deal with the complexity that is > > > coming. > > > > > Regards, > Simon >
Hi François, On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> wrote: > > Hi Simon, > > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit : >> >> Hi Ilias, >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas >> <ilias.apalodimas@linaro.org> wrote: >> > >> > Hi Simon, >> > >> > A bit late to the party, sorry! >> >> (Did you remember the beer? I am replying to this but I don't think it >> is all that helpful for me to reply to a lot of things on this thread, >> since I would not be adding much to my cover letter and patches) >> >> > >> > [...] >> > >> > > > >> > > > I really want to see what the binary case looks like since we could then >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could >> > > > then also do a rpi_arm32_defconfig too. >> > > > >> > > > I want to see less device trees in U-Boot sources, if they can come >> > > > functionally correct from the hardware/our caller. >> > > > >> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't >> > > > use the device tree from build time at run time, ignoring the device >> > > > tree provided to us at run time by the caller. >> > > >> > > Firstly I should say that I find building firmware very messy and >> > > confusing these days. Lots of things to build and it's hard to find >> > > the instructions. It doesn't have to be that way, but if we carry on >> > > as we are, it will continue to be messy and in five years you will >> > > need a Ph.D and a lucky charm to boot on any modern board. My >> > > objective here is to simplify things, bringing some consistency to the >> > > different components. Binman was one effort there. I feel that putting >> > > at least the U-Boot house in order, in my role as devicetree >> > > maintainer (and as author of devicetree support in U-Boot back in >> > > 2011), is the next step. >> > > >> > > If we set things up correctly and agree on the bindings, devicetree >> > > can be the unifying configuration mechanism through the whole of >> > > firmware (except for very early bits) and into the OS, this will set >> > > us up very well to deal with the complexity that is coming. >> > > >> > > Anyway, here are the mental steps that I've gone through over the past >> > > two months: >> > > >> > > Step 1: At present, some people think U-Boot is not even allowed to >> > > have its own nodes/properties in the DT. It is an abuse of the >> > > devicetree standard, like the /chosen node but with less history. We >> > > should sacrifice efficiency, expedience and expandability on the altar >> > > of 'devicetree is a hardware description'. How do we get over that >> > > one? Wel, I just think we need to accept that U-Boot uses devicetree >> > > for its own purposes, as well as for booting the OS. I am not saying >> > > it always has to have those properties, but with existing features >> > > like verified boot, SPL as well as complex firmware images where >> > > U-Boot needs to be able to find things in the image, it is essential. >> > > So let's just assume that we need this everywhere, since we certainly >> > > need it in at least some places. >> > > >> > > (stop reading here if you disagree, because nothing below will make >> > > any sense...you can still use U-Boot v2011.06 which doesn't have >> > > OF_CONTROL :-) >> > >> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding >> > that to the DTs that are copied over from linux isn't imho. There are >> > various reasons for that. First of all syncing device trees is a huge pain >> > and that's probably one of the main reasons our DTs are out of sync for a >> > large number of boards. >> > The point is this was fine in 2011 were we had SPL only, but the reality >> > today is completely different. There's previous stage boot loaders (and >> > enough cases were vendors prefer those over SPL). If that bootloader needs >> > to use it's own device tree for whatever reason, imposing restrictions on >> > it wrt to the device tree it has to include, and require them to have >> > knowledge of U-Boot and it's internal config mechanism makes no sense not >> > to mention it doesn't scale at all. >> >> I think the solution here may be the binman image packer. It works >> from a description of the image (i.e. is data-driver) and can collect >> all the pieces together. The U-Boot properties (and the ones required >> by TF-A, etc.) can be added at package time. >> >> If you think about it, it doesn't matter what properties are in the DT >> that is put into the firmware image. TF-A, for example, is presumably >> reading a devicetree from flash, so what does it care if it has some >> U-Boot properties in it? > > > I am going to change my position in all mail threads I participate. > I was trying to make patches relevant in the future and conceptually clean. That may not be the most effective position: I should just care about Linaro and its members being able to implement SystemReady concepts. > > > If you mandate U-Boot has nodes in the device tree passed to the OS, we can put DT fragment in the nt_fw_config section of the fip and merge it at boot time. So there is a solution compatible with SystemReady. > > If you want to put fake, non future proof, DT sources in the dts for platforms that are organized to provide the authoritative DT to U-Boot at runtime, that's kind of your choice (hopefully representing the rest of U-Boot community). There will be quirk code in U-Boot to redo the adaptations on its non authoritative DT that the platform previous stage firmware does (already saw one in the past month); as Mark said there will be issues over time; and it will confuse people about the role of the DT. But I am fine with it as it does not impair Linaro and its members ability to implement SystemReady way of handling DT. OK thank you. It doesn't sound like you are very on-board though. Also, you mischaracterise my intent with in-tree devicetrees. I would be happy enough for now if you could accept that U-Boot has nodes/properties of its own in the devicetree. It has been a feature of U-Boot for 10 years now. Regards, Simon > >> >> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot, >> so I think this can be dealt with. >> >> > >> > > >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we >> > > have binman definitions, etc. So we need a way to overlay those things >> > > into the DT. We already support this for in-tree DTs, so IMO this is >> > > easy. Just require every board to have an in-tree DT. It helps with >> > > discoverability and documentation, anyway. That is this series. >> > > >> > >> > Again, the board might decide for it's own reason to provide it's own DT. >> > IMHO U-Boot must be able to cope with that and asking DTs to be included in >> > U-Boot source is not the right way to do that, not to mention cases were >> > that's completely unrealistic (e.g QEMU or a board that reads the DTB from >> > it's flash). >> >> I think you are at step 2. See above for my response. >> >> > >> > > (I think most of us are at the beginning of step 2, unsure about it >> > > and worried about step 3) >> > > >> > > Step 3: Ah, but there are flows (i.e. boards that use a particular >> > > flow only, or boards that sometimes use a flow) which need the DT to >> > > come from a prior stage. How to handle that? IMO that is only going to >> > > grow as every man and his dog get into the write-a-bootloader >> > > business. >> > >> > And that's exactly why we have to come up with something that scales, without >> > having to add a bunch of unusable DTs in U-Boot. >> >> In what way does this not scale? How are the DTs unusable? If there is >> a standard binding, we should be fine. >> >> > >> > > We need a way to provide the U-Boot nodes/properties in a >> > > form that the prior stage can consume and integrate with its build >> > > system. Is TF-A the only thing being discussed here? If so, let's just >> > > do it. We have the u-boot.dtsi and we can use binman to put the image >> > > together, for example. Or we can get clever and create some sort of >> > > overlay dtb. >> > > >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff >> > > then it will need to build it in and use two devicetrees, one internal >> > > and one from the prior stage....well that is not very efficient and it >> > > is going to be confusing for people to figure out what U-Boot is >> > > actually doing. But we actually already do that in a lot of cases >> > > where U-Boot passes a DT to the kernel which is different to the one >> > > it uses. So perhaps we have three devicetrees? OMG. >> > >> > No we don't. That's a moot point. If you separate the DTs U-Boot >> > provides the internal one and inherits one 'generic'. Linux will be able to use >> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the >> > DT across kernel versions, In which case there's not much you can do to >> > begin with and that's already a case we have to deal with. >> >> Linux actually doesn't care if the U-Boot properties are in the tree, >> so long as we have proper bindings. My point here is we only need >> either: >> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?) >> b. two devicetrees, one for use in firmware and one for passing to Linux >> >> We don't need to separate out the U-Boot properties into a second (or >> third) devicetree. There just isn't any point. >> >> > >> > > b) Well then >> > > U-Boot can have its own small devicetree with its bits and then U-Boot >> > > can merge the two when it starts. Again that is not very efficient. It >> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get >> > > its public key from there or to enable/disable the console), so >> > > unified firmware config is not possible. It will get very confusing, >> > > particularly for debugging U-Boot. c) Some other scheme to avoid >> > > accepting step 3...please stop! >> > > >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of >> > > whole cloth. What about that? Well, we are just going to have to deal >> > > with that. We can easily merge in the U-Boot nodes/properties and >> > > update the U-Boot CI scripts to do this, as needed, e.g. with >> > > qemu-riscv64_spl. It's only one use case, although Xen might do >> > > something similar. >> > > >> > > To my mind, that deals with both the build-time and run-time issues. >> > > We have a discoverable DT in U-Boot, which should be considered the >> > > source of truth for most boards. We can sync it with Linux >> > > automatically with the tooling that I hope Rob Herring will come up >> > > with. We can use an empty one where there really is no default, >> > > although I'd argue that is making perfect an enemy of the good. >> > > >> > > Step 5: If we get clever and want to remove them from the U-Boot tree >> > > and pick them up from somewhere else, we can do that with sufficient >> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? >> > >> > We can start slowly migrating boards and see how that works out. >> > We could either use 2 device trees as you proposed, or have u-boot merge >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer >> > if linux gets handed a clean device tree without the u-boot internals in >> > it, so I think 2 discrete DTs is cleaner overall. >> >> I know you would prefer that, but does it really matter in practice? >> What is the objection, actually? >> >> As I mentioned on the call, I think the prior stage should do any >> merging or fixing up. Trying to do that sort of thing in 'early' code >> in U-Boot (or any other program, including Linux) is such a pain. With >> U-Boot, for example, we don't even have any RAM available to do it >> with half the time and it would dramatically increase the amount of >> memory needed prior to relocation. It just isn't a very good idea to >> try to do this in early code. It is also completely unnecessary, once >> you get past the philosophical objections. >> >> If TF-A wants to be in the picture, let it deal with the implications >> and responsibility thus incurred. TF-A has no right to tell U-Boot how >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter >> of the size of U-Boot. It duplicates loads of things in there. No one >> will even *notice* an FDT merge function, which is actually only 70 >> LOC: >> >> /** >> * overlay_apply_node - Merges a node into the base device tree >> * @fdt: Base Device Tree blob >> * @target: Node offset in the base device tree to apply the fragment to >> * @fdto: Device tree overlay blob >> * @node: Node offset in the overlay holding the changes to merge >> * >> * overlay_apply_node() merges a node into a target base device tree >> * node pointed. >> * >> * This is part of the final step in the device tree overlay >> * application process, when all the phandles have been adjusted and >> * resolved and you just have to merge overlay into the base device >> * tree. >> * >> * returns: >> * 0 on success >> * Negative error code on failure >> */ >> static int overlay_apply_node(void *fdt, int target, >> void *fdto, int node) >> { >> int property; >> int subnode; >> >> fdt_for_each_property_offset(property, fdto, node) { >> const char *name; >> const void *prop; >> int prop_len; >> int ret; >> >> prop = fdt_getprop_by_offset(fdto, property, &name, >> &prop_len); >> if (prop_len == -FDT_ERR_NOTFOUND) >> return -FDT_ERR_INTERNAL; >> if (prop_len < 0) >> return prop_len; >> >> ret = fdt_setprop(fdt, target, name, prop, prop_len); >> if (ret) >> return ret; >> } >> >> fdt_for_each_subnode(subnode, fdto, node) { >> const char *name = fdt_get_name(fdto, subnode, NULL); >> int nnode; >> int ret; >> >> nnode = fdt_add_subnode(fdt, target, name); >> if (nnode == -FDT_ERR_EXISTS) { >> nnode = fdt_subnode_offset(fdt, target, name); >> if (nnode == -FDT_ERR_NOTFOUND) >> return -FDT_ERR_INTERNAL; >> } >> >> if (nnode < 0) >> return nnode; >> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode); >> if (ret) >> return ret; >> } >> >> return 0; >> >> >> >> } >> >> >> > >> > Regards >> > /Ilias >> > > >> > > To repeat, if we set things up correctly and agree on the bindings, >> > > devicetree can be the unifying configuration mechanism through the >> > > whole of firmware (except for very early bits) and into the OS. I feel >> > > this will set us up very well to deal with the complexity that is >> > > coming. >> > > >> >> Regards, >> Simon
On Thu, Oct 28, 2021 at 12:00:44AM +0200, François Ozog wrote: > Hi Tom > > Le mer. 27 oct. 2021 à 21:06, Tom Rini <trini@konsulko.com> a écrit : > > > On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote: > > > Hi Mark, > > > > > > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl> > > wrote: > > > > > > > > From: François Ozog <francois.ozog@linaro.org> > > > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > > > > > Hi, > > > > > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> > > wrote: > > > > > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass > > wrote: > > > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > > > francois.ozog@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > > > > sjg@chromium.org> > > > > > > a écrit : > > > > > > > > > > > >> > > > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > > > >> > > > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > > > > trini@konsulko.com> > > > > > > wrote: > > > > > > > > > > > >> > > > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > > > > wrote: > > > > > > > > > > > >> > > Hi Simon, > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > > > > > sjg@chromium.org> wrote: > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > With Ilias' efforts we have dropped > > OF_PRIOR_STAGE > > > > and > > > > > > OF_HOSTFILE so > > > > > > > > > > > >> > > > there are only three ways to obtain a > > devicetree: > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the > > > > devicetree > > > > > > is built and > > > > > > > > > > > >> > > > appended to U-Boot > > > > > > > > > > > >> > > > - OF_EMBED - for development purposes, the > > > > > > devicetree is embedded in > > > > > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > > > > > >> > > > - OF_BOARD - the board figures it out on its > > own > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > The last one is currently set up so that no > > > > devicetree > > > > > > is needed at all > > > > > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, > > but > > > > > > some don't. Some > > > > > > > > > > > >> > > > don't even provide instructions on how to boot > > on > > > > the > > > > > > board. > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > The problems with this approach are documented > > at > > > > [1]. > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct > > from > > > > > > OF_SEPARATE. Any board > > > > > > > > > > > >> > > > can obtain its devicetree at runtime, even it is > > > > has a > > > > > > devicetree built > > > > > > > > > > > >> > > > in U-Boot. This is because U-Boot may be a > > > > second-stage > > > > > > bootloader and its > > > > > > > > > > > >> > > > caller may have a better idea about the hardware > > > > > > available in the machine. > > > > > > > > > > > >> > > > This is the case with a few QEMU boards, for > > > > example. > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a > > > > 'choice'. It > > > > > > should be an > > > > > > > > > > > >> > > > option, available with either OF_SEPARATE or > > > > OF_EMBED. > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > This series makes this change, adding various > > > > missing > > > > > > devicetree files > > > > > > > > > > > >> > > > (and placeholders) to make the build work. > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > Adding device trees that are never used sounds > > like a > > > > > > hack to me. > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on > > the > > > > fly > > > > > > based on > > > > > > > > > > > >> > > command line parameters, and the device tree you > > put > > > > in > > > > > > this series > > > > > > > > > > > >> > > has various hardcoded <phandle> values which > > normally > > > > do > > > > > > not show up > > > > > > > > > > > >> > > in hand-written dts files. > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > I am not sure I understand the whole point of > > this. > > > > > > > > > > > >> > > > > > > > > > > > > >> > I am also confused and do not like the idea of > > adding > > > > > > device trees for > > > > > > > > > > > >> > platforms that are capable of and can / do have a > > device > > > > > > tree to give us > > > > > > > > > > > >> > at run time. > > > > > > > > > > > >> > > > > > > > > > > > >> (I'll just reply to this one email, since the same > > points > > > > > > applies to > > > > > > > > > > > >> all replies I think) > > > > > > > > > > > >> > > > > > > > > > > > >> I have been thinking about this and discussing it with > > > > people > > > > > > for a > > > > > > > > > > > >> few months now. I've been signalling a change like > > this > > > > for > > > > > > over a > > > > > > > > > > > >> month now, on U-Boot contributor calls and in > > discussions > > > > > > with Linaro > > > > > > > > > > > >> people. I sent a patch (below) to try to explain > > things. I > > > > > > hope it is > > > > > > > > > > > >> not a surprise! > > > > > > > > > > > >> > > > > > > > > > > > >> The issue here is that we need a devicetree in-tree in > > > > > > U-Boot, to > > > > > > > > > > > >> avoid the mess that has been created by > > OF_PRIOR_STAGE, > > > > > > OF_BOARD, > > > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, > > OF_HOSTFILE. > > > > > > Between > > > > > > > > > > > >> Ilias' series and this one we can get ourselves on a > > > > stronger > > > > > > footing. > > > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for > > debugging/ELF > > > > > > use. > > > > > > > > > > > >> For more context: > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ > > > > > > > > > > > >> > > > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way > > of > > > > > > adding the > > > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in > > > > fact the > > > > > > > > > > > >> maintainer would prefer there was no special support > > even > > > > for > > > > > > booting > > > > > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > > > > > >> > > > > > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > > > > > >> think the path forward might be to run QEMU twice, > > once to > > > > > > get its > > > > > > > > > > > >> generated tree and once to give the 'merged' tree > > with the > > > > > > U-Boot > > > > > > > > > > > >> properties in it, if people want to use U-Boot > > features. > > > > > > > > > > > >> > > > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > > > > > option, not a > > > > > > > > > > > >> build-time one. It creates all sorts of problems and > > > > > > obscurity which > > > > > > > > > > > >> have taken months to unpick. See the above patch for > > the > > > > > > rationale. > > > > > > > > > > > >> > > > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an > > option > > > > > > available to > > > > > > > > > > > >> any board. At some point in the future it may become a > > > > common > > > > > > way > > > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and > > providing a > > > > > > devicetree > > > > > > > > > > > >> to it. It doesn't make any sense to have people decide > > > > > > whether or not > > > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the > > > > image > > > > > > is put > > > > > > > > > > > >> together. We'll end up with different U-Boot build > > targets > > > > > > like > > > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should > > be > > > > > > obvious where > > > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a > > > > commonly > > > > > > used > > > > > > > > > > > >> option, perhaps enabled by most/all boards, so that > > this > > > > sort > > > > > > of build > > > > > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > > > > > > > > > If you mean that when boards are by construction > > providing > > > > a > > > > > > DTB to U-Boot then I agree very much. But I don’t understand how > > the > > > > patch > > > > > > set supports it as it puts dts files for those boards to be built. > > > > > > > > > > > >> > > > > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > > > > >> function correctly in whatever runtime environment in > > > > which > > > > > > it finds > > > > > > > > > > > >> itself. > > > > > > > > > > > >> > > > > > > > > > > > >> Also as binman is pressed into service more and more > > to > > > > build > > > > > > the > > > > > > > > > > > >> complex firmware images that are becoming > > fashionable, it > > > > > > needs a > > > > > > > > > > > >> definition (in the devicetree) that describes how to > > > > create > > > > > > the image. > > > > > > > > > > > >> We can't support that unless we are building a > > devicetree, > > > > > > nor can the > > > > > > > > > > > >> running program access the image layout without that > > > > > > information. > > > > > > > > > > > >> > > > > > > > > > > > >> François's point about 'don't use this with any > > kernel' is > > > > > > > > > > > >> germane...but of course I am not suggesting doing > > that, > > > > since > > > > > > OF_BOARD > > > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for > > various > > > > > > boards that > > > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and > > 3, > > > > for > > > > > > example > > > > > > > > > > > >> (as I said in the cover letter "Most boards do provide > > > > one, > > > > > > but some > > > > > > > > > > > >> don't."). So this series is just completing the > > picture by > > > > > > enforcing > > > > > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the > > > > default. > > > > > > > > > > > > > > > > > > > > > > I think the key point that will get you closer to where > > I am > > > > on > > > > > > this > > > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > > > > > present it > > > > > > > > > > > has build-time effects and this is quite wrong. If you go > > > > > > through all > > > > > > > > > > > the material I have written on this I think I have > > motivated > > > > > > that very > > > > > > > > > > > clearly. > > > > > > > > > > > > > > > > > > > > > > Another big issue is that I believe we need ONE > > devicetree > > > > for > > > > > > U-Boot, > > > > > > > > > > > not two that get merged by U-Boot. Again I have gone > > through > > > > > > that in a > > > > > > > > > > > lot of detail. > > > > > > > > > > > > > > > > > > > > I have a long long reply to your first reply here saved, > > but, > > > > maybe > > > > > > > > > > here's the biggest sticking point. To be clear, you agree > > that > > > > > > U-Boot > > > > > > > > > > needs to support being passed a device tree to use, at run > > > > time, > > > > > > yes? > > > > > > > > > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we > > built > > > > in? > > > > > > > > > > > > > > > > > > Not at runtime. > > > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > > > So is the sticking point here that we really have two > > classes > > > > of > > > > > > > > > > devices, one class where we will never ever be given the > > device > > > > > > tree at > > > > > > > > > > run time (think BeagleBone Black) and one where we will > > always > > > > be > > > > > > given > > > > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect there > > > > will be > > > > > > > > > (many) boards which can boot happily with the U-Boot > > devicetree > > > > but > > > > > > > > > can also accept one at runtime, if provided. For example, > > you may > > > > > > want > > > > > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > > > > > > > > > I'm not sure I see the value in making this a gray area. > > There's > > > > very > > > > > > > > much a class of "never" boards. There's also the class of > > "can" > > > > today. > > > > > > > > Maybe as part of a developer iterative flow it would be nice > > to not > > > > > > have > > > > > > > > to re-flash the prior stage to change a DT, and just do it in > > > > U-Boot > > > > > > > > until things are happy, but I'm not sure what the use case is > > for > > > > > > > > overriding the previous stage. > > > > > > > > > > > > > > > > Especially since the pushback on this series I think has all > > been > > > > "why > > > > > > > > are we copying in a tree to build with? We don't want to use > > it > > > > at run > > > > > > > > time!". And then softer push back like "Well, U-Boot says we > > have > > > > to > > > > > > > > include the device tree file here, but we won't use it...". > > > > > > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > > > > > inadvertently) > > > > > > > > > provided a way to entirely omit a devicetree from U-Boot, > > thus > > > > making > > > > > > > > > things like binman and U-Boot /config impossible, for > > example. > > > > So I > > > > > > > > > want to claw that back, so there is always some sort of > > > > devicetree in > > > > > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > > > > > > > > > I really want to see what the binary case looks like since we > > could > > > > > > then > > > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > > > > could > > > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can > > come > > > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we > > also > > > > don't > > > > > > > > use the device tree from build time at run time, ignoring the > > > > device > > > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > > > confusing these days. Lots of things to build and it's hard to > > find > > > > > > > the instructions. It doesn't have to be that way, but if we > > carry on > > > > > > > as we are, it will continue to be messy and in five years you > > will > > > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > > > objective here is to simplify things, bringing some consistency > > to > > > > the > > > > > > > different components. Binman was one effort there. I feel that > > > > putting > > > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > > > 2011), is the next step. > > > > > > > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh > > scripts > > > > > > that know where to grab other known-good binaries of varying > > licenses > > > > > > that are needed to assemble something that boots. > > > > > > > > > > > > > If we set things up correctly and agree on the bindings, > > devicetree > > > > > > > can be the unifying configuration mechanism through the whole of > > > > > > > firmware (except for very early bits) and into the OS, this will > > set > > > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the > > > > past > > > > > > > two months: > > > > > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed > > to > > > > > > > have its own nodes/properties in the DT. > > > > > > > > > > In my view U-Boot shall be able to leverage device tree format > > (source > > > > and > > > > > binary) to store its own data. > > > > > When you say "the" DT, I always think this is "the" DT that is > > passed to > > > > OS > > > > > and in "that" DT, there should be no U-Boot entries. > > > > > > > > Why not? As long as the device tree validates, it is perfectly fine > > > > to have additional nodes and properties present. The propertiesand > > > > nodes will be simply ignored by the OS. > > > > > > Because of the way we want to organize the firmware supply chain: when > > the > > > board is built, it is "attached" a device tree. > > > At that moment, we don't know what "non trusted firmware" will be used. > > It > > > could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2 > > (yes > > > it works with DT). > > > And we aim at keeping device tree as close to the original intent: > > hardware > > > description only. It's not because we can stuff anything in the DT and > > that > > > it is simple to do that we should. > > > Driver parameters shall be in the OS facility built for that purpose. > > Using > > > device tree has been an ugly habit. > > > > So we're going to continue to re-litigate what does and doesn't live in > > the device tree for forever, aren't we? To continue to be clear, I'm > > not saying that non-upstream bindings should be present. But for > > example, Simon is working on the "U-Boot config node" binding, which is > > going to get re-spun next as /options/ as I read the thread right. > > Populate it and anyone can read it, and probably be getting information > > that's useful to U-Boot or LinuxBoot or EDK2 or anyone else. That's why > > I keep repeating that projects need to push bindings upstream. I'll > > repeat my comment about > > > > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html > > and the binman node both noting a common problem to solve. > > i think you are right. Now tfa is comfortable being its own upstream for > the binding specifications. Could U-Boot community be comfortable doing so? Well, since we need to and are trying to solve the same problem, why should we duplicate efforts? This is something that should be common and upstream is my point.
Hi Simon Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit : > Hi François, > > On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> > wrote: > > > > Hi Simon, > > > > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit : > >> > >> Hi Ilias, > >> > >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > >> <ilias.apalodimas@linaro.org> wrote: > >> > > >> > Hi Simon, > >> > > >> > A bit late to the party, sorry! > >> > >> (Did you remember the beer? I am replying to this but I don't think it > >> is all that helpful for me to reply to a lot of things on this thread, > >> since I would not be adding much to my cover letter and patches) > >> > >> > > >> > [...] > >> > > >> > > > > >> > > > I really want to see what the binary case looks like since we > could then > >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > could > >> > > > then also do a rpi_arm32_defconfig too. > >> > > > > >> > > > I want to see less device trees in U-Boot sources, if they can > come > >> > > > functionally correct from the hardware/our caller. > >> > > > > >> > > > And I'm not seeing how we make use of "U-Boot /config" if we also > don't > >> > > > use the device tree from build time at run time, ignoring the > device > >> > > > tree provided to us at run time by the caller. > >> > > > >> > > Firstly I should say that I find building firmware very messy and > >> > > confusing these days. Lots of things to build and it's hard to find > >> > > the instructions. It doesn't have to be that way, but if we carry on > >> > > as we are, it will continue to be messy and in five years you will > >> > > need a Ph.D and a lucky charm to boot on any modern board. My > >> > > objective here is to simplify things, bringing some consistency to > the > >> > > different components. Binman was one effort there. I feel that > putting > >> > > at least the U-Boot house in order, in my role as devicetree > >> > > maintainer (and as author of devicetree support in U-Boot back in > >> > > 2011), is the next step. > >> > > > >> > > If we set things up correctly and agree on the bindings, devicetree > >> > > can be the unifying configuration mechanism through the whole of > >> > > firmware (except for very early bits) and into the OS, this will set > >> > > us up very well to deal with the complexity that is coming. > >> > > > >> > > Anyway, here are the mental steps that I've gone through over the > past > >> > > two months: > >> > > > >> > > Step 1: At present, some people think U-Boot is not even allowed to > >> > > have its own nodes/properties in the DT. It is an abuse of the > >> > > devicetree standard, like the /chosen node but with less history. We > >> > > should sacrifice efficiency, expedience and expandability on the > altar > >> > > of 'devicetree is a hardware description'. How do we get over that > >> > > one? Wel, I just think we need to accept that U-Boot uses devicetree > >> > > for its own purposes, as well as for booting the OS. I am not saying > >> > > it always has to have those properties, but with existing features > >> > > like verified boot, SPL as well as complex firmware images where > >> > > U-Boot needs to be able to find things in the image, it is > essential. > >> > > So let's just assume that we need this everywhere, since we > certainly > >> > > need it in at least some places. > >> > > > >> > > (stop reading here if you disagree, because nothing below will make > >> > > any sense...you can still use U-Boot v2011.06 which doesn't have > >> > > OF_CONTROL :-) > >> > > >> > Having U-Boot keep it's *internal* config state in DTs is fine. > Adding > >> > that to the DTs that are copied over from linux isn't imho. There are > >> > various reasons for that. First of all syncing device trees is a > huge pain > >> > and that's probably one of the main reasons our DTs are out of sync > for a > >> > large number of boards. > >> > The point is this was fine in 2011 were we had SPL only, but the > reality > >> > today is completely different. There's previous stage boot loaders > (and > >> > enough cases were vendors prefer those over SPL). If that bootloader > needs > >> > to use it's own device tree for whatever reason, imposing > restrictions on > >> > it wrt to the device tree it has to include, and require them to have > >> > knowledge of U-Boot and it's internal config mechanism makes no sense > not > >> > to mention it doesn't scale at all. > >> > >> I think the solution here may be the binman image packer. It works > >> from a description of the image (i.e. is data-driver) and can collect > >> all the pieces together. The U-Boot properties (and the ones required > >> by TF-A, etc.) can be added at package time. > >> > >> If you think about it, it doesn't matter what properties are in the DT > >> that is put into the firmware image. TF-A, for example, is presumably > >> reading a devicetree from flash, so what does it care if it has some > >> U-Boot properties in it? > > > > > > I am going to change my position in all mail threads I participate. > > I was trying to make patches relevant in the future and conceptually > clean. That may not be the most effective position: I should just care > about Linaro and its members being able to implement SystemReady concepts. > > > > > > If you mandate U-Boot has nodes in the device tree passed to the OS, we > can put DT fragment in the nt_fw_config section of the fip and merge it at > boot time. So there is a solution compatible with SystemReady. > > > > If you want to put fake, non future proof, DT sources in the dts for > platforms that are organized to provide the authoritative DT to U-Boot at > runtime, that's kind of your choice (hopefully representing the rest of > U-Boot community). There will be quirk code in U-Boot to redo the > adaptations on its non authoritative DT that the platform previous stage > firmware does (already saw one in the past month); as Mark said there will > be issues over time; and it will confuse people about the role of the DT. > But I am fine with it as it does not impair Linaro and its members ability > to implement SystemReady way of handling DT. > > OK thank you. It doesn't sound like you are very on-board though. > Also, you mischaracterise my intent with in-tree devicetrees. > > I would be happy enough for now if you could accept that U-Boot has > nodes/properties of its own in the devicetree. It has been a feature > of U-Boot for 10 years now. On SystemReady systems the DT passed to U-Boot for the OS will be assembled from the board DT and a U-Boot fragment/overlay. The board DT is free from any software/firmware aspects, just contains hardware description. The U-Boot fragment/overlay can contain any nodes it wants. The location of the bindings specification is essentially irrelevant: it could be devicetree.org, U-Boot doc or Linux kernel. Both DTs will be stored in the FIP. OEMs making their firmware will just put whatever is needed in this “dynamic config” DT. On SystemReady platforms U-Boot will always be given a DT, like on the RPI4. U-Boot will be able to ignore it obviously. That said, doing so, a platform may end-up failing compliance tests. I think we need to document the above in U-Boot and refer to relevant specifications. I’ll let Ilias propose something. > > > > Regards, > Simon > > > > > >> > >> > >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot, > >> so I think this can be dealt with. > >> > >> > > >> > > > >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > >> > > have binman definitions, etc. So we need a way to overlay those > things > >> > > into the DT. We already support this for in-tree DTs, so IMO this is > >> > > easy. Just require every board to have an in-tree DT. It helps with > >> > > discoverability and documentation, anyway. That is this series. > >> > > > >> > > >> > Again, the board might decide for it's own reason to provide it's own > DT. > >> > IMHO U-Boot must be able to cope with that and asking DTs to be > included in > >> > U-Boot source is not the right way to do that, not to mention cases > were > >> > that's completely unrealistic (e.g QEMU or a board that reads the DTB > from > >> > it's flash). > >> > >> I think you are at step 2. See above for my response. > >> > >> > > >> > > (I think most of us are at the beginning of step 2, unsure about it > >> > > and worried about step 3) > >> > > > >> > > Step 3: Ah, but there are flows (i.e. boards that use a particular > >> > > flow only, or boards that sometimes use a flow) which need the DT to > >> > > come from a prior stage. How to handle that? IMO that is only going > to > >> > > grow as every man and his dog get into the write-a-bootloader > >> > > business. > >> > > >> > And that's exactly why we have to come up with something that > scales, without > >> > having to add a bunch of unusable DTs in U-Boot. > >> > >> In what way does this not scale? How are the DTs unusable? If there is > >> a standard binding, we should be fine. > >> > >> > > >> > > We need a way to provide the U-Boot nodes/properties in a > >> > > form that the prior stage can consume and integrate with its build > >> > > system. Is TF-A the only thing being discussed here? If so, let's > just > >> > > do it. We have the u-boot.dtsi and we can use binman to put the > image > >> > > together, for example. Or we can get clever and create some sort of > >> > > overlay dtb. > >> > > > >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > >> > > then it will need to build it in and use two devicetrees, one > internal > >> > > and one from the prior stage....well that is not very efficient and > it > >> > > is going to be confusing for people to figure out what U-Boot is > >> > > actually doing. But we actually already do that in a lot of cases > >> > > where U-Boot passes a DT to the kernel which is different to the one > >> > > it uses. So perhaps we have three devicetrees? OMG. > >> > > >> > No we don't. That's a moot point. If you separate the DTs U-Boot > >> > provides the internal one and inherits one 'generic'. Linux will be > able to use > >> > that. So the only case were you'll need 3 DTs is if the *vendor* > breaks the > >> > DT across kernel versions, In which case there's not much you can do > to > >> > begin with and that's already a case we have to deal with. > >> > >> Linux actually doesn't care if the U-Boot properties are in the tree, > >> so long as we have proper bindings. My point here is we only need > >> either: > >> > >> a. one devicetree, shared with Linux and U-Boot (and TF-A?) > >> b. two devicetrees, one for use in firmware and one for passing to Linux > >> > >> We don't need to separate out the U-Boot properties into a second (or > >> third) devicetree. There just isn't any point. > >> > >> > > >> > > b) Well then > >> > > U-Boot can have its own small devicetree with its bits and then > U-Boot > >> > > can merge the two when it starts. Again that is not very efficient. > It > >> > > means that U-Boot cannot be controlled by the prior stage (e.g. to > get > >> > > its public key from there or to enable/disable the console), so > >> > > unified firmware config is not possible. It will get very confusing, > >> > > particularly for debugging U-Boot. c) Some other scheme to avoid > >> > > accepting step 3...please stop! > >> > > > >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > >> > > whole cloth. What about that? Well, we are just going to have to > deal > >> > > with that. We can easily merge in the U-Boot nodes/properties and > >> > > update the U-Boot CI scripts to do this, as needed, e.g. with > >> > > qemu-riscv64_spl. It's only one use case, although Xen might do > >> > > something similar. > >> > > > >> > > To my mind, that deals with both the build-time and run-time issues. > >> > > We have a discoverable DT in U-Boot, which should be considered the > >> > > source of truth for most boards. We can sync it with Linux > >> > > automatically with the tooling that I hope Rob Herring will come up > >> > > with. We can use an empty one where there really is no default, > >> > > although I'd argue that is making perfect an enemy of the good. > >> > > > >> > > Step 5: If we get clever and want to remove them from the U-Boot > tree > >> > > and pick them up from somewhere else, we can do that with sufficient > >> > > tooling. Perhaps we should set a timeline for that? A year? Two? > Six? > >> > > >> > We can start slowly migrating boards and see how that works out. > >> > We could either use 2 device trees as you proposed, or have u-boot > merge > >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd > prefer > >> > if linux gets handed a clean device tree without the u-boot internals > in > >> > it, so I think 2 discrete DTs is cleaner overall. > >> > >> I know you would prefer that, but does it really matter in practice? > >> What is the objection, actually? > >> > >> As I mentioned on the call, I think the prior stage should do any > >> merging or fixing up. Trying to do that sort of thing in 'early' code > >> in U-Boot (or any other program, including Linux) is such a pain. With > >> U-Boot, for example, we don't even have any RAM available to do it > >> with half the time and it would dramatically increase the amount of > >> memory needed prior to relocation. It just isn't a very good idea to > >> try to do this in early code. It is also completely unnecessary, once > >> you get past the philosophical objections. > >> > >> If TF-A wants to be in the picture, let it deal with the implications > >> and responsibility thus incurred. TF-A has no right to tell U-Boot how > >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter > >> of the size of U-Boot. It duplicates loads of things in there. No one > >> will even *notice* an FDT merge function, which is actually only 70 > >> LOC: > >> > >> /** > >> * overlay_apply_node - Merges a node into the base device tree > >> * @fdt: Base Device Tree blob > >> * @target: Node offset in the base device tree to apply the fragment to > >> * @fdto: Device tree overlay blob > >> * @node: Node offset in the overlay holding the changes to merge > >> * > >> * overlay_apply_node() merges a node into a target base device tree > >> * node pointed. > >> * > >> * This is part of the final step in the device tree overlay > >> * application process, when all the phandles have been adjusted and > >> * resolved and you just have to merge overlay into the base device > >> * tree. > >> * > >> * returns: > >> * 0 on success > >> * Negative error code on failure > >> */ > >> static int overlay_apply_node(void *fdt, int target, > >> void *fdto, int node) > >> { > >> int property; > >> int subnode; > >> > >> fdt_for_each_property_offset(property, fdto, node) { > >> const char *name; > >> const void *prop; > >> int prop_len; > >> int ret; > >> > >> prop = fdt_getprop_by_offset(fdto, property, &name, > >> &prop_len); > >> if (prop_len == -FDT_ERR_NOTFOUND) > >> return -FDT_ERR_INTERNAL; > >> if (prop_len < 0) > >> return prop_len; > >> > >> ret = fdt_setprop(fdt, target, name, prop, prop_len); > >> if (ret) > >> return ret; > >> } > >> > >> fdt_for_each_subnode(subnode, fdto, node) { > >> const char *name = fdt_get_name(fdto, subnode, NULL); > >> int nnode; > >> int ret; > >> > >> nnode = fdt_add_subnode(fdt, target, name); > >> if (nnode == -FDT_ERR_EXISTS) { > >> nnode = fdt_subnode_offset(fdt, target, name); > >> if (nnode == -FDT_ERR_NOTFOUND) > >> return -FDT_ERR_INTERNAL; > >> } > >> > >> if (nnode < 0) > >> return nnode; > >> > >> ret = overlay_apply_node(fdt, nnode, fdto, subnode); > >> if (ret) > >> return ret; > >> } > >> > >> return 0; > >> > >> > >> > >> } > >> > >> > >> > > >> > Regards > >> > /Ilias > >> > > > >> > > To repeat, if we set things up correctly and agree on the bindings, > >> > > devicetree can be the unifying configuration mechanism through the > >> > > whole of firmware (except for very early bits) and into the OS. I > feel > >> > > this will set us up very well to deal with the complexity that is > >> > > coming. > >> > > > >> > >> Regards, > >> Simon >
Hi François, On Thu, 28 Oct 2021 at 08:50, François Ozog <francois.ozog@linaro.org> wrote: > > Hi Simon > > Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit : >> >> Hi François, >> >> On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> wrote: >> > >> > Hi Simon, >> > >> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit : >> >> >> >> Hi Ilias, >> >> >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas >> >> <ilias.apalodimas@linaro.org> wrote: >> >> > >> >> > Hi Simon, >> >> > >> >> > A bit late to the party, sorry! >> >> >> >> (Did you remember the beer? I am replying to this but I don't think it >> >> is all that helpful for me to reply to a lot of things on this thread, >> >> since I would not be adding much to my cover letter and patches) >> >> >> >> > >> >> > [...] >> >> > >> >> > > > >> >> > > > I really want to see what the binary case looks like since we could then >> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could >> >> > > > then also do a rpi_arm32_defconfig too. >> >> > > > >> >> > > > I want to see less device trees in U-Boot sources, if they can come >> >> > > > functionally correct from the hardware/our caller. >> >> > > > >> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't >> >> > > > use the device tree from build time at run time, ignoring the device >> >> > > > tree provided to us at run time by the caller. >> >> > > >> >> > > Firstly I should say that I find building firmware very messy and >> >> > > confusing these days. Lots of things to build and it's hard to find >> >> > > the instructions. It doesn't have to be that way, but if we carry on >> >> > > as we are, it will continue to be messy and in five years you will >> >> > > need a Ph.D and a lucky charm to boot on any modern board. My >> >> > > objective here is to simplify things, bringing some consistency to the >> >> > > different components. Binman was one effort there. I feel that putting >> >> > > at least the U-Boot house in order, in my role as devicetree >> >> > > maintainer (and as author of devicetree support in U-Boot back in >> >> > > 2011), is the next step. >> >> > > >> >> > > If we set things up correctly and agree on the bindings, devicetree >> >> > > can be the unifying configuration mechanism through the whole of >> >> > > firmware (except for very early bits) and into the OS, this will set >> >> > > us up very well to deal with the complexity that is coming. >> >> > > >> >> > > Anyway, here are the mental steps that I've gone through over the past >> >> > > two months: >> >> > > >> >> > > Step 1: At present, some people think U-Boot is not even allowed to >> >> > > have its own nodes/properties in the DT. It is an abuse of the >> >> > > devicetree standard, like the /chosen node but with less history. We >> >> > > should sacrifice efficiency, expedience and expandability on the altar >> >> > > of 'devicetree is a hardware description'. How do we get over that >> >> > > one? Wel, I just think we need to accept that U-Boot uses devicetree >> >> > > for its own purposes, as well as for booting the OS. I am not saying >> >> > > it always has to have those properties, but with existing features >> >> > > like verified boot, SPL as well as complex firmware images where >> >> > > U-Boot needs to be able to find things in the image, it is essential. >> >> > > So let's just assume that we need this everywhere, since we certainly >> >> > > need it in at least some places. >> >> > > >> >> > > (stop reading here if you disagree, because nothing below will make >> >> > > any sense...you can still use U-Boot v2011.06 which doesn't have >> >> > > OF_CONTROL :-) >> >> > >> >> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding >> >> > that to the DTs that are copied over from linux isn't imho. There are >> >> > various reasons for that. First of all syncing device trees is a huge pain >> >> > and that's probably one of the main reasons our DTs are out of sync for a >> >> > large number of boards. >> >> > The point is this was fine in 2011 were we had SPL only, but the reality >> >> > today is completely different. There's previous stage boot loaders (and >> >> > enough cases were vendors prefer those over SPL). If that bootloader needs >> >> > to use it's own device tree for whatever reason, imposing restrictions on >> >> > it wrt to the device tree it has to include, and require them to have >> >> > knowledge of U-Boot and it's internal config mechanism makes no sense not >> >> > to mention it doesn't scale at all. >> >> >> >> I think the solution here may be the binman image packer. It works >> >> from a description of the image (i.e. is data-driver) and can collect >> >> all the pieces together. The U-Boot properties (and the ones required >> >> by TF-A, etc.) can be added at package time. >> >> >> >> If you think about it, it doesn't matter what properties are in the DT >> >> that is put into the firmware image. TF-A, for example, is presumably >> >> reading a devicetree from flash, so what does it care if it has some >> >> U-Boot properties in it? >> > >> > >> > I am going to change my position in all mail threads I participate. >> > I was trying to make patches relevant in the future and conceptually clean. That may not be the most effective position: I should just care about Linaro and its members being able to implement SystemReady concepts. >> > >> > >> > If you mandate U-Boot has nodes in the device tree passed to the OS, we can put DT fragment in the nt_fw_config section of the fip and merge it at boot time. So there is a solution compatible with SystemReady. >> > >> > If you want to put fake, non future proof, DT sources in the dts for platforms that are organized to provide the authoritative DT to U-Boot at runtime, that's kind of your choice (hopefully representing the rest of U-Boot community). There will be quirk code in U-Boot to redo the adaptations on its non authoritative DT that the platform previous stage firmware does (already saw one in the past month); as Mark said there will be issues over time; and it will confuse people about the role of the DT. But I am fine with it as it does not impair Linaro and its members ability to implement SystemReady way of handling DT. >> >> OK thank you. It doesn't sound like you are very on-board though. >> Also, you mischaracterise my intent with in-tree devicetrees. >> >> I would be happy enough for now if you could accept that U-Boot has >> nodes/properties of its own in the devicetree. It has been a feature >> of U-Boot for 10 years now. > > On SystemReady systems the DT passed to U-Boot for the OS will be assembled from the board DT and a U-Boot fragment/overlay. The board DT is free from any software/firmware aspects, just contains hardware description. The U-Boot fragment/overlay can contain any nodes it wants. The location of the bindings specification is essentially irrelevant: it could be devicetree.org, U-Boot doc or Linux kernel. Both DTs will be stored in the FIP. OEMs making their firmware will just put whatever is needed in this “dynamic config” DT. On SystemReady platforms U-Boot will always be given a DT, like on the RPI4. U-Boot will be able to ignore it obviously. That said, doing so, a platform may end-up failing compliance tests. > I think we need to document the above in U-Boot and refer to relevant specifications. I’ll let Ilias propose something. Hmm. So long as OF_BOARD is enabled, the devicetree will not be 'ignored'. Are you talking here about what TF-A will do? I assume so, since you mention FIP and I believe that is a TF-A invention. Of course the image is all packaged together in fact, so binman could presumably merge the DTs at build time, if desired. Regards, Simon >> >> >> >> >> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot, >> >> so I think this can be dealt with. >> >> >> >> > >> >> > > >> >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get >> >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch >> >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we >> >> > > have binman definitions, etc. So we need a way to overlay those things >> >> > > into the DT. We already support this for in-tree DTs, so IMO this is >> >> > > easy. Just require every board to have an in-tree DT. It helps with >> >> > > discoverability and documentation, anyway. That is this series. >> >> > > >> >> > >> >> > Again, the board might decide for it's own reason to provide it's own DT. >> >> > IMHO U-Boot must be able to cope with that and asking DTs to be included in >> >> > U-Boot source is not the right way to do that, not to mention cases were >> >> > that's completely unrealistic (e.g QEMU or a board that reads the DTB from >> >> > it's flash). >> >> >> >> I think you are at step 2. See above for my response. >> >> >> >> > >> >> > > (I think most of us are at the beginning of step 2, unsure about it >> >> > > and worried about step 3) >> >> > > >> >> > > Step 3: Ah, but there are flows (i.e. boards that use a particular >> >> > > flow only, or boards that sometimes use a flow) which need the DT to >> >> > > come from a prior stage. How to handle that? IMO that is only going to >> >> > > grow as every man and his dog get into the write-a-bootloader >> >> > > business. >> >> > >> >> > And that's exactly why we have to come up with something that scales, without >> >> > having to add a bunch of unusable DTs in U-Boot. >> >> >> >> In what way does this not scale? How are the DTs unusable? If there is >> >> a standard binding, we should be fine. >> >> >> >> > >> >> > > We need a way to provide the U-Boot nodes/properties in a >> >> > > form that the prior stage can consume and integrate with its build >> >> > > system. Is TF-A the only thing being discussed here? If so, let's just >> >> > > do it. We have the u-boot.dtsi and we can use binman to put the image >> >> > > together, for example. Or we can get clever and create some sort of >> >> > > overlay dtb. >> >> > > >> >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff >> >> > > then it will need to build it in and use two devicetrees, one internal >> >> > > and one from the prior stage....well that is not very efficient and it >> >> > > is going to be confusing for people to figure out what U-Boot is >> >> > > actually doing. But we actually already do that in a lot of cases >> >> > > where U-Boot passes a DT to the kernel which is different to the one >> >> > > it uses. So perhaps we have three devicetrees? OMG. >> >> > >> >> > No we don't. That's a moot point. If you separate the DTs U-Boot >> >> > provides the internal one and inherits one 'generic'. Linux will be able to use >> >> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the >> >> > DT across kernel versions, In which case there's not much you can do to >> >> > begin with and that's already a case we have to deal with. >> >> >> >> Linux actually doesn't care if the U-Boot properties are in the tree, >> >> so long as we have proper bindings. My point here is we only need >> >> either: >> >> >> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?) >> >> b. two devicetrees, one for use in firmware and one for passing to Linux >> >> >> >> We don't need to separate out the U-Boot properties into a second (or >> >> third) devicetree. There just isn't any point. >> >> >> >> > >> >> > > b) Well then >> >> > > U-Boot can have its own small devicetree with its bits and then U-Boot >> >> > > can merge the two when it starts. Again that is not very efficient. It >> >> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get >> >> > > its public key from there or to enable/disable the console), so >> >> > > unified firmware config is not possible. It will get very confusing, >> >> > > particularly for debugging U-Boot. c) Some other scheme to avoid >> >> > > accepting step 3...please stop! >> >> > > >> >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of >> >> > > whole cloth. What about that? Well, we are just going to have to deal >> >> > > with that. We can easily merge in the U-Boot nodes/properties and >> >> > > update the U-Boot CI scripts to do this, as needed, e.g. with >> >> > > qemu-riscv64_spl. It's only one use case, although Xen might do >> >> > > something similar. >> >> > > >> >> > > To my mind, that deals with both the build-time and run-time issues. >> >> > > We have a discoverable DT in U-Boot, which should be considered the >> >> > > source of truth for most boards. We can sync it with Linux >> >> > > automatically with the tooling that I hope Rob Herring will come up >> >> > > with. We can use an empty one where there really is no default, >> >> > > although I'd argue that is making perfect an enemy of the good. >> >> > > >> >> > > Step 5: If we get clever and want to remove them from the U-Boot tree >> >> > > and pick them up from somewhere else, we can do that with sufficient >> >> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? >> >> > >> >> > We can start slowly migrating boards and see how that works out. >> >> > We could either use 2 device trees as you proposed, or have u-boot merge >> >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer >> >> > if linux gets handed a clean device tree without the u-boot internals in >> >> > it, so I think 2 discrete DTs is cleaner overall. >> >> >> >> I know you would prefer that, but does it really matter in practice? >> >> What is the objection, actually? >> >> >> >> As I mentioned on the call, I think the prior stage should do any >> >> merging or fixing up. Trying to do that sort of thing in 'early' code >> >> in U-Boot (or any other program, including Linux) is such a pain. With >> >> U-Boot, for example, we don't even have any RAM available to do it >> >> with half the time and it would dramatically increase the amount of >> >> memory needed prior to relocation. It just isn't a very good idea to >> >> try to do this in early code. It is also completely unnecessary, once >> >> you get past the philosophical objections. >> >> >> >> If TF-A wants to be in the picture, let it deal with the implications >> >> and responsibility thus incurred. TF-A has no right to tell U-Boot how >> >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter >> >> of the size of U-Boot. It duplicates loads of things in there. No one >> >> will even *notice* an FDT merge function, which is actually only 70 >> >> LOC: >> >> >> >> /** >> >> * overlay_apply_node - Merges a node into the base device tree >> >> * @fdt: Base Device Tree blob >> >> * @target: Node offset in the base device tree to apply the fragment to >> >> * @fdto: Device tree overlay blob >> >> * @node: Node offset in the overlay holding the changes to merge >> >> * >> >> * overlay_apply_node() merges a node into a target base device tree >> >> * node pointed. >> >> * >> >> * This is part of the final step in the device tree overlay >> >> * application process, when all the phandles have been adjusted and >> >> * resolved and you just have to merge overlay into the base device >> >> * tree. >> >> * >> >> * returns: >> >> * 0 on success >> >> * Negative error code on failure >> >> */ >> >> static int overlay_apply_node(void *fdt, int target, >> >> void *fdto, int node) >> >> { >> >> int property; >> >> int subnode; >> >> >> >> fdt_for_each_property_offset(property, fdto, node) { >> >> const char *name; >> >> const void *prop; >> >> int prop_len; >> >> int ret; >> >> >> >> prop = fdt_getprop_by_offset(fdto, property, &name, >> >> &prop_len); >> >> if (prop_len == -FDT_ERR_NOTFOUND) >> >> return -FDT_ERR_INTERNAL; >> >> if (prop_len < 0) >> >> return prop_len; >> >> >> >> ret = fdt_setprop(fdt, target, name, prop, prop_len); >> >> if (ret) >> >> return ret; >> >> } >> >> >> >> fdt_for_each_subnode(subnode, fdto, node) { >> >> const char *name = fdt_get_name(fdto, subnode, NULL); >> >> int nnode; >> >> int ret; >> >> >> >> nnode = fdt_add_subnode(fdt, target, name); >> >> if (nnode == -FDT_ERR_EXISTS) { >> >> nnode = fdt_subnode_offset(fdt, target, name); >> >> if (nnode == -FDT_ERR_NOTFOUND) >> >> return -FDT_ERR_INTERNAL; >> >> } >> >> >> >> if (nnode < 0) >> >> return nnode; >> >> >> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode); >> >> if (ret) >> >> return ret; >> >> } >> >> >> >> return 0; >> >> >> >> >> >> >> >> } >> >> >> >> >> >> > >> >> > Regards >> >> > /Ilias >> >> > > >> >> > > To repeat, if we set things up correctly and agree on the bindings, >> >> > > devicetree can be the unifying configuration mechanism through the >> >> > > whole of firmware (except for very early bits) and into the OS. I feel >> >> > > this will set us up very well to deal with the complexity that is >> >> > > coming. >> >> > > >> >> >> >> Regards, >> >> Simon > > -- > François-Frédéric Ozog | Director Business Development > T: +33.67221.6485 > francois.ozog@linaro.org | Skype: ffozog >
Hi Simon Le jeu. 28 oct. 2021 à 17:44, Simon Glass <sjg@chromium.org> a écrit : > Hi François, > > On Thu, 28 Oct 2021 at 08:50, François Ozog <francois.ozog@linaro.org> > wrote: > > > > Hi Simon > > > > Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit : > >> > >> Hi François, > >> > >> On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> > wrote: > >> > > >> > Hi Simon, > >> > > >> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit > : > >> >> > >> >> Hi Ilias, > >> >> > >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > >> >> <ilias.apalodimas@linaro.org> wrote: > >> >> > > >> >> > Hi Simon, > >> >> > > >> >> > A bit late to the party, sorry! > >> >> > >> >> (Did you remember the beer? I am replying to this but I don't think > it > >> >> is all that helpful for me to reply to a lot of things on this > thread, > >> >> since I would not be adding much to my cover letter and patches) > >> >> > >> >> > > >> >> > [...] > >> >> > > >> >> > > > > >> >> > > > I really want to see what the binary case looks like since we > could then > >> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > could > >> >> > > > then also do a rpi_arm32_defconfig too. > >> >> > > > > >> >> > > > I want to see less device trees in U-Boot sources, if they can > come > >> >> > > > functionally correct from the hardware/our caller. > >> >> > > > > >> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we > also don't > >> >> > > > use the device tree from build time at run time, ignoring the > device > >> >> > > > tree provided to us at run time by the caller. > >> >> > > > >> >> > > Firstly I should say that I find building firmware very messy and > >> >> > > confusing these days. Lots of things to build and it's hard to > find > >> >> > > the instructions. It doesn't have to be that way, but if we > carry on > >> >> > > as we are, it will continue to be messy and in five years you > will > >> >> > > need a Ph.D and a lucky charm to boot on any modern board. My > >> >> > > objective here is to simplify things, bringing some consistency > to the > >> >> > > different components. Binman was one effort there. I feel that > putting > >> >> > > at least the U-Boot house in order, in my role as devicetree > >> >> > > maintainer (and as author of devicetree support in U-Boot back in > >> >> > > 2011), is the next step. > >> >> > > > >> >> > > If we set things up correctly and agree on the bindings, > devicetree > >> >> > > can be the unifying configuration mechanism through the whole of > >> >> > > firmware (except for very early bits) and into the OS, this will > set > >> >> > > us up very well to deal with the complexity that is coming. > >> >> > > > >> >> > > Anyway, here are the mental steps that I've gone through over > the past > >> >> > > two months: > >> >> > > > >> >> > > Step 1: At present, some people think U-Boot is not even allowed > to > >> >> > > have its own nodes/properties in the DT. It is an abuse of the > >> >> > > devicetree standard, like the /chosen node but with less > history. We > >> >> > > should sacrifice efficiency, expedience and expandability on the > altar > >> >> > > of 'devicetree is a hardware description'. How do we get over > that > >> >> > > one? Wel, I just think we need to accept that U-Boot uses > devicetree > >> >> > > for its own purposes, as well as for booting the OS. I am not > saying > >> >> > > it always has to have those properties, but with existing > features > >> >> > > like verified boot, SPL as well as complex firmware images where > >> >> > > U-Boot needs to be able to find things in the image, it is > essential. > >> >> > > So let's just assume that we need this everywhere, since we > certainly > >> >> > > need it in at least some places. > >> >> > > > >> >> > > (stop reading here if you disagree, because nothing below will > make > >> >> > > any sense...you can still use U-Boot v2011.06 which doesn't have > >> >> > > OF_CONTROL :-) > >> >> > > >> >> > Having U-Boot keep it's *internal* config state in DTs is fine. > Adding > >> >> > that to the DTs that are copied over from linux isn't imho. There > are > >> >> > various reasons for that. First of all syncing device trees is a > huge pain > >> >> > and that's probably one of the main reasons our DTs are out of > sync for a > >> >> > large number of boards. > >> >> > The point is this was fine in 2011 were we had SPL only, but the > reality > >> >> > today is completely different. There's previous stage boot > loaders (and > >> >> > enough cases were vendors prefer those over SPL). If that > bootloader needs > >> >> > to use it's own device tree for whatever reason, imposing > restrictions on > >> >> > it wrt to the device tree it has to include, and require them to > have > >> >> > knowledge of U-Boot and it's internal config mechanism makes no > sense not > >> >> > to mention it doesn't scale at all. > >> >> > >> >> I think the solution here may be the binman image packer. It works > >> >> from a description of the image (i.e. is data-driver) and can collect > >> >> all the pieces together. The U-Boot properties (and the ones required > >> >> by TF-A, etc.) can be added at package time. > >> >> > >> >> If you think about it, it doesn't matter what properties are in the > DT > >> >> that is put into the firmware image. TF-A, for example, is presumably > >> >> reading a devicetree from flash, so what does it care if it has some > >> >> U-Boot properties in it? > >> > > >> > > >> > I am going to change my position in all mail threads I participate. > >> > I was trying to make patches relevant in the future and conceptually > clean. That may not be the most effective position: I should just care > about Linaro and its members being able to implement SystemReady concepts. > >> > > >> > > >> > If you mandate U-Boot has nodes in the device tree passed to the OS, > we can put DT fragment in the nt_fw_config section of the fip and merge it > at boot time. So there is a solution compatible with SystemReady. > >> > > >> > If you want to put fake, non future proof, DT sources in the dts for > platforms that are organized to provide the authoritative DT to U-Boot at > runtime, that's kind of your choice (hopefully representing the rest of > U-Boot community). There will be quirk code in U-Boot to redo the > adaptations on its non authoritative DT that the platform previous stage > firmware does (already saw one in the past month); as Mark said there will > be issues over time; and it will confuse people about the role of the DT. > But I am fine with it as it does not impair Linaro and its members ability > to implement SystemReady way of handling DT. > >> > >> OK thank you. It doesn't sound like you are very on-board though. > >> Also, you mischaracterise my intent with in-tree devicetrees. > >> > >> I would be happy enough for now if you could accept that U-Boot has > >> nodes/properties of its own in the devicetree. It has been a feature > >> of U-Boot for 10 years now. > > > > On SystemReady systems the DT passed to U-Boot for the OS will be > assembled from the board DT and a U-Boot fragment/overlay. The board DT is > free from any software/firmware aspects, just contains hardware > description. The U-Boot fragment/overlay can contain any nodes it wants. > The location of the bindings specification is essentially irrelevant: it > could be devicetree.org, U-Boot doc or Linux kernel. Both DTs will be > stored in the FIP. OEMs making their firmware will just put whatever is > needed in this “dynamic config” DT. On SystemReady platforms U-Boot will > always be given a DT, like on the RPI4. U-Boot will be able to ignore it > obviously. That said, doing so, a platform may end-up failing compliance > tests. > > I think we need to document the above in U-Boot and refer to relevant > specifications. I’ll let Ilias propose something. > > Hmm. So long as OF_BOARD is enabled, the devicetree will not be 'ignored'. > > Are you talking here about what TF-A will do? I assume so, since you > mention FIP and I believe that is a TF-A invention. > Yes > > Of course the image is all packaged together in fact, so binman could > presumably merge the DTs at build time, if desired. Practically I don’t think so. The passed device tree will contain all authoritative information such as discovered normal memory (excluded the secure memory ranges), architectural nodes such as PSCI and other nodes coming from TEE-OS or secure partitions such as SCMI interface or firmwareTPM. If you combine the two static parts at build time you will have to extract the runtime pieces from the DT passed to U-Boot. > > > Regards, > Simon > > >> >> > >> >> > >> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot, > >> >> so I think this can be dealt with. > >> >> > >> >> > > >> >> > > > >> >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they > get > >> >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > >> >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi > file"), we > >> >> > > have binman definitions, etc. So we need a way to overlay those > things > >> >> > > into the DT. We already support this for in-tree DTs, so IMO > this is > >> >> > > easy. Just require every board to have an in-tree DT. It helps > with > >> >> > > discoverability and documentation, anyway. That is this series. > >> >> > > > >> >> > > >> >> > Again, the board might decide for it's own reason to provide it's > own DT. > >> >> > IMHO U-Boot must be able to cope with that and asking DTs to be > included in > >> >> > U-Boot source is not the right way to do that, not to mention > cases were > >> >> > that's completely unrealistic (e.g QEMU or a board that reads the > DTB from > >> >> > it's flash). > >> >> > >> >> I think you are at step 2. See above for my response. > >> >> > >> >> > > >> >> > > (I think most of us are at the beginning of step 2, unsure about > it > >> >> > > and worried about step 3) > >> >> > > > >> >> > > Step 3: Ah, but there are flows (i.e. boards that use a > particular > >> >> > > flow only, or boards that sometimes use a flow) which need the > DT to > >> >> > > come from a prior stage. How to handle that? IMO that is only > going to > >> >> > > grow as every man and his dog get into the write-a-bootloader > >> >> > > business. > >> >> > > >> >> > And that's exactly why we have to come up with something that > scales, without > >> >> > having to add a bunch of unusable DTs in U-Boot. > >> >> > >> >> In what way does this not scale? How are the DTs unusable? If there > is > >> >> a standard binding, we should be fine. > >> >> > >> >> > > >> >> > > We need a way to provide the U-Boot nodes/properties in a > >> >> > > form that the prior stage can consume and integrate with its > build > >> >> > > system. Is TF-A the only thing being discussed here? If so, > let's just > >> >> > > do it. We have the u-boot.dtsi and we can use binman to put the > image > >> >> > > together, for example. Or we can get clever and create some sort > of > >> >> > > overlay dtb. > >> >> > > > >> >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this > stuff > >> >> > > then it will need to build it in and use two devicetrees, one > internal > >> >> > > and one from the prior stage....well that is not very efficient > and it > >> >> > > is going to be confusing for people to figure out what U-Boot is > >> >> > > actually doing. But we actually already do that in a lot of cases > >> >> > > where U-Boot passes a DT to the kernel which is different to the > one > >> >> > > it uses. So perhaps we have three devicetrees? OMG. > >> >> > > >> >> > No we don't. That's a moot point. If you separate the DTs U-Boot > >> >> > provides the internal one and inherits one 'generic'. Linux will > be able to use > >> >> > that. So the only case were you'll need 3 DTs is if the *vendor* > breaks the > >> >> > DT across kernel versions, In which case there's not much you can > do to > >> >> > begin with and that's already a case we have to deal with. > >> >> > >> >> Linux actually doesn't care if the U-Boot properties are in the tree, > >> >> so long as we have proper bindings. My point here is we only need > >> >> either: > >> >> > >> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?) > >> >> b. two devicetrees, one for use in firmware and one for passing to > Linux > >> >> > >> >> We don't need to separate out the U-Boot properties into a second (or > >> >> third) devicetree. There just isn't any point. > >> >> > >> >> > > >> >> > > b) Well then > >> >> > > U-Boot can have its own small devicetree with its bits and then > U-Boot > >> >> > > can merge the two when it starts. Again that is not very > efficient. It > >> >> > > means that U-Boot cannot be controlled by the prior stage (e.g. > to get > >> >> > > its public key from there or to enable/disable the console), so > >> >> > > unified firmware config is not possible. It will get very > confusing, > >> >> > > particularly for debugging U-Boot. c) Some other scheme to avoid > >> >> > > accepting step 3...please stop! > >> >> > > > >> >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up > out of > >> >> > > whole cloth. What about that? Well, we are just going to have to > deal > >> >> > > with that. We can easily merge in the U-Boot nodes/properties and > >> >> > > update the U-Boot CI scripts to do this, as needed, e.g. with > >> >> > > qemu-riscv64_spl. It's only one use case, although Xen might do > >> >> > > something similar. > >> >> > > > >> >> > > To my mind, that deals with both the build-time and run-time > issues. > >> >> > > We have a discoverable DT in U-Boot, which should be considered > the > >> >> > > source of truth for most boards. We can sync it with Linux > >> >> > > automatically with the tooling that I hope Rob Herring will come > up > >> >> > > with. We can use an empty one where there really is no default, > >> >> > > although I'd argue that is making perfect an enemy of the good. > >> >> > > > >> >> > > Step 5: If we get clever and want to remove them from the U-Boot > tree > >> >> > > and pick them up from somewhere else, we can do that with > sufficient > >> >> > > tooling. Perhaps we should set a timeline for that? A year? Two? > Six? > >> >> > > >> >> > We can start slowly migrating boards and see how that works out. > >> >> > We could either use 2 device trees as you proposed, or have u-boot > merge > >> >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH > I'd prefer > >> >> > if linux gets handed a clean device tree without the u-boot > internals in > >> >> > it, so I think 2 discrete DTs is cleaner overall. > >> >> > >> >> I know you would prefer that, but does it really matter in practice? > >> >> What is the objection, actually? > >> >> > >> >> As I mentioned on the call, I think the prior stage should do any > >> >> merging or fixing up. Trying to do that sort of thing in 'early' code > >> >> in U-Boot (or any other program, including Linux) is such a pain. > With > >> >> U-Boot, for example, we don't even have any RAM available to do it > >> >> with half the time and it would dramatically increase the amount of > >> >> memory needed prior to relocation. It just isn't a very good idea to > >> >> try to do this in early code. It is also completely unnecessary, once > >> >> you get past the philosophical objections. > >> >> > >> >> If TF-A wants to be in the picture, let it deal with the implications > >> >> and responsibility thus incurred. TF-A has no right to tell U-Boot > how > >> >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter > >> >> of the size of U-Boot. It duplicates loads of things in there. No one > >> >> will even *notice* an FDT merge function, which is actually only 70 > >> >> LOC: > >> >> > >> >> /** > >> >> * overlay_apply_node - Merges a node into the base device tree > >> >> * @fdt: Base Device Tree blob > >> >> * @target: Node offset in the base device tree to apply the > fragment to > >> >> * @fdto: Device tree overlay blob > >> >> * @node: Node offset in the overlay holding the changes to merge > >> >> * > >> >> * overlay_apply_node() merges a node into a target base device tree > >> >> * node pointed. > >> >> * > >> >> * This is part of the final step in the device tree overlay > >> >> * application process, when all the phandles have been adjusted and > >> >> * resolved and you just have to merge overlay into the base device > >> >> * tree. > >> >> * > >> >> * returns: > >> >> * 0 on success > >> >> * Negative error code on failure > >> >> */ > >> >> static int overlay_apply_node(void *fdt, int target, > >> >> void *fdto, int node) > >> >> { > >> >> int property; > >> >> int subnode; > >> >> > >> >> fdt_for_each_property_offset(property, fdto, node) { > >> >> const char *name; > >> >> const void *prop; > >> >> int prop_len; > >> >> int ret; > >> >> > >> >> prop = fdt_getprop_by_offset(fdto, property, &name, > >> >> &prop_len); > >> >> if (prop_len == -FDT_ERR_NOTFOUND) > >> >> return -FDT_ERR_INTERNAL; > >> >> if (prop_len < 0) > >> >> return prop_len; > >> >> > >> >> ret = fdt_setprop(fdt, target, name, prop, prop_len); > >> >> if (ret) > >> >> return ret; > >> >> } > >> >> > >> >> fdt_for_each_subnode(subnode, fdto, node) { > >> >> const char *name = fdt_get_name(fdto, subnode, NULL); > >> >> int nnode; > >> >> int ret; > >> >> > >> >> nnode = fdt_add_subnode(fdt, target, name); > >> >> if (nnode == -FDT_ERR_EXISTS) { > >> >> nnode = fdt_subnode_offset(fdt, target, name); > >> >> if (nnode == -FDT_ERR_NOTFOUND) > >> >> return -FDT_ERR_INTERNAL; > >> >> } > >> >> > >> >> if (nnode < 0) > >> >> return nnode; > >> >> > >> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode); > >> >> if (ret) > >> >> return ret; > >> >> } > >> >> > >> >> return 0; > >> >> > >> >> > >> >> > >> >> } > >> >> > >> >> > >> >> > > >> >> > Regards > >> >> > /Ilias > >> >> > > > >> >> > > To repeat, if we set things up correctly and agree on the > bindings, > >> >> > > devicetree can be the unifying configuration mechanism through > the > >> >> > > whole of firmware (except for very early bits) and into the OS. > I feel > >> >> > > this will set us up very well to deal with the complexity that is > >> >> > > coming. > >> >> > > > >> >> > >> >> Regards, > >> >> Simon > > > > -- > > François-Frédéric Ozog | Director Business Development > > T: +33.67221.6485 > > francois.ozog@linaro.org | Skype: ffozog > > >
Hi Simon, On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote: > > Hi Ilias, > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > <ilias.apalodimas@linaro.org> wrote: > > > > Hi Simon, > > > > A bit late to the party, sorry! > > (Did you remember the beer? We'll probably need something stronger to sort this out :) > I am replying to this but I don't think it > is all that helpful for me to reply to a lot of things on this thread, > since I would not be adding much to my cover letter and patches) > > > > > [...] > > > > > > > > > > I really want to see what the binary case looks like since we could then > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > functionally correct from the hardware/our caller. > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > > use the device tree from build time at run time, ignoring the device > > > > tree provided to us at run time by the caller. > > > > > > Firstly I should say that I find building firmware very messy and > > > confusing these days. Lots of things to build and it's hard to find > > > the instructions. It doesn't have to be that way, but if we carry on > > > as we are, it will continue to be messy and in five years you will > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > objective here is to simplify things, bringing some consistency to the > > > different components. Binman was one effort there. I feel that putting > > > at least the U-Boot house in order, in my role as devicetree > > > maintainer (and as author of devicetree support in U-Boot back in > > > 2011), is the next step. > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > can be the unifying configuration mechanism through the whole of > > > firmware (except for very early bits) and into the OS, this will set > > > us up very well to deal with the complexity that is coming. > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > two months: > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > have its own nodes/properties in the DT. It is an abuse of the > > > devicetree standard, like the /chosen node but with less history. We > > > should sacrifice efficiency, expedience and expandability on the altar > > > of 'devicetree is a hardware description'. How do we get over that > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > for its own purposes, as well as for booting the OS. I am not saying > > > it always has to have those properties, but with existing features > > > like verified boot, SPL as well as complex firmware images where > > > U-Boot needs to be able to find things in the image, it is essential. > > > So let's just assume that we need this everywhere, since we certainly > > > need it in at least some places. > > > > > > (stop reading here if you disagree, because nothing below will make > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > OF_CONTROL :-) > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > that to the DTs that are copied over from linux isn't imho. There are > > various reasons for that. First of all syncing device trees is a huge pain > > and that's probably one of the main reasons our DTs are out of sync for a > > large number of boards. > > The point is this was fine in 2011 were we had SPL only, but the reality > > today is completely different. There's previous stage boot loaders (and > > enough cases were vendors prefer those over SPL). If that bootloader needs > > to use it's own device tree for whatever reason, imposing restrictions on > > it wrt to the device tree it has to include, and require them to have > > knowledge of U-Boot and it's internal config mechanism makes no sense not > > to mention it doesn't scale at all. > > I think the solution here may be the binman image packer. It works > from a description of the image (i.e. is data-driver) and can collect > all the pieces together. The U-Boot properties (and the ones required > by TF-A, etc.) can be added at package time. I am not sure I am following you here or why binman is relevant to this discussion. If the boot process doesn't require a FIP (e.g SPL + U-Boot proper or SPL -> EL3 -> U-Boot proper or TF-A + U-Boot) then using binman makes a lot of sense. If the boot process is TF-A -> U-Boot and requires a FIP, TF-A has it's own set of tools for preparing that [1] [2] , why would we want to teach binman FIP packaging? And if we do are you willing to keep it up to date with everything they come up with? IOW packaging the firmware is not U-Boot's responsibility, it's the vendors. Why should he not be able to choose FIP? (ST already changed that in u-boot btw). > > If you think about it, it doesn't matter what properties are in the DT > that is put into the firmware image. TF-A, for example, is presumably > reading a devicetree from flash, so what does it care if it has some > U-Boot properties in it? It doesn't, but the point here is entirely different. Today there's a number of U-Boot DTBs that are unable to boot a kernel. The direction we would like to is have the firmware provide a DTB that's usable for the kernel. Yes I know vendors mess things up and there's a correlation of the DTB and the kernel version, but let's set that aside for a moment. If we want to use a 'generic' DT then we have to make sure that whoever packages it knows what to put in there. That's why for me, it's very important to only allow *upstreamed only* DT properties for whoever ends up being responsible for the packaging. In that case you can demand TF-A to bundle U-Boot nodes in the DTB it produces if the board is supposed to use U-Boot. If those are internal only to U-Boot and not upstreamed this makes little sense to me and I don't see why people will agree to that. > > As to syncing, we have solved this using u-boot.dtsi files in U-Boot, > so I think this can be dealt with. > > > > > > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > have binman definitions, etc. So we need a way to overlay those things > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > easy. Just require every board to have an in-tree DT. It helps with > > > discoverability and documentation, anyway. That is this series. > > > > > > > Again, the board might decide for it's own reason to provide it's own DT. > > IMHO U-Boot must be able to cope with that and asking DTs to be included in > > U-Boot source is not the right way to do that, not to mention cases were > > that's completely unrealistic (e.g QEMU or a board that reads the DTB from > > it's flash). > > I think you are at step 2. See above for my response. > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > and worried about step 3) > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > flow only, or boards that sometimes use a flow) which need the DT to > > > come from a prior stage. How to handle that? IMO that is only going to > > > grow as every man and his dog get into the write-a-bootloader > > > business. > > > > And that's exactly why we have to come up with something that scales, without > > having to add a bunch of unusable DTs in U-Boot. > > In what way does this not scale? How are the DTs unusable? If there is > a standard binding, we should be fine. The keyword here is the definition of 'standard'. If standard means upstreamed to DT spec, as I said before I don't see any problem. By unusable I was referring to the QEMU DTs you are trying to push into U-Boot or the RPI one. It doesn't scale because you have to maintain and upstream all the DTs in the U-Boot tree. The story so far is merge and forget for a big number of DTs, so I find it hard to believe that everyone will start behaving and sync up their DTs. I'd much rather prefer having a central repo and force people to use that. > > > > > > We need a way to provide the U-Boot nodes/properties in a > > > form that the prior stage can consume and integrate with its build > > > system. Is TF-A the only thing being discussed here? If so, let's just > > > do it. We have the u-boot.dtsi and we can use binman to put the image > > > together, for example. Or we can get clever and create some sort of > > > overlay dtb. > > > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > > then it will need to build it in and use two devicetrees, one internal > > > and one from the prior stage....well that is not very efficient and it > > > is going to be confusing for people to figure out what U-Boot is > > > actually doing. But we actually already do that in a lot of cases > > > where U-Boot passes a DT to the kernel which is different to the one > > > it uses. So perhaps we have three devicetrees? OMG. > > > > No we don't. That's a moot point. If you separate the DTs U-Boot > > provides the internal one and inherits one 'generic'. Linux will be able to use > > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the > > DT across kernel versions, In which case there's not much you can do to > > begin with and that's already a case we have to deal with. > > Linux actually doesn't care if the U-Boot properties are in the tree, > so long as we have proper bindings. My point here is we only need > either: > > a. one devicetree, shared with Linux and U-Boot (and TF-A?) > b. two devicetrees, one for use in firmware and one for passing to Linux > > We don't need to separate out the U-Boot properties into a second (or > third) devicetree. There just isn't any point. Again if we are talking about bindings that are upstream in the spec, then we agree. Depending on the SRAM limitation we can even do (a). If the vendor messes up the DT backwards compatibility then we can do (b). If you expect TF-A and FIP to go pick up the special bindings U-Boot needs, then we disagree. > > > > > > b) Well then > > > U-Boot can have its own small devicetree with its bits and then U-Boot > > > can merge the two when it starts. Again that is not very efficient. It > > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > > its public key from there or to enable/disable the console), so > > > unified firmware config is not possible. It will get very confusing, > > > particularly for debugging U-Boot. c) Some other scheme to avoid > > > accepting step 3...please stop! > > > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > > whole cloth. What about that? Well, we are just going to have to deal > > > with that. We can easily merge in the U-Boot nodes/properties and > > > update the U-Boot CI scripts to do this, as needed, e.g. with > > > qemu-riscv64_spl. It's only one use case, although Xen might do > > > something similar. > > > > > > To my mind, that deals with both the build-time and run-time issues. > > > We have a discoverable DT in U-Boot, which should be considered the > > > source of truth for most boards. We can sync it with Linux > > > automatically with the tooling that I hope Rob Herring will come up > > > with. We can use an empty one where there really is no default, > > > although I'd argue that is making perfect an enemy of the good. > > > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > > and pick them up from somewhere else, we can do that with sufficient > > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > > > We can start slowly migrating boards and see how that works out. > > We could either use 2 device trees as you proposed, or have u-boot merge > > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer > > if linux gets handed a clean device tree without the u-boot internals in > > it, so I think 2 discrete DTs is cleaner overall. > > I know you would prefer that, but does it really matter in practice? > What is the objection, actually? > > As I mentioned on the call, I think the prior stage should do any > merging or fixing up. Trying to do that sort of thing in 'early' code > in U-Boot (or any other program, including Linux) is such a pain. With > U-Boot, for example, we don't even have any RAM available to do it > with half the time and it would dramatically increase the amount of > memory needed prior to relocation. It just isn't a very good idea to > try to do this in early code. It is also completely unnecessary, once > you get past the philosophical objections. > > If TF-A wants to be in the picture, let it deal with the implications > and responsibility thus incurred. TF-A has no right to tell U-Boot how > to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter > of the size of U-Boot. It duplicates loads of things in there. No one > will even *notice* an FDT merge function, which is actually only 70 > LOC: > Again I am repeating myself so here's a tl;dr of how I view this: 1. All DT bindings u-boot expect become part of the DT spec -- I am fine with whatever, since at this point it makes sense to say "You are booting u-boot go add whatever it expects, it's part of the spec". The prior stage boot loader can then obviously merge the DT fragments and everyone will be happy. 2. For the bindings that are not upstreamed, I'd prefer having u-boot do the fixup. Alternatively, we could provide fragments that are easy for TF-A to merge? By easy I don't mean read U-Boot code, it's .dts files, find the fragments you need and add them manually... [...] [1] https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_FW_CONFIG [2] https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot-build.html Regards /Ilias
Hi, > On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote: > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > > <ilias.apalodimas@linaro.org> wrote: .. > > Linux actually doesn't care if the U-Boot properties are in the tree, > > so long as we have proper bindings. My point here is we only need > > either: > > > > a. one devicetree, shared with Linux and U-Boot (and TF-A?) > > b. two devicetrees, one for use in firmware and one for passing to Linux > > > > We don't need to separate out the U-Boot properties into a second (or > > third) devicetree. There just isn't any point. > > Again if we are talking about bindings that are upstream in the spec, > then we agree. Depending on the SRAM limitation we can even do (a). > If the vendor messes up the DT backwards compatibility then we can do > (b). If you expect TF-A and FIP to go pick up the special bindings > U-Boot needs, then we disagree. *puts developer at board vendor hat on* Sometimes (personally I'd say usually) it isn't possible to have a backwards compatible tree. Also, like it or not, in the device tree there *are* configuration options which are not hardware dependent (eg. internal ethernet connection on the ls1028a). So a vendor doesn't necessarily need to "mess things up" to need (b). And as you know, my point is, that this device tree has to come from the distribution, it must not be compiled in into the firmware. I feel like I've repeated this far too many times. Therefore, this will be my last comment about it and I would really like to see that this - very real - scenario is treated as a valid use case and will be supported in your systemready vision. -michael
On Tue, 2 Nov 2021 at 11:07, Michael Walle <michael@walle.cc> wrote: > Hi, > > > On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote: > > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > > > <ilias.apalodimas@linaro.org> wrote: > > .. > > > > Linux actually doesn't care if the U-Boot properties are in the tree, > > > so long as we have proper bindings. My point here is we only need > > > either: > > > > > > a. one devicetree, shared with Linux and U-Boot (and TF-A?) > > > b. two devicetrees, one for use in firmware and one for passing to > Linux > > > > > > We don't need to separate out the U-Boot properties into a second (or > > > third) devicetree. There just isn't any point. > > > > Again if we are talking about bindings that are upstream in the spec, > > then we agree. Depending on the SRAM limitation we can even do (a). > > If the vendor messes up the DT backwards compatibility then we can do > > (b). If you expect TF-A and FIP to go pick up the special bindings > > U-Boot needs, then we disagree. > > *puts developer at board vendor hat on* Sometimes (personally I'd say > usually) it isn't possible to have a backwards compatible tree. Also, > like it or not, in the device tree there *are* configuration options > which are not hardware dependent (eg. internal ethernet connection on > the ls1028a). Are you referring to DPAA2 configuration to create the ethernet port itself ? This is indeed configuration. There are many ways to handle those ones. As well as SerDes configuration to make PCI lanes or MDIO lanes. Yet the two are different in nature: SerDes configuration must match board layout, so it is about "no user choice" configuration. This configuration could be statically defined and attached with the board. But it there is a SoM with a carrier board, we may need to compose that at runtime for development, or make it static build for product packaging. DPAA2 configuration is user choice driven. Those choices can be merged in the DT to be passed to the OS at runtime. There are multiple ways to deal with that, from DT overlays to U-Boot DPAA2 command line extensions that would inject the DT necessary nodes. > So a vendor doesn't necessarily need to "mess things up" > to need (b). And as you know, my point is, that this device tree has > to come from the distribution, it must not be compiled in into the > firmware. > I wouldn't bet that all distro providers will always come with a DT... > > I feel like I've repeated this far too many times. Therefore, this > will be my last comment about it and I would really like to see that > this - very real - scenario is treated as a valid use case and will be > supported in your systemready vision. > I have been building (shared it on the list) a deck to go into those details. I am almost ready to talk to it. > > -michael >
Hi Ilias, On Mon, 1 Nov 2021 at 05:05, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > Hi Simon, > > On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote: > > > > Hi Ilias, > > > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > > <ilias.apalodimas@linaro.org> wrote: > > > > > > Hi Simon, > > > > > > A bit late to the party, sorry! > > > > (Did you remember the beer? > > We'll probably need something stronger to sort this out :) Yes I agree! > > > I am replying to this but I don't think it > > is all that helpful for me to reply to a lot of things on this thread, > > since I would not be adding much to my cover letter and patches) > > > > > > > > [...] > > > > > > > > > > > > > I really want to see what the binary case looks like since we could then > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can come > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > > > > > use the device tree from build time at run time, ignoring the device > > > > > tree provided to us at run time by the caller. > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > confusing these days. Lots of things to build and it's hard to find > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > as we are, it will continue to be messy and in five years you will > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > objective here is to simplify things, bringing some consistency to the > > > > different components. Binman was one effort there. I feel that putting > > > > at least the U-Boot house in order, in my role as devicetree > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > 2011), is the next step. > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > can be the unifying configuration mechanism through the whole of > > > > firmware (except for very early bits) and into the OS, this will set > > > > us up very well to deal with the complexity that is coming. > > > > > > > > Anyway, here are the mental steps that I've gone through over the past > > > > two months: > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > have its own nodes/properties in the DT. It is an abuse of the > > > > devicetree standard, like the /chosen node but with less history. We > > > > should sacrifice efficiency, expedience and expandability on the altar > > > > of 'devicetree is a hardware description'. How do we get over that > > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > > for its own purposes, as well as for booting the OS. I am not saying > > > > it always has to have those properties, but with existing features > > > > like verified boot, SPL as well as complex firmware images where > > > > U-Boot needs to be able to find things in the image, it is essential. > > > > So let's just assume that we need this everywhere, since we certainly > > > > need it in at least some places. > > > > > > > > (stop reading here if you disagree, because nothing below will make > > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > > OF_CONTROL :-) > > > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > > that to the DTs that are copied over from linux isn't imho. There are > > > various reasons for that. First of all syncing device trees is a huge pain > > > and that's probably one of the main reasons our DTs are out of sync for a > > > large number of boards. > > > The point is this was fine in 2011 were we had SPL only, but the reality > > > today is completely different. There's previous stage boot loaders (and > > > enough cases were vendors prefer those over SPL). If that bootloader needs > > > to use it's own device tree for whatever reason, imposing restrictions on > > > it wrt to the device tree it has to include, and require them to have > > > knowledge of U-Boot and it's internal config mechanism makes no sense not > > > to mention it doesn't scale at all. > > > > I think the solution here may be the binman image packer. It works > > from a description of the image (i.e. is data-driver) and can collect > > all the pieces together. The U-Boot properties (and the ones required > > by TF-A, etc.) can be added at package time. > > I am not sure I am following you here or why binman is relevant to > this discussion. If the boot process doesn't require a FIP (e.g SPL > + U-Boot proper or SPL -> EL3 -> U-Boot proper or TF-A + U-Boot) then > using binman makes a lot of sense. If the boot process is TF-A -> > U-Boot and requires a FIP, TF-A has it's own set of tools for > preparing that [1] [2] , why would we want to teach binman FIP > packaging? And if we do are you willing to keep it up to date with > everything they come up with? IOW packaging the firmware is not > U-Boot's responsibility, it's the vendors. Why should he not be able > to choose FIP? (ST already changed that in u-boot btw). Binman is a firmware packager. It seems to be the one that is used last, to produce the final image, although I am not sure as this seems quite complicated. My view on firmware is that we should build it step by step with individual projects but then package it all at the end and Binman is designed to do the packaging. https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#motivation So I am not sure what problem FIP solves, or why it was invented, Did we need another firmware format? But if FIP is important, then yes I think support for it should be added to Binman. It will make packaging a lot easier. > > > > > If you think about it, it doesn't matter what properties are in the DT > > that is put into the firmware image. TF-A, for example, is presumably > > reading a devicetree from flash, so what does it care if it has some > > U-Boot properties in it? > > It doesn't, but the point here is entirely different. Today there's a > number of U-Boot DTBs that are unable to boot a kernel. The direction > we would like to is have the firmware provide a DTB that's usable for > the kernel. Yes I know vendors mess things up and there's a > correlation of the DTB and the kernel version, but let's set that > aside for a moment. If we want to use a 'generic' DT then we have to > make sure that whoever packages it knows what to put in there. That's > why for me, it's very important to only allow *upstreamed only* DT > properties for whoever ends up being responsible for the packaging. > In that case you can demand TF-A to bundle U-Boot nodes in the DTB it > produces if the board is supposed to use U-Boot. If those are internal > only to U-Boot and not upstreamed this makes little sense to me and I > don't see why people will agree to that. Well I think all of this is taking too much energy...I have stated my position. U-Boot needs its nodes and properties. > > > > > As to syncing, we have solved this using u-boot.dtsi files in U-Boot, > > so I think this can be dealt with. > > > > > > > > > > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > > have binman definitions, etc. So we need a way to overlay those things > > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > > easy. Just require every board to have an in-tree DT. It helps with > > > > discoverability and documentation, anyway. That is this series. > > > > > > > > > > Again, the board might decide for it's own reason to provide it's own DT. > > > IMHO U-Boot must be able to cope with that and asking DTs to be included in > > > U-Boot source is not the right way to do that, not to mention cases were > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB from > > > it's flash). > > > > I think you are at step 2. See above for my response. > > > > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > > and worried about step 3) > > > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > > flow only, or boards that sometimes use a flow) which need the DT to > > > > come from a prior stage. How to handle that? IMO that is only going to > > > > grow as every man and his dog get into the write-a-bootloader > > > > business. > > > > > > And that's exactly why we have to come up with something that scales, without > > > having to add a bunch of unusable DTs in U-Boot. > > > > In what way does this not scale? How are the DTs unusable? If there is > > a standard binding, we should be fine. > > The keyword here is the definition of 'standard'. If standard means > upstreamed to DT spec, as I said before I don't see any problem. By > unusable I was referring to the QEMU DTs you are trying to push into > U-Boot or the RPI one. It doesn't scale because you have to maintain > and upstream all the DTs in the U-Boot tree. The story so far is > merge and forget for a big number of DTs, so I find it hard to believe > that everyone will start behaving and sync up their DTs. I'd much > rather prefer having a central repo and force people to use that. Well let's see how it goes. If we can get some validation in place, then the picture should get better. > > > > > > > > > > We need a way to provide the U-Boot nodes/properties in a > > > > form that the prior stage can consume and integrate with its build > > > > system. Is TF-A the only thing being discussed here? If so, let's just > > > > do it. We have the u-boot.dtsi and we can use binman to put the image > > > > together, for example. Or we can get clever and create some sort of > > > > overlay dtb. > > > > > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > > > then it will need to build it in and use two devicetrees, one internal > > > > and one from the prior stage....well that is not very efficient and it > > > > is going to be confusing for people to figure out what U-Boot is > > > > actually doing. But we actually already do that in a lot of cases > > > > where U-Boot passes a DT to the kernel which is different to the one > > > > it uses. So perhaps we have three devicetrees? OMG. > > > > > > No we don't. That's a moot point. If you separate the DTs U-Boot > > > provides the internal one and inherits one 'generic'. Linux will be able to use > > > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the > > > DT across kernel versions, In which case there's not much you can do to > > > begin with and that's already a case we have to deal with. > > > > Linux actually doesn't care if the U-Boot properties are in the tree, > > so long as we have proper bindings. My point here is we only need > > either: > > > > a. one devicetree, shared with Linux and U-Boot (and TF-A?) > > b. two devicetrees, one for use in firmware and one for passing to Linux > > > > We don't need to separate out the U-Boot properties into a second (or > > third) devicetree. There just isn't any point. > > Again if we are talking about bindings that are upstream in the spec, > then we agree. Depending on the SRAM limitation we can even do (a). > If the vendor messes up the DT backwards compatibility then we can do > (b). If you expect TF-A and FIP to go pick up the special bindings > U-Boot needs, then we disagree. I would certainly prefer to be talking about bindings that are upstreamed, if they can be upstreamed. I sent a patch with a start on that and then a PR to the repo here: https://github.com/devicetree-org/dt-schema/pull/62 So perhaps we should hold off on this and see how progress is in a month or so. > > > > > > > > > > b) Well then > > > > U-Boot can have its own small devicetree with its bits and then U-Boot > > > > can merge the two when it starts. Again that is not very efficient. It > > > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > > > its public key from there or to enable/disable the console), so > > > > unified firmware config is not possible. It will get very confusing, > > > > particularly for debugging U-Boot. c) Some other scheme to avoid > > > > accepting step 3...please stop! > > > > > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > > > whole cloth. What about that? Well, we are just going to have to deal > > > > with that. We can easily merge in the U-Boot nodes/properties and > > > > update the U-Boot CI scripts to do this, as needed, e.g. with > > > > qemu-riscv64_spl. It's only one use case, although Xen might do > > > > something similar. > > > > > > > > To my mind, that deals with both the build-time and run-time issues. > > > > We have a discoverable DT in U-Boot, which should be considered the > > > > source of truth for most boards. We can sync it with Linux > > > > automatically with the tooling that I hope Rob Herring will come up > > > > with. We can use an empty one where there really is no default, > > > > although I'd argue that is making perfect an enemy of the good. > > > > > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > > > and pick them up from somewhere else, we can do that with sufficient > > > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > > > > > We can start slowly migrating boards and see how that works out. > > > We could either use 2 device trees as you proposed, or have u-boot merge > > > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer > > > if linux gets handed a clean device tree without the u-boot internals in > > > it, so I think 2 discrete DTs is cleaner overall. > > > > I know you would prefer that, but does it really matter in practice? > > What is the objection, actually? > > > > As I mentioned on the call, I think the prior stage should do any > > merging or fixing up. Trying to do that sort of thing in 'early' code > > in U-Boot (or any other program, including Linux) is such a pain. With > > U-Boot, for example, we don't even have any RAM available to do it > > with half the time and it would dramatically increase the amount of > > memory needed prior to relocation. It just isn't a very good idea to > > try to do this in early code. It is also completely unnecessary, once > > you get past the philosophical objections. > > > > If TF-A wants to be in the picture, let it deal with the implications > > and responsibility thus incurred. TF-A has no right to tell U-Boot how > > to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter > > of the size of U-Boot. It duplicates loads of things in there. No one > > will even *notice* an FDT merge function, which is actually only 70 > > LOC: > > > > Again I am repeating myself so here's a tl;dr of how I view this: > 1. All DT bindings u-boot expect become part of the DT spec -- I am > fine with whatever, since at this point it makes sense to say "You are > booting u-boot go add whatever it expects, it's part of the spec". > The prior stage boot loader can then obviously merge the DT fragments > and everyone will be happy. > 2. For the bindings that are not upstreamed, I'd prefer having u-boot > do the fixup. Alternatively, we could provide fragments that are easy > for TF-A to merge? By easy I don't mean read U-Boot code, it's .dts > files, find the fragments you need and add them manually... OK, well then I don't think we have anything of concern here, so long as we can get the bindings agreed. Let's see how it goes. Regards, Simon > > [...] > > [1] https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_FW_CONFIG > [2] https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot-build.html > > Regards > > /Ilias
Hi François, On Thu, 28 Oct 2021 at 10:26, François Ozog <francois.ozog@linaro.org> wrote: > > Hi Simon > > Le jeu. 28 oct. 2021 à 17:44, Simon Glass <sjg@chromium.org> a écrit : >> >> Hi François, >> >> On Thu, 28 Oct 2021 at 08:50, François Ozog <francois.ozog@linaro.org> wrote: >> > >> > Hi Simon >> > >> > Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit : >> >> >> >> Hi François, >> >> >> >> On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> wrote: >> >> > >> >> > Hi Simon, >> >> > >> >> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit : >> >> >> >> >> >> Hi Ilias, >> >> >> >> >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas >> >> >> <ilias.apalodimas@linaro.org> wrote: >> >> >> > >> >> >> > Hi Simon, >> >> >> > >> >> >> > A bit late to the party, sorry! >> >> >> >> >> >> (Did you remember the beer? I am replying to this but I don't think it >> >> >> is all that helpful for me to reply to a lot of things on this thread, >> >> >> since I would not be adding much to my cover letter and patches) >> >> >> >> >> >> > >> >> >> > [...] >> >> >> > >> >> >> > > > >> >> >> > > > I really want to see what the binary case looks like since we could then >> >> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could >> >> >> > > > then also do a rpi_arm32_defconfig too. >> >> >> > > > >> >> >> > > > I want to see less device trees in U-Boot sources, if they can come >> >> >> > > > functionally correct from the hardware/our caller. >> >> >> > > > >> >> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't >> >> >> > > > use the device tree from build time at run time, ignoring the device >> >> >> > > > tree provided to us at run time by the caller. >> >> >> > > >> >> >> > > Firstly I should say that I find building firmware very messy and >> >> >> > > confusing these days. Lots of things to build and it's hard to find >> >> >> > > the instructions. It doesn't have to be that way, but if we carry on >> >> >> > > as we are, it will continue to be messy and in five years you will >> >> >> > > need a Ph.D and a lucky charm to boot on any modern board. My >> >> >> > > objective here is to simplify things, bringing some consistency to the >> >> >> > > different components. Binman was one effort there. I feel that putting >> >> >> > > at least the U-Boot house in order, in my role as devicetree >> >> >> > > maintainer (and as author of devicetree support in U-Boot back in >> >> >> > > 2011), is the next step. >> >> >> > > >> >> >> > > If we set things up correctly and agree on the bindings, devicetree >> >> >> > > can be the unifying configuration mechanism through the whole of >> >> >> > > firmware (except for very early bits) and into the OS, this will set >> >> >> > > us up very well to deal with the complexity that is coming. >> >> >> > > >> >> >> > > Anyway, here are the mental steps that I've gone through over the past >> >> >> > > two months: >> >> >> > > >> >> >> > > Step 1: At present, some people think U-Boot is not even allowed to >> >> >> > > have its own nodes/properties in the DT. It is an abuse of the >> >> >> > > devicetree standard, like the /chosen node but with less history. We >> >> >> > > should sacrifice efficiency, expedience and expandability on the altar >> >> >> > > of 'devicetree is a hardware description'. How do we get over that >> >> >> > > one? Wel, I just think we need to accept that U-Boot uses devicetree >> >> >> > > for its own purposes, as well as for booting the OS. I am not saying >> >> >> > > it always has to have those properties, but with existing features >> >> >> > > like verified boot, SPL as well as complex firmware images where >> >> >> > > U-Boot needs to be able to find things in the image, it is essential. >> >> >> > > So let's just assume that we need this everywhere, since we certainly >> >> >> > > need it in at least some places. >> >> >> > > >> >> >> > > (stop reading here if you disagree, because nothing below will make >> >> >> > > any sense...you can still use U-Boot v2011.06 which doesn't have >> >> >> > > OF_CONTROL :-) >> >> >> > >> >> >> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding >> >> >> > that to the DTs that are copied over from linux isn't imho. There are >> >> >> > various reasons for that. First of all syncing device trees is a huge pain >> >> >> > and that's probably one of the main reasons our DTs are out of sync for a >> >> >> > large number of boards. >> >> >> > The point is this was fine in 2011 were we had SPL only, but the reality >> >> >> > today is completely different. There's previous stage boot loaders (and >> >> >> > enough cases were vendors prefer those over SPL). If that bootloader needs >> >> >> > to use it's own device tree for whatever reason, imposing restrictions on >> >> >> > it wrt to the device tree it has to include, and require them to have >> >> >> > knowledge of U-Boot and it's internal config mechanism makes no sense not >> >> >> > to mention it doesn't scale at all. >> >> >> >> >> >> I think the solution here may be the binman image packer. It works >> >> >> from a description of the image (i.e. is data-driver) and can collect >> >> >> all the pieces together. The U-Boot properties (and the ones required >> >> >> by TF-A, etc.) can be added at package time. >> >> >> >> >> >> If you think about it, it doesn't matter what properties are in the DT >> >> >> that is put into the firmware image. TF-A, for example, is presumably >> >> >> reading a devicetree from flash, so what does it care if it has some >> >> >> U-Boot properties in it? >> >> > >> >> > >> >> > I am going to change my position in all mail threads I participate. >> >> > I was trying to make patches relevant in the future and conceptually clean. That may not be the most effective position: I should just care about Linaro and its members being able to implement SystemReady concepts. >> >> > >> >> > >> >> > If you mandate U-Boot has nodes in the device tree passed to the OS, we can put DT fragment in the nt_fw_config section of the fip and merge it at boot time. So there is a solution compatible with SystemReady. >> >> > >> >> > If you want to put fake, non future proof, DT sources in the dts for platforms that are organized to provide the authoritative DT to U-Boot at runtime, that's kind of your choice (hopefully representing the rest of U-Boot community). There will be quirk code in U-Boot to redo the adaptations on its non authoritative DT that the platform previous stage firmware does (already saw one in the past month); as Mark said there will be issues over time; and it will confuse people about the role of the DT. But I am fine with it as it does not impair Linaro and its members ability to implement SystemReady way of handling DT. >> >> >> >> OK thank you. It doesn't sound like you are very on-board though. >> >> Also, you mischaracterise my intent with in-tree devicetrees. >> >> >> >> I would be happy enough for now if you could accept that U-Boot has >> >> nodes/properties of its own in the devicetree. It has been a feature >> >> of U-Boot for 10 years now. >> > >> > On SystemReady systems the DT passed to U-Boot for the OS will be assembled from the board DT and a U-Boot fragment/overlay. The board DT is free from any software/firmware aspects, just contains hardware description. The U-Boot fragment/overlay can contain any nodes it wants. The location of the bindings specification is essentially irrelevant: it could be devicetree.org, U-Boot doc or Linux kernel. Both DTs will be stored in the FIP. OEMs making their firmware will just put whatever is needed in this “dynamic config” DT. On SystemReady platforms U-Boot will always be given a DT, like on the RPI4. U-Boot will be able to ignore it obviously. That said, doing so, a platform may end-up failing compliance tests. >> > I think we need to document the above in U-Boot and refer to relevant specifications. I’ll let Ilias propose something. >> >> Hmm. So long as OF_BOARD is enabled, the devicetree will not be 'ignored'. >> >> Are you talking here about what TF-A will do? I assume so, since you >> mention FIP and I believe that is a TF-A invention. > > Yes >> >> >> Of course the image is all packaged together in fact, so binman could >> presumably merge the DTs at build time, if desired. > > Practically I don’t think so. The passed device tree will contain all authoritative information such as discovered normal memory (excluded the secure memory ranges), architectural nodes such as PSCI and other nodes coming from TEE-OS or secure partitions such as SCMI interface or firmwareTPM. > If you combine the two static parts at build time you will have to extract the runtime pieces from the DT passed to U-Boot. This could be the subject of some future discussion, perhaps, as I don't think we are talking about the same thing. I am talking about the DT packaged in the firmware, but I think you are talking about the things detected at runtime. Binman is for the first problem, not the second. Regards, Simon >> >> >> >> Regards, >> Simon >> >> >> >> >> >> >> >> >> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot, >> >> >> so I think this can be dealt with. >> >> >> >> >> >> > >> >> >> > > >> >> >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get >> >> >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch >> >> >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we >> >> >> > > have binman definitions, etc. So we need a way to overlay those things >> >> >> > > into the DT. We already support this for in-tree DTs, so IMO this is >> >> >> > > easy. Just require every board to have an in-tree DT. It helps with >> >> >> > > discoverability and documentation, anyway. That is this series. >> >> >> > > >> >> >> > >> >> >> > Again, the board might decide for it's own reason to provide it's own DT. >> >> >> > IMHO U-Boot must be able to cope with that and asking DTs to be included in >> >> >> > U-Boot source is not the right way to do that, not to mention cases were >> >> >> > that's completely unrealistic (e.g QEMU or a board that reads the DTB from >> >> >> > it's flash). >> >> >> >> >> >> I think you are at step 2. See above for my response. >> >> >> >> >> >> > >> >> >> > > (I think most of us are at the beginning of step 2, unsure about it >> >> >> > > and worried about step 3) >> >> >> > > >> >> >> > > Step 3: Ah, but there are flows (i.e. boards that use a particular >> >> >> > > flow only, or boards that sometimes use a flow) which need the DT to >> >> >> > > come from a prior stage. How to handle that? IMO that is only going to >> >> >> > > grow as every man and his dog get into the write-a-bootloader >> >> >> > > business. >> >> >> > >> >> >> > And that's exactly why we have to come up with something that scales, without >> >> >> > having to add a bunch of unusable DTs in U-Boot. >> >> >> >> >> >> In what way does this not scale? How are the DTs unusable? If there is >> >> >> a standard binding, we should be fine. >> >> >> >> >> >> > >> >> >> > > We need a way to provide the U-Boot nodes/properties in a >> >> >> > > form that the prior stage can consume and integrate with its build >> >> >> > > system. Is TF-A the only thing being discussed here? If so, let's just >> >> >> > > do it. We have the u-boot.dtsi and we can use binman to put the image >> >> >> > > together, for example. Or we can get clever and create some sort of >> >> >> > > overlay dtb. >> >> >> > > >> >> >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff >> >> >> > > then it will need to build it in and use two devicetrees, one internal >> >> >> > > and one from the prior stage....well that is not very efficient and it >> >> >> > > is going to be confusing for people to figure out what U-Boot is >> >> >> > > actually doing. But we actually already do that in a lot of cases >> >> >> > > where U-Boot passes a DT to the kernel which is different to the one >> >> >> > > it uses. So perhaps we have three devicetrees? OMG. >> >> >> > >> >> >> > No we don't. That's a moot point. If you separate the DTs U-Boot >> >> >> > provides the internal one and inherits one 'generic'. Linux will be able to use >> >> >> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the >> >> >> > DT across kernel versions, In which case there's not much you can do to >> >> >> > begin with and that's already a case we have to deal with. >> >> >> >> >> >> Linux actually doesn't care if the U-Boot properties are in the tree, >> >> >> so long as we have proper bindings. My point here is we only need >> >> >> either: >> >> >> >> >> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?) >> >> >> b. two devicetrees, one for use in firmware and one for passing to Linux >> >> >> >> >> >> We don't need to separate out the U-Boot properties into a second (or >> >> >> third) devicetree. There just isn't any point. >> >> >> >> >> >> > >> >> >> > > b) Well then >> >> >> > > U-Boot can have its own small devicetree with its bits and then U-Boot >> >> >> > > can merge the two when it starts. Again that is not very efficient. It >> >> >> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get >> >> >> > > its public key from there or to enable/disable the console), so >> >> >> > > unified firmware config is not possible. It will get very confusing, >> >> >> > > particularly for debugging U-Boot. c) Some other scheme to avoid >> >> >> > > accepting step 3...please stop! >> >> >> > > >> >> >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of >> >> >> > > whole cloth. What about that? Well, we are just going to have to deal >> >> >> > > with that. We can easily merge in the U-Boot nodes/properties and >> >> >> > > update the U-Boot CI scripts to do this, as needed, e.g. with >> >> >> > > qemu-riscv64_spl. It's only one use case, although Xen might do >> >> >> > > something similar. >> >> >> > > >> >> >> > > To my mind, that deals with both the build-time and run-time issues. >> >> >> > > We have a discoverable DT in U-Boot, which should be considered the >> >> >> > > source of truth for most boards. We can sync it with Linux >> >> >> > > automatically with the tooling that I hope Rob Herring will come up >> >> >> > > with. We can use an empty one where there really is no default, >> >> >> > > although I'd argue that is making perfect an enemy of the good. >> >> >> > > >> >> >> > > Step 5: If we get clever and want to remove them from the U-Boot tree >> >> >> > > and pick them up from somewhere else, we can do that with sufficient >> >> >> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? >> >> >> > >> >> >> > We can start slowly migrating boards and see how that works out. >> >> >> > We could either use 2 device trees as you proposed, or have u-boot merge >> >> >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer >> >> >> > if linux gets handed a clean device tree without the u-boot internals in >> >> >> > it, so I think 2 discrete DTs is cleaner overall. >> >> >> >> >> >> I know you would prefer that, but does it really matter in practice? >> >> >> What is the objection, actually? >> >> >> >> >> >> As I mentioned on the call, I think the prior stage should do any >> >> >> merging or fixing up. Trying to do that sort of thing in 'early' code >> >> >> in U-Boot (or any other program, including Linux) is such a pain. With >> >> >> U-Boot, for example, we don't even have any RAM available to do it >> >> >> with half the time and it would dramatically increase the amount of >> >> >> memory needed prior to relocation. It just isn't a very good idea to >> >> >> try to do this in early code. It is also completely unnecessary, once >> >> >> you get past the philosophical objections. >> >> >> >> >> >> If TF-A wants to be in the picture, let it deal with the implications >> >> >> and responsibility thus incurred. TF-A has no right to tell U-Boot how >> >> >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter >> >> >> of the size of U-Boot. It duplicates loads of things in there. No one >> >> >> will even *notice* an FDT merge function, which is actually only 70 >> >> >> LOC: >> >> >> >> >> >> /** >> >> >> * overlay_apply_node - Merges a node into the base device tree >> >> >> * @fdt: Base Device Tree blob >> >> >> * @target: Node offset in the base device tree to apply the fragment to >> >> >> * @fdto: Device tree overlay blob >> >> >> * @node: Node offset in the overlay holding the changes to merge >> >> >> * >> >> >> * overlay_apply_node() merges a node into a target base device tree >> >> >> * node pointed. >> >> >> * >> >> >> * This is part of the final step in the device tree overlay >> >> >> * application process, when all the phandles have been adjusted and >> >> >> * resolved and you just have to merge overlay into the base device >> >> >> * tree. >> >> >> * >> >> >> * returns: >> >> >> * 0 on success >> >> >> * Negative error code on failure >> >> >> */ >> >> >> static int overlay_apply_node(void *fdt, int target, >> >> >> void *fdto, int node) >> >> >> { >> >> >> int property; >> >> >> int subnode; >> >> >> >> >> >> fdt_for_each_property_offset(property, fdto, node) { >> >> >> const char *name; >> >> >> const void *prop; >> >> >> int prop_len; >> >> >> int ret; >> >> >> >> >> >> prop = fdt_getprop_by_offset(fdto, property, &name, >> >> >> &prop_len); >> >> >> if (prop_len == -FDT_ERR_NOTFOUND) >> >> >> return -FDT_ERR_INTERNAL; >> >> >> if (prop_len < 0) >> >> >> return prop_len; >> >> >> >> >> >> ret = fdt_setprop(fdt, target, name, prop, prop_len); >> >> >> if (ret) >> >> >> return ret; >> >> >> } >> >> >> >> >> >> fdt_for_each_subnode(subnode, fdto, node) { >> >> >> const char *name = fdt_get_name(fdto, subnode, NULL); >> >> >> int nnode; >> >> >> int ret; >> >> >> >> >> >> nnode = fdt_add_subnode(fdt, target, name); >> >> >> if (nnode == -FDT_ERR_EXISTS) { >> >> >> nnode = fdt_subnode_offset(fdt, target, name); >> >> >> if (nnode == -FDT_ERR_NOTFOUND) >> >> >> return -FDT_ERR_INTERNAL; >> >> >> } >> >> >> >> >> >> if (nnode < 0) >> >> >> return nnode; >> >> >> >> >> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode); >> >> >> if (ret) >> >> >> return ret; >> >> >> } >> >> >> >> >> >> return 0; >> >> >> >> >> >> >> >> >> >> >> >> } >> >> >> >> >> >> >> >> >> > >> >> >> > Regards >> >> >> > /Ilias >> >> >> > > >> >> >> > > To repeat, if we set things up correctly and agree on the bindings, >> >> >> > > devicetree can be the unifying configuration mechanism through the >> >> >> > > whole of firmware (except for very early bits) and into the OS. I feel >> >> >> > > this will set us up very well to deal with the complexity that is >> >> >> > > coming. >> >> >> > > >> >> >> >> >> >> Regards, >> >> >> Simon >> > >> > -- >> > François-Frédéric Ozog | Director Business Development >> > T: +33.67221.6485 >> > francois.ozog@linaro.org | Skype: ffozog >> > > > -- > François-Frédéric Ozog | Director Business Development > T: +33.67221.6485 > francois.ozog@linaro.org | Skype: ffozog >