mbox series

[00/16] fdt: Make OF_BOARD a boolean option

Message ID 20211013010120.96851-1-sjg@chromium.org
Headers show
Series fdt: Make OF_BOARD a boolean option | expand

Message

Simon Glass Oct. 13, 2021, 1:01 a.m. UTC
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
there are only three ways to obtain a devicetree:

   - OF_SEPARATE - the normal way, where the devicetree is built and
      appended to U-Boot
   - OF_EMBED - for development purposes, the devicetree is embedded in
      the ELF file (also used for EFI)
   - OF_BOARD - the board figures it out on its own

The last one is currently set up so that no devicetree is needed at all
in the U-Boot tree. Most boards do provide one, but some don't. Some
don't even provide instructions on how to boot on the board.

The problems with this approach are documented at [1].

In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
can obtain its devicetree at runtime, even it is has a devicetree built
in U-Boot. This is because U-Boot may be a second-stage bootloader and its
caller may have a better idea about the hardware available in the machine.
This is the case with a few QEMU boards, for example.

So it makes no sense to have OF_BOARD as a 'choice'. It should be an
option, available with either OF_SEPARATE or OF_EMBED.

This series makes this change, adding various missing devicetree files
(and placeholders) to make the build work.

It also provides a few qemu clean-ups discovered along the way.

This series is based on Ilias' two series for OF_HOSTFILE and
OF_PRIOR_STAGE removal.

It is available at u-boot-dm/ofb-working

[1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/


Simon Glass (16):
  arm: qemu: Mention -nographic in the docs
  arm: qemu: Explain how to extract the generate devicetree
  riscv: qemu: Explain how to extract the generate devicetree
  arm: qemu: Add a devicetree file for qemu_arm
  arm: qemu: Add a devicetree file for qemu_arm64
  riscv: qemu: Add devicetree files for qemu_riscv32/64
  arm: rpi: Add a devicetree file for rpi_4
  arm: vexpress: Add a devicetree file for juno
  arm: xenguest_arm64: Add a fake devicetree file
  arm: octeontx: Add a fake devicetree file
  arm: xilinx_versal_virt: Add a devicetree file
  arm: bcm7xxx: Add a devicetree file
  arm: qemu-ppce500: Add a devicetree file
  arm: highbank: Add a fake devicetree file
  fdt: Make OF_BOARD a bool option
  Drop CONFIG_BINMAN_STANDALONE_FDT

 Makefile                               |    3 +-
 arch/arm/dts/Makefile                  |   20 +-
 arch/arm/dts/bcm2711-rpi-4-b.dts       | 1958 ++++++++++++++++++++++++
 arch/arm/dts/bcm7xxx.dts               |   15 +
 arch/arm/dts/highbank.dts              |   14 +
 arch/arm/dts/juno-r2.dts               | 1038 +++++++++++++
 arch/arm/dts/octeontx.dts              |   14 +
 arch/arm/dts/qemu-arm.dts              |  402 +++++
 arch/arm/dts/qemu-arm64.dts            |  381 +++++
 arch/arm/dts/xenguest-arm64.dts        |   15 +
 arch/arm/dts/xilinx-versal-virt.dts    |  307 ++++
 arch/powerpc/dts/Makefile              |    1 +
 arch/powerpc/dts/qemu-ppce500.dts      |  264 ++++
 arch/riscv/dts/Makefile                |    2 +-
 arch/riscv/dts/qemu-virt.dts           |    8 -
 arch/riscv/dts/qemu-virt32.dts         |  217 +++
 arch/riscv/dts/qemu-virt64.dts         |  217 +++
 configs/bcm7260_defconfig              |    1 +
 configs/bcm7445_defconfig              |    1 +
 configs/highbank_defconfig             |    2 +-
 configs/octeontx2_95xx_defconfig       |    1 +
 configs/octeontx2_96xx_defconfig       |    1 +
 configs/octeontx_81xx_defconfig        |    1 +
 configs/octeontx_83xx_defconfig        |    1 +
 configs/qemu-ppce500_defconfig         |    2 +
 configs/qemu-riscv32_defconfig         |    1 +
 configs/qemu-riscv32_smode_defconfig   |    1 +
 configs/qemu-riscv32_spl_defconfig     |    4 +-
 configs/qemu-riscv64_defconfig         |    1 +
 configs/qemu-riscv64_smode_defconfig   |    1 +
 configs/qemu-riscv64_spl_defconfig     |    3 +-
 configs/qemu_arm64_defconfig           |    1 +
 configs/qemu_arm_defconfig             |    1 +
 configs/rpi_4_32b_defconfig            |    1 +
 configs/rpi_4_defconfig                |    1 +
 configs/rpi_arm64_defconfig            |    1 +
 configs/vexpress_aemv8a_juno_defconfig |    1 +
 configs/xenguest_arm64_defconfig       |    1 +
 configs/xilinx_versal_virt_defconfig   |    1 +
 doc/board/emulation/qemu-arm.rst       |   19 +-
 doc/board/emulation/qemu-riscv.rst     |   12 +
 dts/Kconfig                            |   27 +-
 tools/binman/binman.rst                |   20 -
 43 files changed, 4922 insertions(+), 61 deletions(-)
 create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
 create mode 100644 arch/arm/dts/bcm7xxx.dts
 create mode 100644 arch/arm/dts/highbank.dts
 create mode 100644 arch/arm/dts/juno-r2.dts
 create mode 100644 arch/arm/dts/octeontx.dts
 create mode 100644 arch/arm/dts/qemu-arm.dts
 create mode 100644 arch/arm/dts/qemu-arm64.dts
 create mode 100644 arch/arm/dts/xenguest-arm64.dts
 create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
 create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
 delete mode 100644 arch/riscv/dts/qemu-virt.dts
 create mode 100644 arch/riscv/dts/qemu-virt32.dts
 create mode 100644 arch/riscv/dts/qemu-virt64.dts

Comments

Bin Meng Oct. 13, 2021, 1:29 a.m. UTC | #1
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
Tom Rini Oct. 13, 2021, 1:34 a.m. UTC | #2
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.
Heinrich Schuchardt Oct. 13, 2021, 4:26 a.m. UTC | #3
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
>
François Ozog Oct. 13, 2021, 8:02 a.m. UTC | #4
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
Andre Przywara Oct. 13, 2021, 9:50 a.m. UTC | #5
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
>
Philippe Mathieu-Daudé Oct. 13, 2021, 12:39 p.m. UTC | #6
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
>
François Ozog Oct. 13, 2021, 1:05 p.m. UTC | #7
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
François Ozog Oct. 13, 2021, 1:06 p.m. UTC | #8
Le mer. 13 oct. 2021 à 14:41, Heinrich Schuchardt <
heinrich.schuchardt@canonical.com> a écrit :

>
>
> On 10/13/21 03:01, Simon Glass wrote:
> > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > there are only three ways to obtain a devicetree:
> >
> >     - OF_SEPARATE - the normal way, where the devicetree is built and
> >        appended to U-Boot
> >     - OF_EMBED - for development purposes, the devicetree is embedded in
> >        the ELF file (also used for EFI)
> >     - OF_BOARD - the board figures it out on its own
> >
> > The last one is currently set up so that no devicetree is needed at all
> > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > don't even provide instructions on how to boot on the board.
> >
> > The problems with this approach are documented at [1].
> >
> > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > can obtain its devicetree at runtime, even it is has a devicetree built
> > in U-Boot. This is because U-Boot may be a second-stage bootloader and
> its
> > caller may have a better idea about the hardware available in the
> machine.
> > This is the case with a few QEMU boards, for example.
> >
> > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > option, available with either OF_SEPARATE or OF_EMBED.
> >
> > This series makes this change, adding various missing devicetree files
> > (and placeholders) to make the build work.
>
> Why should we add dummy files with irrelevant content (see patch 06/16)
> to make the build work? Why don't you fix the Makefile instead?
>
+1

>
> Best regards
>
> Heinrich
>
> >
> > It also provides a few qemu clean-ups discovered along the way.
> >
> > This series is based on Ilias' two series for OF_HOSTFILE and
> > OF_PRIOR_STAGE removal.
> >
> > It is available at u-boot-dm/ofb-working
> >
> > [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >
> >
> > Simon Glass (16):
> >    arm: qemu: Mention -nographic in the docs
> >    arm: qemu: Explain how to extract the generate devicetree
> >    riscv: qemu: Explain how to extract the generate devicetree
> >    arm: qemu: Add a devicetree file for qemu_arm
> >    arm: qemu: Add a devicetree file for qemu_arm64
> >    riscv: qemu: Add devicetree files for qemu_riscv32/64
> >    arm: rpi: Add a devicetree file for rpi_4
> >    arm: vexpress: Add a devicetree file for juno
> >    arm: xenguest_arm64: Add a fake devicetree file
> >    arm: octeontx: Add a fake devicetree file
> >    arm: xilinx_versal_virt: Add a devicetree file
> >    arm: bcm7xxx: Add a devicetree file
> >    arm: qemu-ppce500: Add a devicetree file
> >    arm: highbank: Add a fake devicetree file
> >    fdt: Make OF_BOARD a bool option
> >    Drop CONFIG_BINMAN_STANDALONE_FDT
> >
> >   Makefile                               |    3 +-
> >   arch/arm/dts/Makefile                  |   20 +-
> >   arch/arm/dts/bcm2711-rpi-4-b.dts       | 1958 ++++++++++++++++++++++++
> >   arch/arm/dts/bcm7xxx.dts               |   15 +
> >   arch/arm/dts/highbank.dts              |   14 +
> >   arch/arm/dts/juno-r2.dts               | 1038 +++++++++++++
> >   arch/arm/dts/octeontx.dts              |   14 +
> >   arch/arm/dts/qemu-arm.dts              |  402 +++++
> >   arch/arm/dts/qemu-arm64.dts            |  381 +++++
> >   arch/arm/dts/xenguest-arm64.dts        |   15 +
> >   arch/arm/dts/xilinx-versal-virt.dts    |  307 ++++
> >   arch/powerpc/dts/Makefile              |    1 +
> >   arch/powerpc/dts/qemu-ppce500.dts      |  264 ++++
> >   arch/riscv/dts/Makefile                |    2 +-
> >   arch/riscv/dts/qemu-virt.dts           |    8 -
> >   arch/riscv/dts/qemu-virt32.dts         |  217 +++
> >   arch/riscv/dts/qemu-virt64.dts         |  217 +++
> >   configs/bcm7260_defconfig              |    1 +
> >   configs/bcm7445_defconfig              |    1 +
> >   configs/highbank_defconfig             |    2 +-
> >   configs/octeontx2_95xx_defconfig       |    1 +
> >   configs/octeontx2_96xx_defconfig       |    1 +
> >   configs/octeontx_81xx_defconfig        |    1 +
> >   configs/octeontx_83xx_defconfig        |    1 +
> >   configs/qemu-ppce500_defconfig         |    2 +
> >   configs/qemu-riscv32_defconfig         |    1 +
> >   configs/qemu-riscv32_smode_defconfig   |    1 +
> >   configs/qemu-riscv32_spl_defconfig     |    4 +-
> >   configs/qemu-riscv64_defconfig         |    1 +
> >   configs/qemu-riscv64_smode_defconfig   |    1 +
> >   configs/qemu-riscv64_spl_defconfig     |    3 +-
> >   configs/qemu_arm64_defconfig           |    1 +
> >   configs/qemu_arm_defconfig             |    1 +
> >   configs/rpi_4_32b_defconfig            |    1 +
> >   configs/rpi_4_defconfig                |    1 +
> >   configs/rpi_arm64_defconfig            |    1 +
> >   configs/vexpress_aemv8a_juno_defconfig |    1 +
> >   configs/xenguest_arm64_defconfig       |    1 +
> >   configs/xilinx_versal_virt_defconfig   |    1 +
> >   doc/board/emulation/qemu-arm.rst       |   19 +-
> >   doc/board/emulation/qemu-riscv.rst     |   12 +
> >   dts/Kconfig                            |   27 +-
> >   tools/binman/binman.rst                |   20 -
> >   43 files changed, 4922 insertions(+), 61 deletions(-)
> >   create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> >   create mode 100644 arch/arm/dts/bcm7xxx.dts
> >   create mode 100644 arch/arm/dts/highbank.dts
> >   create mode 100644 arch/arm/dts/juno-r2.dts
> >   create mode 100644 arch/arm/dts/octeontx.dts
> >   create mode 100644 arch/arm/dts/qemu-arm.dts
> >   create mode 100644 arch/arm/dts/qemu-arm64.dts
> >   create mode 100644 arch/arm/dts/xenguest-arm64.dts
> >   create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
> >   create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
> >   delete mode 100644 arch/riscv/dts/qemu-virt.dts
> >   create mode 100644 arch/riscv/dts/qemu-virt32.dts
> >   create mode 100644 arch/riscv/dts/qemu-virt64.dts
> >
>
François Ozog Oct. 13, 2021, 1:06 p.m. UTC | #9
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
Simon Glass Oct. 13, 2021, 2:47 p.m. UTC | #10
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
François Ozog Oct. 13, 2021, 5:34 p.m. UTC | #11
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
>
Simon Glass Oct. 13, 2021, 6:06 p.m. UTC | #12
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
Tom Rini Oct. 14, 2021, 2:56 p.m. UTC | #13
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) ?
Simon Glass Oct. 14, 2021, 3:17 p.m. UTC | #14
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
Tom Rini Oct. 14, 2021, 3:28 p.m. UTC | #15
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.
Andre Przywara Oct. 14, 2021, 4:24 p.m. UTC | #16
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
François Ozog Oct. 14, 2021, 5:48 p.m. UTC | #17
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
François Ozog Oct. 14, 2021, 5:58 p.m. UTC | #18
Le jeu. 14 oct. 2021 à 17:28, Tom Rini <trini@konsulko.com> a écrit :

> On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > Hi François,
> > > >
> > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> francois.ozog@linaro.org> wrote:
> > > > >
> > > > > Hi Simon
> > > > >
> > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a
> écrit :
> > > > >>
> > > > >> Hi Tom, Bin,François,
> > > > >>
> > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> wrote:
> > > > >> >
> > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > >> > > Hi Simon,
> > > > >> > >
> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org>
> wrote:
> > > > >> > > >
> > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and
> OF_HOSTFILE so
> > > > >> > > > there are only three ways to obtain a devicetree:
> > > > >> > > >
> > > > >> > > >    - OF_SEPARATE - the normal way, where the devicetree is
> built and
> > > > >> > > >       appended to U-Boot
> > > > >> > > >    - OF_EMBED - for development purposes, the devicetree is
> embedded in
> > > > >> > > >       the ELF file (also used for EFI)
> > > > >> > > >    - OF_BOARD - the board figures it out on its own
> > > > >> > > >
> > > > >> > > > The last one is currently set up so that no devicetree is
> needed at all
> > > > >> > > > in the U-Boot tree. Most boards do provide one, but some
> don't. Some
> > > > >> > > > don't even provide instructions on how to boot on the board.
> > > > >> > > >
> > > > >> > > > The problems with this approach are documented at [1].
> > > > >> > > >
> > > > >> > > > In practice, OF_BOARD is not really distinct from
> OF_SEPARATE. Any board
> > > > >> > > > can obtain its devicetree at runtime, even it is has a
> devicetree built
> > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage
> bootloader and its
> > > > >> > > > caller may have a better idea about the hardware available
> in the machine.
> > > > >> > > > This is the case with a few QEMU boards, for example.
> > > > >> > > >
> > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It
> should be an
> > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > >> > > >
> > > > >> > > > This series makes this change, adding various missing
> devicetree files
> > > > >> > > > (and placeholders) to make the build work.
> > > > >> > >
> > > > >> > > Adding device trees that are never used sounds like a hack to
> me.
> > > > >> > >
> > > > >> > > For QEMU, device tree is dynamically generated on the fly
> based on
> > > > >> > > command line parameters, and the device tree you put in this
> series
> > > > >> > > has various hardcoded <phandle> values which normally do not
> show up
> > > > >> > > in hand-written dts files.
> > > > >> > >
> > > > >> > > I am not sure I understand the whole point of this.
> > > > >> >
> > > > >> > I am also confused and do not like the idea of adding device
> trees for
> > > > >> > platforms that are capable of and can / do have a device tree
> to give us
> > > > >> > at run time.
> > > > >>
> > > > >> (I'll just reply to this one email, since the same points applies
> to
> > > > >> all replies I think)
> > > > >>
> > > > >> I have been thinking about this and discussing it with people for
> a
> > > > >> few months now. I've been signalling a change like this for over a
> > > > >> month now, on U-Boot contributor calls and in discussions with
> Linaro
> > > > >> people. I sent a patch (below) to try to explain things. I hope
> it is
> > > > >> not a surprise!
> > > > >>
> > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > > >> Ilias' series and this one we can get ourselves on a stronger
> footing.
> > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > > >> For more context:
> > > > >>
> > > > >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > >>
> > > > >> BTW I did suggest to QEMU ARM that they support a way of adding
> the
> > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > >> maintainer would prefer there was no special support even for
> booting
> > > > >> Linux directly!)
> > > > >
> > > > > i understand their point of view and agree with it.
> > > > >>
> > > > >> But in any case it doesn't really help U-Boot. I
> > > > >> think the path forward might be to run QEMU twice, once to get its
> > > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > > >> properties in it, if people want to use U-Boot features.
> > > > >>
> > > > >> I do strongly believe that OF_BOARD must be a run-time option,
> not a
> > > > >> build-time one. It creates all sorts of problems and obscurity
> which
> > > > >> have taken months to unpick. See the above patch for the
> rationale.
> > > > >>
> > > > >> To add to that rationale, OF_BOARD needs to be an option
> available to
> > > > >> any board. At some point in the future it may become a common way
> > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> devicetree
> > > > >> to it. It doesn't make any sense to have people decide whether or
> not
> > > > >> to set OF_BOARD at build time, thus affecting how the image is put
> > > > >> together. We'll end up with different U-Boot build targets like
> > > > >> capricorn, capricorn_of_board and the like. It should be obvious
> where
> > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > > > >> option, perhaps enabled by most/all boards, so that this sort of
> build
> > > > >> explosion is not needed.
> > > > >
> > > > > If you mean that when boards are by construction providing a DTB
> to U-Boot then I agree very much. But I don’t understand how the patch set
> supports it as it puts dts files for those boards to be built.
> > > > >>
> > > > >> U-Boot needs to be flexible enough to
> > > > >> function correctly in whatever runtime environment in which it
> finds
> > > > >> itself.
> > > > >>
> > > > >> Also as binman is pressed into service more and more to build the
> > > > >> complex firmware images that are becoming fashionable, it needs a
> > > > >> definition (in the devicetree) that describes how to create the
> image.
> > > > >> We can't support that unless we are building a devicetree, nor
> can the
> > > > >> running program access the image layout without that information.
> > > > >>
> > > > >> François's point about 'don't use this with any kernel' is
> > > > >> germane...but of course I am not suggesting doing that, since
> OF_BOARD
> > > > >> is, still, enabled. We already use OF_BOARD for various boards
> that
> > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> example
> > > > >> (as I said in the cover letter "Most boards do provide one, but
> some
> > > > >> don't."). So this series is just completing the picture by
> enforcing
> > > > >> that *some sort* of devicetree is always present.
> > > > >
> > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > >
> > > > I think the key point that will get you closer to where I am on this
> > > > issue, is that OF_BOARD needs to be a run-time option. At present it
> > > > has build-time effects and this is quite wrong. If you go through all
> > > > the material I have written on this I think I have motivated that
> very
> > > > clearly.
> > > >
> > > > Another big issue is that I believe we need ONE devicetree for
> U-Boot,
> > > > not two that get merged by U-Boot. Again I have gone through that in
> a
> > > > lot of detail.
> > >
> > > I have a long long reply to your first reply here saved, but, maybe
> > > here's the biggest sticking point.  To be clear, you agree that U-Boot
> > > needs to support being passed a device tree to use, at run time, yes?
> >
> > Yes. The OF_BOARD feature provides this.
> >
> > >
> > > And in that case, would not be using the "fake" tree we built in?
> >
> > Not at runtime.
>
> OK.
>
> > > So is the sticking point here that we really have two classes of
> > > devices, one class where we will never ever be given the device tree at
> > > run time (think BeagleBone Black) and one where we will always be given
> > > one at run time (think Raspberry Pi) ?
> >
> > I'm not sure it will be that black and white. I suspect there will be
> > (many) boards which can boot happily with the U-Boot devicetree but
> > can also accept one at runtime, if provided. For example, you may want
> > to boot with or without TF-A or some other, earlier stage.
>
> I'm not sure I see the value in making this a gray area.  There's very
> much a class of "never" boards.  There's also the class of "can" today.
> Maybe as part of a developer iterative flow it would be nice to not have
> to re-flash the prior stage to change a DT, and just do it in U-Boot
> until things are happy, but I'm not sure what the use case is for
> overriding the previous stage.
>
> Especially since the pushback on this series I think has all been "why
> are we copying in a tree to build with?  We don't want to use it at run
> time!".  And then softer push back like "Well, U-Boot says we have to
> include the device tree file here, but we won't use it...".
>
> > I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
> > provided a way to entirely omit a devicetree from U-Boot, thus making
> > things like binman and U-Boot /config impossible, for example. So I
> > want to claw that back, so there is always some sort of devicetree in
> > U-Boot, as we have for rpi_3, etc.
>
> I really want to see what the binary case looks like since we could then
> kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> then also do a rpi_arm32_defconfig too.
>
> I want to see less device trees in U-Boot sources, if they can come
> functionally correct from the hardware/our caller.
>
> And I'm not seeing how we make use of "U-Boot /config" if we also don't
> use the device tree from build time at run time, ignoring the device
> tree provided to us at run time by the caller.

+1
if there is a complex build problem to solve when no DT is needed when
OF_BOARD is needed i could agree to temporarily have a void.dts like

/dts-v1/;
/ {
/* required to pass build until proper makefike for OF_BOARD */
};

But not pseudo dts for boards that provide a DT to U-Boot. The pseudo dts
are good for reference in the documentation part of the tree.


>
> --
> Tom
>
François Ozog Oct. 14, 2021, 6:12 p.m. UTC | #19
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
>
Simon Glass Oct. 14, 2021, 9 p.m. UTC | #20
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
Simon Glass Oct. 15, 2021, 6:03 p.m. UTC | #21
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
Ilias Apalodimas Oct. 26, 2021, 6:46 a.m. UTC | #22
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
Tom Rini Oct. 27, 2021, 12:48 p.m. UTC | #23
On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> Hi all,
> 
> On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > Hi François,
> > > > >
> > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
> > > > > >
> > > > > > Hi Simon
> > > > > >
> > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> > > > > >>
> > > > > >> Hi Tom, Bin,François,
> > > > > >>
> > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> > > > > >> >
> > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > >> > > Hi Simon,
> > > > > >> > >
> > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > > > > >> > > >
> > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > > >> > > > there are only three ways to obtain a devicetree:
> > > > > >> > > >
> > > > > >> > > >    - OF_SEPARATE - the normal way, where the devicetree is built and
> > > > > >> > > >       appended to U-Boot
> > > > > >> > > >    - OF_EMBED - for development purposes, the devicetree is embedded in
> > > > > >> > > >       the ELF file (also used for EFI)
> > > > > >> > > >    - OF_BOARD - the board figures it out on its own
> > > > > >> > > >
> > > > > >> > > > The last one is currently set up so that no devicetree is needed at all
> > > > > >> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > > >> > > > don't even provide instructions on how to boot on the board.
> > > > > >> > > >
> > > > > >> > > > The problems with this approach are documented at [1].
> > > > > >> > > >
> > > > > >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > > >> > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > > >> > > > caller may have a better idea about the hardware available in the machine.
> > > > > >> > > > This is the case with a few QEMU boards, for example.
> > > > > >> > > >
> > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > >> > > >
> > > > > >> > > > This series makes this change, adding various missing devicetree files
> > > > > >> > > > (and placeholders) to make the build work.
> > > > > >> > >
> > > > > >> > > Adding device trees that are never used sounds like a hack to me.
> > > > > >> > >
> > > > > >> > > For QEMU, device tree is dynamically generated on the fly based on
> > > > > >> > > command line parameters, and the device tree you put in this series
> > > > > >> > > has various hardcoded <phandle> values which normally do not show up
> > > > > >> > > in hand-written dts files.
> > > > > >> > >
> > > > > >> > > I am not sure I understand the whole point of this.
> > > > > >> >
> > > > > >> > I am also confused and do not like the idea of adding device trees for
> > > > > >> > platforms that are capable of and can / do have a device tree to give us
> > > > > >> > at run time.
> > > > > >>
> > > > > >> (I'll just reply to this one email, since the same points applies to
> > > > > >> all replies I think)
> > > > > >>
> > > > > >> I have been thinking about this and discussing it with people for a
> > > > > >> few months now. I've been signalling a change like this for over a
> > > > > >> month now, on U-Boot contributor calls and in discussions with Linaro
> > > > > >> people. I sent a patch (below) to try to explain things. I hope it is
> > > > > >> not a surprise!
> > > > > >>
> > > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > > > >> Ilias' series and this one we can get ourselves on a stronger footing.
> > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > > > >> For more context:
> > > > > >>
> > > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > >>
> > > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > >> maintainer would prefer there was no special support even for booting
> > > > > >> Linux directly!)
> > > > > >
> > > > > > i understand their point of view and agree with it.
> > > > > >>
> > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > >> think the path forward might be to run QEMU twice, once to get its
> > > > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > > > >> properties in it, if people want to use U-Boot features.
> > > > > >>
> > > > > >> I do strongly believe that OF_BOARD must be a run-time option, not a
> > > > > >> build-time one. It creates all sorts of problems and obscurity which
> > > > > >> have taken months to unpick. See the above patch for the rationale.
> > > > > >>
> > > > > >> To add to that rationale, OF_BOARD needs to be an option available to
> > > > > >> any board. At some point in the future it may become a common way
> > > > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> > > > > >> to it. It doesn't make any sense to have people decide whether or not
> > > > > >> to set OF_BOARD at build time, thus affecting how the image is put
> > > > > >> together. We'll end up with different U-Boot build targets like
> > > > > >> capricorn, capricorn_of_board and the like. It should be obvious where
> > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > > > > >> option, perhaps enabled by most/all boards, so that this sort of build
> > > > > >> explosion is not needed.
> > > > > >
> > > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set  supports it as it puts dts files for those boards to be built.
> > > > > >>
> > > > > >> U-Boot needs to be flexible enough to
> > > > > >> function correctly in whatever runtime environment in which it finds
> > > > > >> itself.
> > > > > >>
> > > > > >> Also as binman is pressed into service more and more to build the
> > > > > >> complex firmware images that are becoming fashionable, it needs a
> > > > > >> definition (in the devicetree) that describes how to create the image.
> > > > > >> We can't support that unless we are building a devicetree, nor can the
> > > > > >> running program access the image layout without that information.
> > > > > >>
> > > > > >> François's point about 'don't use this with any kernel' is
> > > > > >> germane...but of course I am not suggesting doing that, since OF_BOARD
> > > > > >> is, still, enabled. We already use OF_BOARD for various boards that
> > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> > > > > >> (as I said in the cover letter "Most boards do provide one, but some
> > > > > >> don't."). So this series is just completing the picture by enforcing
> > > > > >> that *some sort* of devicetree is always present.
> > > > > >
> > > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > > >
> > > > > I think the key point that will get you closer to where I am on this
> > > > > issue, is that OF_BOARD needs to be a run-time option. At present it
> > > > > has build-time effects and this is quite wrong. If you go through all
> > > > > the material I have written on this I think I have motivated that very
> > > > > clearly.
> > > > >
> > > > > Another big issue is that I believe we need ONE devicetree for U-Boot,
> > > > > not two that get merged by U-Boot. Again I have gone through that in a
> > > > > lot of detail.
> > > >
> > > > I have a long long reply to your first reply here saved, but, maybe
> > > > here's the biggest sticking point.  To be clear, you agree that U-Boot
> > > > needs to support being passed a device tree to use, at run time, yes?
> > >
> > > Yes. The OF_BOARD feature provides this.
> > >
> > > >
> > > > And in that case, would not be using the "fake" tree we built in?
> > >
> > > Not at runtime.
> >
> > OK.
> >
> > > > So is the sticking point here that we really have two classes of
> > > > devices, one class where we will never ever be given the device tree at
> > > > run time (think BeagleBone Black) and one where we will always be given
> > > > one at run time (think Raspberry Pi) ?
> > >
> > > I'm not sure it will be that black and white. I suspect there will be
> > > (many) boards which can boot happily with the U-Boot devicetree but
> > > can also accept one at runtime, if provided. For example, you may want
> > > to boot with or without TF-A or some other, earlier stage.
> >
> > I'm not sure I see the value in making this a gray area.  There's very
> > much a class of "never" boards.  There's also the class of "can" today.
> > Maybe as part of a developer iterative flow it would be nice to not have
> > to re-flash the prior stage to change a DT, and just do it in U-Boot
> > until things are happy, but I'm not sure what the use case is for
> > overriding the previous stage.
> >
> > Especially since the pushback on this series I think has all been "why
> > are we copying in a tree to build with?  We don't want to use it at run
> > time!".  And then softer push back like "Well, U-Boot says we have to
> > include the device tree file here, but we won't use it...".
> 
> See below.
> 
> >
> > > I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
> > > provided a way to entirely omit a devicetree from U-Boot, thus making
> > > things like binman and U-Boot /config impossible, for example. So I
> > > want to claw that back, so there is always some sort of devicetree in
> > > U-Boot, as we have for rpi_3, etc.
> >
> > I really want to see what the binary case looks like since we could then
> > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > then also do a rpi_arm32_defconfig too.
> >
> > I want to see less device trees in U-Boot sources, if they can come
> > functionally correct from the hardware/our caller.
> >
> > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > use the device tree from build time at run time, ignoring the device
> > tree provided to us at run time by the caller.
> 
> Firstly I should say that I find building firmware very messy and
> confusing these days. Lots of things to build and it's hard to find
> the instructions. It doesn't have to be that way, but if we carry on
> as we are, it will continue to be messy and in five years you will
> need a Ph.D and a lucky charm to boot on any modern board. My
> objective here is to simplify things, bringing some consistency to the
> different components. Binman was one effort there. I feel that putting
> at least the U-Boot house in order, in my role as devicetree
> maintainer (and as author of devicetree support in U-Boot back in
> 2011), is the next step.

Yes, it's Not Great.  I don't like my handful of build-BOARD.sh scripts
that know where to grab other known-good binaries of varying licenses
that are needed to assemble something that boots.

> If we set things up correctly and agree on the bindings, devicetree
> can be the unifying configuration mechanism through the whole of
> firmware (except for very early bits) and into the OS, this will set
> us up very well to deal with the complexity that is coming.
> 
> Anyway, here are the mental steps that I've gone through over the past
> two months:
> 
> Step 1: At present, some people think U-Boot is not even allowed to
> have its own nodes/properties in the DT. It is an abuse of the
> devicetree standard, like the /chosen node but with less history. We
> should sacrifice efficiency, expedience and expandability on the altar
> of 'devicetree is a hardware description'. How do we get over that
> one? Wel, I just think we need to accept that U-Boot uses devicetree
> for its own purposes, as well as for booting the OS. I am not saying

Yes, we need to have properties present in the device tree, and just
like how "linux," is a valid vendor prefix for the linux kernel (but not
used I would expect by the BSD families) we have cases that need
"u-boot," properties.

> it always has to have those properties, but with existing features
> like verified boot, SPL as well as complex firmware images where
> U-Boot needs to be able to find things in the image, it is essential.
> So let's just assume that we need this everywhere, since we certainly
> need it in at least some places.

No, we can't / shouldn't assume we need this everywhere.  A lot of
places? Yes.  But some features are going to be optional.  A valid must
be supported use case is something like a Pi where the hardware gives us
a device tree, the tree is correct and some features in U-Boot aren't
needed (SPL) nor possibly supported immediately (verified boot).  We can
go off on a tangent about how useful it would be to have HW platforms
that are both common and can demonstrate a number of features, but
that's its own problem to solve.

> (stop reading here if you disagree, because nothing below will make
> any sense...you can still use U-Boot v2011.06 which doesn't have
> OF_CONTROL :-)
> 
> Step 2: Assume U-Boot has its own nodes/properties. How do they get
> there? Well, we have u-boot.dtsi files for that (the 2016 patch
> "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> have binman definitions, etc. So we need a way to overlay those things
> into the DT. We already support this for in-tree DTs, so IMO this is
> easy. Just require every board to have an in-tree DT. It helps with
> discoverability and documentation, anyway. That is this series.
>
> (I think most of us are at the beginning of step 2, unsure about it
> and worried about step 3)
> 
> Step 3: Ah, but there are flows (i.e. boards that use a particular
> flow only, or boards that sometimes use a flow) which need the DT to
> come from a prior stage. How to handle that? IMO that is only going to
> grow as every man and his dog get into the write-a-bootloader
> business. We need a way to provide the U-Boot nodes/properties in a
> form that the prior stage can consume and integrate with its build
> system. Is TF-A the only thing being discussed here? If so, let's just
> do it. We have the u-boot.dtsi and we can use binman to put the image
> together, for example. Or we can get clever and create some sort of
> overlay dtb.
> 
> Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> then it will need to build it in and use two devicetrees, one internal
> and one from the prior stage....well that is not very efficient and it
> is going to be confusing for people to figure out what U-Boot is
> actually doing. But we actually already do that in a lot of cases
> where U-Boot passes a DT to the kernel which is different to the one
> it uses. So perhaps we have three devicetrees? OMG. b) Well then
> U-Boot can have its own small devicetree with its bits and then U-Boot
> can merge the two when it starts. Again that is not very efficient. It
> means that U-Boot cannot be controlled by the prior stage (e.g. to get
> its public key from there or to enable/disable the console), so
> unified firmware config is not possible. It will get very confusing,
> particularly for debugging U-Boot. c) Some other scheme to avoid
> accepting step 3...please stop!

How the nodes should get there is how the rest of the nodes in a system
get there.  Bindings are submitted and reviewed.  The authoritative
source of the dtses in question then has them, like any other property.

> Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> whole cloth. What about that? Well, we are just going to have to deal
> with that. We can easily merge in the U-Boot nodes/properties and
> update the U-Boot CI scripts to do this, as needed, e.g. with
> qemu-riscv64_spl. It's only one use case, although Xen might do
> something similar.
> 
> To my mind, that deals with both the build-time and run-time issues.
> We have a discoverable DT in U-Boot, which should be considered the
> source of truth for most boards. We can sync it with Linux
> automatically with the tooling that I hope Rob Herring will come up
> with. We can use an empty one where there really is no default,
> although I'd argue that is making perfect an enemy of the good.
> 
> Step 5: If we get clever and want to remove them from the U-Boot tree
> and pick them up from somewhere else, we can do that with sufficient
> tooling. Perhaps we should set a timeline for that? A year? Two? Six?

These last two paragraphs condense what I think is honestly close to a
decade of debate / discussion down to a fiat "U-Boot will have the DTS
files".  I don't want that.  I don't think any of the other projects
that want to leverage DTS files want that.

> To repeat, if we set things up correctly and agree on the bindings,
> devicetree can be the unifying configuration mechanism through the
> whole of firmware (except for very early bits) and into the OS. I feel
> this will set us up very well to deal with the complexity that is
> coming.

Sure, it could.  But that doesn't mean that U-Boot is where the dts
files live.
Tom Rini Oct. 27, 2021, 12:59 p.m. UTC | #24
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?
François Ozog Oct. 27, 2021, 1:15 p.m. UTC | #25
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
>
Heinrich Schuchardt Oct. 27, 2021, 1:23 p.m. UTC | #26
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
> 
>
François Ozog Oct. 27, 2021, 1:30 p.m. UTC | #27
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
>
Tom Rini Oct. 27, 2021, 1:38 p.m. UTC | #28
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.
Ilias Apalodimas Oct. 27, 2021, 1:47 p.m. UTC | #29
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
François Ozog Oct. 27, 2021, 1:48 p.m. UTC | #30
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
>
Tom Rini Oct. 27, 2021, 2:26 p.m. UTC | #31
On Wed, Oct 27, 2021 at 04:47:55PM +0300, Ilias Apalodimas wrote:
> Hi trying to reply to all at the same time!
> 
> On Wed, Oct 27, 2021 at 09:38:40AM -0400, Tom Rini wrote:
> > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> > > Hi Tom,
> > > 
> > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote:
> > > 
> > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > > > Hi Simon,
> > > > >
> > > > > A bit late to the party, sorry!
> > > > >
> > > > > [...]
> > > > >
> > > > > > >
> > > > > > > I really want to see what the binary case looks like since we could
> > > > then
> > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > > > > then also do a rpi_arm32_defconfig too.
> > > > > > >
> > > > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > > > functionally correct from the hardware/our caller.
> > > > > > >
> > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > > > don't
> > > > > > > use the device tree from build time at run time, ignoring the device
> > > > > > > tree provided to us at run time by the caller.
> > > > > >
> > > > > > Firstly I should say that I find building firmware very messy and
> > > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > > > as we are, it will continue to be messy and in five years you will
> > > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > > objective here is to simplify things, bringing some consistency to the
> > > > > > different components. Binman was one effort there. I feel that putting
> > > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > > 2011), is the next step.
> > > > > >
> > > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > > can be the unifying configuration mechanism through the whole of
> > > > > > firmware (except for very early bits) and into the OS, this will set
> > > > > > us up very well to deal with the complexity that is coming.
> > > > > >
> > > > > > Anyway, here are the mental steps that I've gone through over the past
> > > > > > two months:
> > > > > >
> > > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > > > devicetree standard, like the /chosen node but with less history. We
> > > > > > should sacrifice efficiency, expedience and expandability on the altar
> > > > > > of 'devicetree is a hardware description'. How do we get over that
> > > > > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > > > > for its own purposes, as well as for booting the OS. I am not saying
> > > > > > it always has to have those properties, but with existing features
> > > > > > like verified boot, SPL as well as complex firmware images where
> > > > > > U-Boot needs to be able to find things in the image, it is essential.
> > > > > > So let's just assume that we need this everywhere, since we certainly
> > > > > > need it in at least some places.
> > > > > >
> > > > > > (stop reading here if you disagree, because nothing below will make
> > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > > > OF_CONTROL :-)
> > > > >
> > > > > Having U-Boot keep it's *internal* config state in DTs is fine.  Adding
> > > > > that to the DTs that are copied over from linux isn't imho.  There are
> > > > > various reasons for that.  First of all syncing device trees is a huge
> > > > pain
> > > > > and that's probably one of the main reasons our DTs are out of sync for a
> > > > > large number of boards.
> > > >
> > > > This re-sync is only a pain because:
> > > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> > > >    NOT SUPPOSED TO.
> > > > 2. DTS files are getting closer to being the super stable API that has
> > > >    been promised now that there's validation tools.
> 
> Agree on both, but still this is the reality we have to deal with right now
> 
> > > >
> > > > Some SoCs, like stm32 are doing an amazing job and keeping things in
> > > > sync, every release.  Others like NXP are violating rule #1.
> > > 
> > > With NXP commitment to SystemReady on some IMX8 boards, I think this is
> > > changing,
> > > at least for the SystemReady boards.
> > 
> > I'd really like to see some progress (as would the other non-NXP folks
> > working on NXP SoCs) in that regard.
> > 
> > > > Still
> > > > others like some TI platforms get bit by #2 (I solved one of these, and
> > > > need to cycle back to the one you and I talked about on IRC a while
> > > > back, I bet it's another node name dash changed to underbar).
> > > >
> > > > > The point is this was fine in 2011 were we had SPL only,  but the reality
> > > > > today is completely different.  There's previous stage boot loaders (and
> > > > > enough cases were vendors prefer those over SPL).  If that bootloader
> > > > needs
> > > > > to use it's own device tree for whatever reason,  imposing restrictions
> > > > on
> > > > > it wrt to the device tree it has to include,  and require them to have
> > > > > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > > > > to mention it doesn't scale at all.
> > > >
> > > > If you are passing the full device tree around, a few more
> > > > nodes/properties aren't going to make the situation worse.  If we're
> > > > talking about a 60 kilobyte blob one more kilobyte isn't where we call
> > > > the line, especially since if we wait another 6 months it'll be a 62
> > > > kilobyte file coming in from Linux instead.
> > >
> > > This is not about size but about firmware supply chain organization.
> > 
> > That's great since it means we just need the bindings reviewed then
> > everyone can pass whatever everyone else needs.
> > 
> 
> Size here is not my concern.  If the bindings u-boot expects gets
> upstreamed I am obviously fine with the previous stage bootloader passing
> them over.  What I strongly disagree,  is *demand* the previous stage boot
> loader have knowledge about them if they are not in upstream.

I also agree that bindings MUST be upstreamed for there to be a
reasonable expectation that any other project (or human creating a dts)
be adding them, either statically or any sort of run-time modification
(think memory information, this gets fixed up at run-time often still).

And it may end up being zero "u-boot,FOO" bindings where this is the
case.  Or it may end up being related to secure / verified boot stuff
only.
Tom Rini Oct. 27, 2021, 2:30 p.m. UTC | #32
On Wed, Oct 27, 2021 at 03:48:48PM +0200, François Ozog wrote:
> On Wed, 27 Oct 2021 at 15:38, Tom Rini <trini@konsulko.com> wrote:
> 
> > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> > > Hi Tom,
> > >
> > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > > > Hi Simon,
> > > > >
> > > > > A bit late to the party, sorry!
> > > > >
> > > > > [...]
> > > > >
> > > > > > >
> > > > > > > I really want to see what the binary case looks like since we
> > could
> > > > then
> > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> > could
> > > > > > > then also do a rpi_arm32_defconfig too.
> > > > > > >
> > > > > > > I want to see less device trees in U-Boot sources, if they can
> > come
> > > > > > > functionally correct from the hardware/our caller.
> > > > > > >
> > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > > > don't
> > > > > > > use the device tree from build time at run time, ignoring the
> > device
> > > > > > > tree provided to us at run time by the caller.
> > > > > >
> > > > > > Firstly I should say that I find building firmware very messy and
> > > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > > the instructions. It doesn't have to be that way, but if we carry
> > on
> > > > > > as we are, it will continue to be messy and in five years you will
> > > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > > objective here is to simplify things, bringing some consistency to
> > the
> > > > > > different components. Binman was one effort there. I feel that
> > putting
> > > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > > 2011), is the next step.
> > > > > >
> > > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > > can be the unifying configuration mechanism through the whole of
> > > > > > firmware (except for very early bits) and into the OS, this will
> > set
> > > > > > us up very well to deal with the complexity that is coming.
> > > > > >
> > > > > > Anyway, here are the mental steps that I've gone through over the
> > past
> > > > > > two months:
> > > > > >
> > > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > > > devicetree standard, like the /chosen node but with less history.
> > We
> > > > > > should sacrifice efficiency, expedience and expandability on the
> > altar
> > > > > > of 'devicetree is a hardware description'. How do we get over that
> > > > > > one? Wel, I just think we need to accept that U-Boot uses
> > devicetree
> > > > > > for its own purposes, as well as for booting the OS. I am not
> > saying
> > > > > > it always has to have those properties, but with existing features
> > > > > > like verified boot, SPL as well as complex firmware images where
> > > > > > U-Boot needs to be able to find things in the image, it is
> > essential.
> > > > > > So let's just assume that we need this everywhere, since we
> > certainly
> > > > > > need it in at least some places.
> > > > > >
> > > > > > (stop reading here if you disagree, because nothing below will make
> > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > > > OF_CONTROL :-)
> > > > >
> > > > > Having U-Boot keep it's *internal* config state in DTs is fine.
> > Adding
> > > > > that to the DTs that are copied over from linux isn't imho.  There
> > are
> > > > > various reasons for that.  First of all syncing device trees is a
> > huge
> > > > pain
> > > > > and that's probably one of the main reasons our DTs are out of sync
> > for a
> > > > > large number of boards.
> > > >
> > > > This re-sync is only a pain because:
> > > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> > > >    NOT SUPPOSED TO.
> > > > 2. DTS files are getting closer to being the super stable API that has
> > > >    been promised now that there's validation tools.
> > > >
> > > > Some SoCs, like stm32 are doing an amazing job and keeping things in
> > > > sync, every release.  Others like NXP are violating rule #1.
> > >
> > > With NXP commitment to SystemReady on some IMX8 boards, I think this is
> > > changing,
> > > at least for the SystemReady boards.
> >
> > I'd really like to see some progress (as would the other non-NXP folks
> > working on NXP SoCs) in that regard.
> >
> > > > Still
> > > > others like some TI platforms get bit by #2 (I solved one of these, and
> > > > need to cycle back to the one you and I talked about on IRC a while
> > > > back, I bet it's another node name dash changed to underbar).
> > > >
> > > > > The point is this was fine in 2011 were we had SPL only,  but the
> > reality
> > > > > today is completely different.  There's previous stage boot loaders
> > (and
> > > > > enough cases were vendors prefer those over SPL).  If that bootloader
> > > > needs
> > > > > to use it's own device tree for whatever reason,  imposing
> > restrictions
> > > > on
> > > > > it wrt to the device tree it has to include,  and require them to
> > have
> > > > > knowledge of U-Boot and it's internal config mechanism makes no
> > sense not
> > > > > to mention it doesn't scale at all.
> > > >
> > > > If you are passing the full device tree around, a few more
> > > > nodes/properties aren't going to make the situation worse.  If we're
> > > > talking about a 60 kilobyte blob one more kilobyte isn't where we call
> > > > the line, especially since if we wait another 6 months it'll be a 62
> > > > kilobyte file coming in from Linux instead.
> > >
> > > This is not about size but about firmware supply chain organization.
> >
> > That's great since it means we just need the bindings reviewed then
> > everyone can pass whatever everyone else needs.
> >
> > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"),
> > we
> > > > > > have binman definitions, etc. So we need a way to overlay those
> > things
> > > > > > into the DT. We already support this for in-tree DTs, so IMO this
> > is
> > > > > > easy. Just require every board to have an in-tree DT. It helps with
> > > > > > discoverability and documentation, anyway. That is this series.
> > > > >
> > > > > Again, the board might decide for it's own reason to provide it's own
> > > > DT.
> > > > > IMHO U-Boot must be able to cope with that and asking DTs to be
> > included
> > > > in
> > > > > U-Boot source is not the right way to do that,  not to mention cases
> > were
> > > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> > > > from
> > > > > it's flash).
> > > > >
> > > > > > (I think most of us are at the beginning of step 2, unsure about it
> > > > > > and worried about step 3)
> > > > > >
> > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > > > > flow only, or boards that sometimes use a flow) which need the DT
> > to
> > > > > > come from a prior stage. How to handle that? IMO that is only
> > going to
> > > > > > grow as every man and his dog get into the write-a-bootloader
> > > > > > business.
> > > > >
> > > > > And that's exactly why we have to come up with something that scales,
> > > > without
> > > > > having to add a bunch of unusable DTs in U-Boot.
> > > >
> > > > Both of these are solved by having our bindings reviewed and upstreamed
> > > > and then what we need included in the authoritative dts files.
> > > >
> > > There shall be authoritative System Device Trees as vendors are working
> > on.
> > > Those System Device Trees cover all aspects of a board, not just the
> > > Cortex-A part that U-Boot cares about.
> > > Out of those system device trees, a tool (lopper) is going to carve out
> > the
> > > "authoritative dts for the cortex-A".
> > > Essentially, that carve out will correspond to what would come out of
> > Linux.
> >
> > s/Linux/software/
> >
> > > This scheme will not be generalized, just adopted by vendors on some
> > > boards.
> > > DT for those board become part of the OS ABI (meaning, the driver
> > > developper is constrained).
> >
> > OK?  And is going to pick and choose which valid bindings to implement?
> > Or is it going to provide half a node for Linux?  No?  I assume no.  So
> > it will also provide whatever bindings we've upstreamed and say need to
> > be passed.
> >
> Until we can agree on a better scheme, Linux will server as the basis for
> most of the bindings.

Yes, this is the de-facto standard since the beginning.

> Some projects, like TF-A maintain their own bindings specifications. I

And as I keep saying I believe this to be totally wrong.  Unless and
only unless the TF-A bindings are for TF-A only to care about, and then
it's just one-off do what you guys want non-standard stuff.

> guess U-Boot shall do the same.

No, U-Boot is going to upstream the bindings that we want to have be
considered official.

> The U-Boot DT (for properties or whatever purpose) can be stored in a
> various of U-Boot decided ways and as part of the TF-A FIP image in the
> ad-hoc section: NT_FW_CONFIG. Passing FIP information to U-Boot to retrieve
> the NF_FW_CONFIG should be part of the blob_list discussion that started a
> while ago.

Yes, we'll have to see where things progress about what bindings are
needed, and where.

> For System Device Tree, the bindings and the master repo will be maintained
> in devicetree.org (AFAIK).

Interesting, okay.
Tom Rini Oct. 27, 2021, 2:54 p.m. UTC | #33
On Wed, Oct 27, 2021 at 03:15:01PM +0200, François Ozog wrote:
> Hi,
> 
> On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> 
> > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > Hi all,
> > >
> > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > Hi François,
> > > > > > >
> > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > francois.ozog@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Simon
> > > > > > > >
> > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org>
> > a écrit :
> > > > > > > >>
> > > > > > > >> Hi Tom, Bin,François,
> > > > > > > >>
> > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> > wrote:
> > > > > > > >> >
> > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > > >> > > Hi Simon,
> > > > > > > >> > >
> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > sjg@chromium.org> wrote:
> > > > > > > >> > > >
> > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and
> > OF_HOSTFILE so
> > > > > > > >> > > > there are only three ways to obtain a devicetree:
> > > > > > > >> > > >
> > > > > > > >> > > >    - OF_SEPARATE - the normal way, where the devicetree
> > is built and
> > > > > > > >> > > >       appended to U-Boot
> > > > > > > >> > > >    - OF_EMBED - for development purposes, the
> > devicetree is embedded in
> > > > > > > >> > > >       the ELF file (also used for EFI)
> > > > > > > >> > > >    - OF_BOARD - the board figures it out on its own
> > > > > > > >> > > >
> > > > > > > >> > > > The last one is currently set up so that no devicetree
> > is needed at all
> > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, but
> > some don't. Some
> > > > > > > >> > > > don't even provide instructions on how to boot on the
> > board.
> > > > > > > >> > > >
> > > > > > > >> > > > The problems with this approach are documented at [1].
> > > > > > > >> > > >
> > > > > > > >> > > > In practice, OF_BOARD is not really distinct from
> > OF_SEPARATE. Any board
> > > > > > > >> > > > can obtain its devicetree at runtime, even it is has a
> > devicetree built
> > > > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage
> > bootloader and its
> > > > > > > >> > > > caller may have a better idea about the hardware
> > available in the machine.
> > > > > > > >> > > > This is the case with a few QEMU boards, for example.
> > > > > > > >> > > >
> > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It
> > should be an
> > > > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > > > > > >> > > >
> > > > > > > >> > > > This series makes this change, adding various missing
> > devicetree files
> > > > > > > >> > > > (and placeholders) to make the build work.
> > > > > > > >> > >
> > > > > > > >> > > Adding device trees that are never used sounds like a
> > hack to me.
> > > > > > > >> > >
> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly
> > based on
> > > > > > > >> > > command line parameters, and the device tree you put in
> > this series
> > > > > > > >> > > has various hardcoded <phandle> values which normally do
> > not show up
> > > > > > > >> > > in hand-written dts files.
> > > > > > > >> > >
> > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > >> >
> > > > > > > >> > I am also confused and do not like the idea of adding
> > device trees for
> > > > > > > >> > platforms that are capable of and can / do have a device
> > tree to give us
> > > > > > > >> > at run time.
> > > > > > > >>
> > > > > > > >> (I'll just reply to this one email, since the same points
> > applies to
> > > > > > > >> all replies I think)
> > > > > > > >>
> > > > > > > >> I have been thinking about this and discussing it with people
> > for a
> > > > > > > >> few months now. I've been signalling a change like this for
> > over a
> > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > with Linaro
> > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > hope it is
> > > > > > > >> not a surprise!
> > > > > > > >>
> > > > > > > >> The issue here is that we need a devicetree in-tree in
> > U-Boot, to
> > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > OF_BOARD,
> > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > Between
> > > > > > > >> Ilias' series and this one we can get ourselves on a stronger
> > footing.
> > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> > use.
> > > > > > > >> For more context:
> > > > > > > >>
> > > > > > > >>
> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > >>
> > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> > adding the
> > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > > > >> maintainer would prefer there was no special support even for
> > booting
> > > > > > > >> Linux directly!)
> > > > > > > >
> > > > > > > > i understand their point of view and agree with it.
> > > > > > > >>
> > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > >> think the path forward might be to run QEMU twice, once to
> > get its
> > > > > > > >> generated tree and once to give the 'merged' tree with the
> > U-Boot
> > > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > > >>
> > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > option, not a
> > > > > > > >> build-time one. It creates all sorts of problems and
> > obscurity which
> > > > > > > >> have taken months to unpick. See the above patch for the
> > rationale.
> > > > > > > >>
> > > > > > > >> To add to that rationale, OF_BOARD needs to be an option
> > available to
> > > > > > > >> any board. At some point in the future it may become a common
> > way
> > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> > devicetree
> > > > > > > >> to it. It doesn't make any sense to have people decide
> > whether or not
> > > > > > > >> to set OF_BOARD at build time, thus affecting how the image
> > is put
> > > > > > > >> together. We'll end up with different U-Boot build targets
> > like
> > > > > > > >> capricorn, capricorn_of_board and the like. It should be
> > obvious where
> > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly
> > used
> > > > > > > >> option, perhaps enabled by most/all boards, so that this sort
> > of build
> > > > > > > >> explosion is not needed.
> > > > > > > >
> > > > > > > > If you mean that when boards are by construction providing a
> > DTB to U-Boot then I agree very much. But I don’t understand how the patch
> > set  supports it as it puts dts files for those boards to be built.
> > > > > > > >>
> > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > >> function correctly in whatever runtime environment in which
> > it finds
> > > > > > > >> itself.
> > > > > > > >>
> > > > > > > >> Also as binman is pressed into service more and more to build
> > the
> > > > > > > >> complex firmware images that are becoming fashionable, it
> > needs a
> > > > > > > >> definition (in the devicetree) that describes how to create
> > the image.
> > > > > > > >> We can't support that unless we are building a devicetree,
> > nor can the
> > > > > > > >> running program access the image layout without that
> > information.
> > > > > > > >>
> > > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > > >> germane...but of course I am not suggesting doing that, since
> > OF_BOARD
> > > > > > > >> is, still, enabled. We already use OF_BOARD for various
> > boards that
> > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> > example
> > > > > > > >> (as I said in the cover letter "Most boards do provide one,
> > but some
> > > > > > > >> don't."). So this series is just completing the picture by
> > enforcing
> > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > >
> > > > > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > > > > >
> > > > > > > I think the key point that will get you closer to where I am on
> > this
> > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > present it
> > > > > > > has build-time effects and this is quite wrong. If you go
> > through all
> > > > > > > the material I have written on this I think I have motivated
> > that very
> > > > > > > clearly.
> > > > > > >
> > > > > > > Another big issue is that I believe we need ONE devicetree for
> > U-Boot,
> > > > > > > not two that get merged by U-Boot. Again I have gone through
> > that in a
> > > > > > > lot of detail.
> > > > > >
> > > > > > I have a long long reply to your first reply here saved, but, maybe
> > > > > > here's the biggest sticking point.  To be clear, you agree that
> > U-Boot
> > > > > > needs to support being passed a device tree to use, at run time,
> > yes?
> > > > >
> > > > > Yes. The OF_BOARD feature provides this.
> > > > >
> > > > > >
> > > > > > And in that case, would not be using the "fake" tree we built in?
> > > > >
> > > > > Not at runtime.
> > > >
> > > > OK.
> > > >
> > > > > > So is the sticking point here that we really have two classes of
> > > > > > devices, one class where we will never ever be given the device
> > tree at
> > > > > > run time (think BeagleBone Black) and one where we will always be
> > given
> > > > > > one at run time (think Raspberry Pi) ?
> > > > >
> > > > > I'm not sure it will be that black and white. I suspect there will be
> > > > > (many) boards which can boot happily with the U-Boot devicetree but
> > > > > can also accept one at runtime, if provided. For example, you may
> > want
> > > > > to boot with or without TF-A or some other, earlier stage.
> > > >
> > > > I'm not sure I see the value in making this a gray area.  There's very
> > > > much a class of "never" boards.  There's also the class of "can" today.
> > > > Maybe as part of a developer iterative flow it would be nice to not
> > have
> > > > to re-flash the prior stage to change a DT, and just do it in U-Boot
> > > > until things are happy, but I'm not sure what the use case is for
> > > > overriding the previous stage.
> > > >
> > > > Especially since the pushback on this series I think has all been "why
> > > > are we copying in a tree to build with?  We don't want to use it at run
> > > > time!".  And then softer push back like "Well, U-Boot says we have to
> > > > include the device tree file here, but we won't use it...".
> > >
> > > See below.
> > >
> > > >
> > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > inadvertently)
> > > > > provided a way to entirely omit a devicetree from U-Boot, thus making
> > > > > things like binman and U-Boot /config impossible, for example. So I
> > > > > want to claw that back, so there is always some sort of devicetree in
> > > > > U-Boot, as we have for rpi_3, etc.
> > > >
> > > > I really want to see what the binary case looks like since we could
> > then
> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > then also do a rpi_arm32_defconfig too.
> > > >
> > > > I want to see less device trees in U-Boot sources, if they can come
> > > > functionally correct from the hardware/our caller.
> > > >
> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > > use the device tree from build time at run time, ignoring the device
> > > > tree provided to us at run time by the caller.
> > >
> > > Firstly I should say that I find building firmware very messy and
> > > confusing these days. Lots of things to build and it's hard to find
> > > the instructions. It doesn't have to be that way, but if we carry on
> > > as we are, it will continue to be messy and in five years you will
> > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > objective here is to simplify things, bringing some consistency to the
> > > different components. Binman was one effort there. I feel that putting
> > > at least the U-Boot house in order, in my role as devicetree
> > > maintainer (and as author of devicetree support in U-Boot back in
> > > 2011), is the next step.
> >
> > Yes, it's Not Great.  I don't like my handful of build-BOARD.sh scripts
> > that know where to grab other known-good binaries of varying licenses
> > that are needed to assemble something that boots.
> >
> > > If we set things up correctly and agree on the bindings, devicetree
> > > can be the unifying configuration mechanism through the whole of
> > > firmware (except for very early bits) and into the OS, this will set
> > > us up very well to deal with the complexity that is coming.
> > >
> > > Anyway, here are the mental steps that I've gone through over the past
> > > two months:
> > >
> > > Step 1: At present, some people think U-Boot is not even allowed to
> > > have its own nodes/properties in the DT.
> 
> In my view U-Boot shall be able to leverage device tree format (source and
> binary) to store its own data.
> When you say "the" DT, I always think this is "the" DT that is passed to OS
> and in "that" DT, there should be no U-Boot entries. As stated in another

I would (and I know I'm repeating myself and emails have crossed, etc,
but for future clarity) say it's that no un-official nodes/properties
should be passed from one piece of software to another.  I mean hell,
"u-boot,bootcount" MUST get passed to the OS, so has some idea how many
times the system has booted.  It's just a long standing item to get that
bootcount driver / binding unblocked and merged finally.  But that's a
different tangent to get lost on.

> mail thread, I also refer to a place in a FIP where that dynamic config DT
> is meant to be stored: NT_FW_CONFIG.
> But there can be U-Boot defined bindings in "a" control/dynamic config DT;
> Trusted Firmware does that.

Maybe I just need to come out and say if "everyone" has decided how
U-Boot needs to work, but also myself (head custodian) and Simon (head
DM custodian, device tree in U-Boot custodian) aren't 100% on board with
everything, maybe some step back and re-evaluation needs to be taken?
And I'm not saying we're the final word only here either, there has been
and needs to continue to be good faith discussions.  It should also be
clear at this point that he and I aren't on the same page on everything,
for example :)

> > It is an abuse of the
> > > devicetree standard, like the /chosen node but with less history. We
> > > should sacrifice efficiency, expedience and expandability on the altar
> > > of 'devicetree is a hardware description'. How do we get over that
> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > for its own purposes, as well as for booting the OS. I am not saying
> >
> > Yes, we need to have properties present in the device tree, and just
> > like how "linux," is a valid vendor prefix for the linux kernel (but not
> > used I would expect by the BSD families) we have cases that need
> > "u-boot," properties.
> >
> > > it always has to have those properties, but with existing features
> > > like verified boot, SPL as well as complex firmware images where
> > > U-Boot needs to be able to find things in the image, it is essential.
> > > So let's just assume that we need this everywhere, since we certainly
> > > need it in at least some places.
> >
> > No, we can't / shouldn't assume we need this everywhere.  A lot of
> > places? Yes.  But some features are going to be optional.  A valid must
> > be supported use case is something like a Pi where the hardware gives us
> > a device tree, the tree is correct and some features in U-Boot aren't
> > needed (SPL) nor possibly supported immediately (verified boot).  We can
> > go off on a tangent about how useful it would be to have HW platforms
> > that are both common and can demonstrate a number of features, but
> > that's its own problem to solve.
> >
> > > (stop reading here if you disagree, because nothing below will make
> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > OF_CONTROL :-)
> > >
> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > > have binman definitions, etc. So we need a way to overlay those things
> > > into the DT. We already support this for in-tree DTs, so IMO this is
> > > easy. Just require every board to have an in-tree DT. It helps with
> > > discoverability and documentation, anyway. That is this series.
> > >
> > > (I think most of us are at the beginning of step 2, unsure about it
> > > and worried about step 3)
> > >
> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > flow only, or boards that sometimes use a flow) which need the DT to
> > > come from a prior stage. How to handle that? IMO that is only going to
> > > grow as every man and his dog get into the write-a-bootloader
> > > business. We need a way to provide the U-Boot nodes/properties in a
> > > form that the prior stage can consume and integrate with its build
> > > system. Is TF-A the only thing being discussed here? If so, let's just
> > > do it. We have the u-boot.dtsi and we can use binman to put the image
> > > together, for example. Or we can get clever and create some sort of
> > > overlay dtb.
> > >
> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > > then it will need to build it in and use two devicetrees, one internal
> > > and one from the prior stage....well that is not very efficient and it
> > > is going to be confusing for people to figure out what U-Boot is
> > > actually doing. But we actually already do that in a lot of cases
> > > where U-Boot passes a DT to the kernel which is different to the one
> > > it uses. So perhaps we have three devicetrees? OMG. b) Well then
> > > U-Boot can have its own small devicetree with its bits and then U-Boot
> > > can merge the two when it starts. Again that is not very efficient.
> 
> Does not need to merge the two. hence it does not have any influence on
> efficiency.
> For properties access, trusted firmware has defined an abstract way to get
> them:
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html

That's interesting, but I also think fconf_load_config(), etc are the
efficiency and additional overhead Simon is talking about being worried
about.

> The properties are currently implemented as DT but TF.ORG could decide to
> move to CBOR.
> The API will remain so that a change in backend will not influence existing
> code.
> I think you are too focused on "THE" device tree. "THE" device tree that is
> passed to the OS
> shall be hardware description and not a hacky place to fit any piece of
> metadata.

No, but it is the place to put well defined metadata.

> I would argue that /chosen shall not even be there as most if not all
> information can be passed as OS command line. And actually for the UEFI
> contract, /chosen should go empty.

Shoving a bunch of stuff to the kernel command line sounds pretty hacky
to me.  But I'll just assume it's already been given the official Not
Hacky stamp of approval since after all, there's not a long standing
cleaner path to do anything like that on x86, and we must all mirror the
x86 world.

> > It
> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > > its public key from there or to enable/disable the console), so
> > > unified firmware config is not possible. It will get very confusing,
> > > particularly for debugging U-Boot. c) Some other scheme to avoid
> > > accepting step 3...please stop!
> >
> > How the nodes should get there is how the rest of the nodes in a system
> > get there.  Bindings are submitted and reviewed.  The authoritative
> > source of the dtses in question then has them, like any other property.
> >
> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > > whole cloth. What about that? Well, we are just going to have to deal
> > > with that. We can easily merge in the U-Boot nodes/properties and
> > > update the U-Boot CI scripts to do this, as needed, e.g. with
> > > qemu-riscv64_spl. It's only one use case, although Xen might do
> > > something similar.
> > >
> > > To my mind, that deals with both the build-time and run-time issues.
> > > We have a discoverable DT in U-Boot, which should be considered the
> > > source of truth for most boards. We can sync it with Linux
> > > automatically with the tooling that I hope Rob Herring will come up
> > > with. We can use an empty one where there really is no default,
> > > although I'd argue that is making perfect an enemy of the good.
> > >
> > > Step 5: If we get clever and want to remove them from the U-Boot tree
> > > and pick them up from somewhere else, we can do that with sufficient
> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
> >
> > For SystemReady compliant boards, this has to come much faster.
> Do you think distros will keep providing DTs for ever? I bet not.

Since it seems like it'll be a long time before people stop producing
SBCs that lack on-board flash storage for the world firmware, yeah, I
don't know when distributions will stop shipping DTBs.  Maybe a year or
two after the last popular SBC comes out and distros are comfortable
shoving people that have that hardware off to some other community to
support?
Tom Rini Oct. 27, 2021, 2:55 p.m. UTC | #34
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.
Heinrich Schuchardt Oct. 27, 2021, 3:02 p.m. UTC | #35
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
Mark Kettenis Oct. 27, 2021, 3:10 p.m. UTC | #36
> 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.
Simon Glass Oct. 27, 2021, 3:24 p.m. UTC | #37
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
François Ozog Oct. 27, 2021, 4:02 p.m. UTC | #38
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.
>
Tom Rini Oct. 27, 2021, 6:04 p.m. UTC | #39
On Wed, Oct 27, 2021 at 05:02:39PM +0200, Heinrich Schuchardt wrote:
> On 10/27/21 16:55, Tom Rini wrote:
> > On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote:
> > 
> > [snip]
> > > One passed to U-Boot for fixups and further passed to the OS. This
> > > devicetree may originate from a prior boot stage, from a file loaded by
> > > U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command.
> > 
> > I assume systemd-boot is implementing the same logic that extlinux.conf
> > has used for forever, yes?
> 
> It is loading the file and then calls U-Boot's implementation of the EFI
> Device Tree Fixup Protocol for fixups before passing the device-tree to the
> OS.

So it's using https://systemd.io/BOOT_LOADER_SPECIFICATION/ OK.

> > > This devicetree will not contain any U-Boot specific information.
> > 
> > To repeat, it must only have official bindings, yes, regardless of what
> > project they come from.
> > 
> 
> Don't expect prior firmware stages to provide any U-Boot specific stuff
> whatever official or non-official U-Boot specific bindings exist.

Failure to implement official bindings may result in failure to boot,
which would be pretty silly.
Tom Rini Oct. 27, 2021, 6:06 p.m. UTC | #40
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.
François Ozog Oct. 27, 2021, 6:11 p.m. UTC | #41
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
>
Tom Rini Oct. 27, 2021, 7:06 p.m. UTC | #42
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 :)
Mark Kettenis Oct. 27, 2021, 9:52 p.m. UTC | #43
> 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.
François Ozog Oct. 27, 2021, 10 p.m. UTC | #44
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
>
Simon Glass Oct. 28, 2021, 2:50 a.m. UTC | #45
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
François Ozog Oct. 28, 2021, 8:21 a.m. UTC | #46
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
>
Simon Glass Oct. 28, 2021, 2:30 p.m. UTC | #47
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
Tom Rini Oct. 28, 2021, 2:41 p.m. UTC | #48
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.
François Ozog Oct. 28, 2021, 2:50 p.m. UTC | #49
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
>
Simon Glass Oct. 28, 2021, 3:44 p.m. UTC | #50
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
>
François Ozog Oct. 28, 2021, 4:25 p.m. UTC | #51
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
> >
>
Ilias Apalodimas Nov. 1, 2021, 11:04 a.m. UTC | #52
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
Michael Walle Nov. 2, 2021, 10:06 a.m. UTC | #53
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
François Ozog Nov. 2, 2021, 12:34 p.m. UTC | #54
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
>
Simon Glass Nov. 2, 2021, 2:59 p.m. UTC | #55
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
Simon Glass Nov. 2, 2021, 2:59 p.m. UTC | #56
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
>