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

Simon Glass posted 16 patches 1 week, 3 days ago
Only 6 patches received!
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

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

Posted by Simon Glass 1 week, 3 days ago
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
there are only three ways to obtain a devicetree:

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

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

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

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

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

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

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

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

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

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


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

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

-- 
2.33.0.882.g93a45727a2-goog


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

Posted by Heinrich Schuchardt 1 week, 3 days ago

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
> 

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

Posted by François Ozog 1 week, 3 days ago
Le mer. 13 oct. 2021 à 14:41, Heinrich Schuchardt <
heinrich.schuchardt@canonical.com> a écrit :

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

>
> Best regards
>
> Heinrich
>
> >
> > It also provides a few qemu clean-ups discovered along the way.
> >
> > This series is based on Ilias' two series for OF_HOSTFILE and
> > OF_PRIOR_STAGE removal.
> >
> > It is available at u-boot-dm/ofb-working
> >
> > [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >
> >
> > Simon Glass (16):
> >    arm: qemu: Mention -nographic in the docs
> >    arm: qemu: Explain how to extract the generate devicetree
> >    riscv: qemu: Explain how to extract the generate devicetree
> >    arm: qemu: Add a devicetree file for qemu_arm
> >    arm: qemu: Add a devicetree file for qemu_arm64
> >    riscv: qemu: Add devicetree files for qemu_riscv32/64
> >    arm: rpi: Add a devicetree file for rpi_4
> >    arm: vexpress: Add a devicetree file for juno
> >    arm: xenguest_arm64: Add a fake devicetree file
> >    arm: octeontx: Add a fake devicetree file
> >    arm: xilinx_versal_virt: Add a devicetree file
> >    arm: bcm7xxx: Add a devicetree file
> >    arm: qemu-ppce500: Add a devicetree file
> >    arm: highbank: Add a fake devicetree file
> >    fdt: Make OF_BOARD a bool option
> >    Drop CONFIG_BINMAN_STANDALONE_FDT
> >
> >   Makefile                               |    3 +-
> >   arch/arm/dts/Makefile                  |   20 +-
> >   arch/arm/dts/bcm2711-rpi-4-b.dts       | 1958 ++++++++++++++++++++++++
> >   arch/arm/dts/bcm7xxx.dts               |   15 +
> >   arch/arm/dts/highbank.dts              |   14 +
> >   arch/arm/dts/juno-r2.dts               | 1038 +++++++++++++
> >   arch/arm/dts/octeontx.dts              |   14 +
> >   arch/arm/dts/qemu-arm.dts              |  402 +++++
> >   arch/arm/dts/qemu-arm64.dts            |  381 +++++
> >   arch/arm/dts/xenguest-arm64.dts        |   15 +
> >   arch/arm/dts/xilinx-versal-virt.dts    |  307 ++++
> >   arch/powerpc/dts/Makefile              |    1 +
> >   arch/powerpc/dts/qemu-ppce500.dts      |  264 ++++
> >   arch/riscv/dts/Makefile                |    2 +-
> >   arch/riscv/dts/qemu-virt.dts           |    8 -
> >   arch/riscv/dts/qemu-virt32.dts         |  217 +++
> >   arch/riscv/dts/qemu-virt64.dts         |  217 +++
> >   configs/bcm7260_defconfig              |    1 +
> >   configs/bcm7445_defconfig              |    1 +
> >   configs/highbank_defconfig             |    2 +-
> >   configs/octeontx2_95xx_defconfig       |    1 +
> >   configs/octeontx2_96xx_defconfig       |    1 +
> >   configs/octeontx_81xx_defconfig        |    1 +
> >   configs/octeontx_83xx_defconfig        |    1 +
> >   configs/qemu-ppce500_defconfig         |    2 +
> >   configs/qemu-riscv32_defconfig         |    1 +
> >   configs/qemu-riscv32_smode_defconfig   |    1 +
> >   configs/qemu-riscv32_spl_defconfig     |    4 +-
> >   configs/qemu-riscv64_defconfig         |    1 +
> >   configs/qemu-riscv64_smode_defconfig   |    1 +
> >   configs/qemu-riscv64_spl_defconfig     |    3 +-
> >   configs/qemu_arm64_defconfig           |    1 +
> >   configs/qemu_arm_defconfig             |    1 +
> >   configs/rpi_4_32b_defconfig            |    1 +
> >   configs/rpi_4_defconfig                |    1 +
> >   configs/rpi_arm64_defconfig            |    1 +
> >   configs/vexpress_aemv8a_juno_defconfig |    1 +
> >   configs/xenguest_arm64_defconfig       |    1 +
> >   configs/xilinx_versal_virt_defconfig   |    1 +
> >   doc/board/emulation/qemu-arm.rst       |   19 +-
> >   doc/board/emulation/qemu-riscv.rst     |   12 +
> >   dts/Kconfig                            |   27 +-
> >   tools/binman/binman.rst                |   20 -
> >   43 files changed, 4922 insertions(+), 61 deletions(-)
> >   create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> >   create mode 100644 arch/arm/dts/bcm7xxx.dts
> >   create mode 100644 arch/arm/dts/highbank.dts
> >   create mode 100644 arch/arm/dts/juno-r2.dts
> >   create mode 100644 arch/arm/dts/octeontx.dts
> >   create mode 100644 arch/arm/dts/qemu-arm.dts
> >   create mode 100644 arch/arm/dts/qemu-arm64.dts
> >   create mode 100644 arch/arm/dts/xenguest-arm64.dts
> >   create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
> >   create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
> >   delete mode 100644 arch/riscv/dts/qemu-virt.dts
> >   create mode 100644 arch/riscv/dts/qemu-virt32.dts
> >   create mode 100644 arch/riscv/dts/qemu-virt64.dts
> >
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

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

Posted by Bin Meng 1 week, 3 days ago
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

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

Posted by Philippe Mathieu-Daudé 1 week, 3 days ago
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
> 


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

Posted by François Ozog 1 week, 3 days ago
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

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

Posted by Tom Rini 1 week, 3 days ago
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

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

Posted by Simon Glass 1 week, 3 days ago
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

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

Posted by François Ozog 1 week, 3 days ago
Hi Simon

Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :

> Hi Tom, Bin,François,
>
> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > Hi Simon,
> > >
> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > there are only three ways to obtain a devicetree:
> > > >
> > > >    - OF_SEPARATE - the normal way, where the devicetree is built and
> > > >       appended to U-Boot
> > > >    - OF_EMBED - for development purposes, the devicetree is embedded
> in
> > > >       the ELF file (also used for EFI)
> > > >    - OF_BOARD - the board figures it out on its own
> > > >
> > > > The last one is currently set up so that no devicetree is needed at
> all
> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > don't even provide instructions on how to boot on the board.
> > > >
> > > > The problems with this approach are documented at [1].
> > > >
> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any
> board
> > > > can obtain its devicetree at runtime, even it is has a devicetree
> built
> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader
> and its
> > > > caller may have a better idea about the hardware available in the
> machine.
> > > > This is the case with a few QEMU boards, for example.
> > > >
> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > >
> > > > This series makes this change, adding various missing devicetree
> files
> > > > (and placeholders) to make the build work.
> > >
> > > Adding device trees that are never used sounds like a hack to me.
> > >
> > > For QEMU, device tree is dynamically generated on the fly based on
> > > command line parameters, and the device tree you put in this series
> > > has various hardcoded <phandle> values which normally do not show up
> > > in hand-written dts files.
> > >
> > > I am not sure I understand the whole point of this.
> >
> > I am also confused and do not like the idea of adding device trees for
> > platforms that are capable of and can / do have a device tree to give us
> > at run time.
>
> (I'll just reply to this one email, since the same points applies to
> all replies I think)
>
> I have been thinking about this and discussing it with people for a
> few months now. I've been signalling a change like this for over a
> month now, on U-Boot contributor calls and in discussions with Linaro
> people. I sent a patch (below) to try to explain things. I hope it is
> not a surprise!
>
> The issue here is that we need a devicetree in-tree in U-Boot, to
> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> Ilias' series and this one we can get ourselves on a stronger footing.
> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> For more context:
>
>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>
> BTW I did suggest to QEMU ARM that they support a way of adding the
> u-boot.dtsi but there was not much interest there (in fact the
> maintainer would prefer there was no special support even for booting
> Linux directly!)

i understand their point of view and agree with it.

> But in any case it doesn't really help U-Boot. I
> think the path forward might be to run QEMU twice, once to get its
> generated tree and once to give the 'merged' tree with the U-Boot
> properties in it, if people want to use U-Boot features.
>
> I do strongly believe that OF_BOARD must be a run-time option, not a
> build-time one. It creates all sorts of problems and obscurity which
> have taken months to unpick. See the above patch for the rationale.
>
> To add to that rationale, OF_BOARD needs to be an option available to
> any board. At some point in the future it may become a common way
> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> to it. It doesn't make any sense to have people decide whether or not
> to set OF_BOARD at build time, thus affecting how the image is put
> together. We'll end up with different U-Boot build targets like
> capricorn, capricorn_of_board and the like. It should be obvious where
> that will lead. Instead, OF_BOARD needs to become a commonly used
> option, perhaps enabled by most/all boards, so that this sort of build
> explosion is not needed.

If you mean that when boards are by construction providing a DTB to U-Boot
then I agree very much. But I don’t understand how the patch set  supports
it as it puts dts files for those boards to be built.

> U-Boot needs to be flexible enough to
> function correctly in whatever runtime environment in which it finds
> itself.
>
> Also as binman is pressed into service more and more to build the
> complex firmware images that are becoming fashionable, it needs a
> definition (in the devicetree) that describes how to create the image.
> We can't support that unless we are building a devicetree, nor can the
> running program access the image layout without that information.
>
> François's point about 'don't use this with any kernel' is
> germane...but of course I am not suggesting doing that, since OF_BOARD
> is, still, enabled. We already use OF_BOARD for various boards that
> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> (as I said in the cover letter "Most boards do provide one, but some
> don't."). So this series is just completing the picture by enforcing
> that *some sort* of devicetree is always present.
>
That seems inconsistent with the OF_BOARD becomes the default.

>
> I can't quite pinpoint the patch where U-Boot started allowing the
> devicetree to be omitted, but if people are interested I could try a
> little harder. It was certainly not my intention (putting on my
> device-tree-maintainer hat) to go down that path and it slipped in
> somehow in all the confusion. I'm not sure anyone could tell you that
> rpi_3 has an in-tree devicetree but rpi_4 does not...
>
> Anyway this series is very modest. It just adds the requirement that
> all in-tree boards have some sort of sample devicetree and preferably
> some documentation as to where it might come from at runtime.

That’s a very good goal. But adding files in dts make them not samples but
templates to be used and replace board provided DTB.
If you push all your DTS files in documentation, you do what you say:
adding sample files.

> That
> should not be a tough call IMO. Assuming we can get the validation in
> place (mentioned by Rob Herring recently) it will be quite natural to
> sync them between (presumably) Linux and U-Boot.
>
> I am also quite happy to discuss what should actually be in these
> devicetree files and whether some of them should be essentially empty.
> As you probably noticed, some of them are empty since I literally
> could not figure out where they come from! But there needs to be at
> least some skeleton for U-Boot to progress, since devicetree is
> critical to its feature set.

absolutely. And thank you for your efforts to make that center stage. This
is also Linaro Edge group mist challenging  task on the next 6 moths.
Knowing that we have lived in a floating situation for over 10 years, I
just hope we get consensus across projects and distro providers about the
right end goal and migration strategy.

>
>
> It is high time we tidied all this up. I predict it will be much
> harder, and much more confusing, in 6 months.
>
> Regards,
> Simon
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

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

Posted by Simon Glass 1 week, 3 days ago
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

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

Posted by François Ozog 1 week, 2 days ago
Le mer. 13 oct. 2021 à 20:06, Simon Glass <sjg@chromium.org> a écrit :

> Hi François,
>
> On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> > Hi Simon
> >
> > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> Hi Tom, Bin,François,
> >>
> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> >> >
> >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> >> > > Hi Simon,
> >> > >
> >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org>
> wrote:
> >> > > >
> >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and
> OF_HOSTFILE so
> >> > > > there are only three ways to obtain a devicetree:
> >> > > >
> >> > > >    - OF_SEPARATE - the normal way, where the devicetree is built
> and
> >> > > >       appended to U-Boot
> >> > > >    - OF_EMBED - for development purposes, the devicetree is
> embedded in
> >> > > >       the ELF file (also used for EFI)
> >> > > >    - OF_BOARD - the board figures it out on its own
> >> > > >
> >> > > > The last one is currently set up so that no devicetree is needed
> at all
> >> > > > in the U-Boot tree. Most boards do provide one, but some don't.
> Some
> >> > > > don't even provide instructions on how to boot on the board.
> >> > > >
> >> > > > The problems with this approach are documented at [1].
> >> > > >
> >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE.
> Any board
> >> > > > can obtain its devicetree at runtime, even it is has a devicetree
> built
> >> > > > in U-Boot. This is because U-Boot may be a second-stage
> bootloader and its
> >> > > > caller may have a better idea about the hardware available in the
> machine.
> >> > > > This is the case with a few QEMU boards, for example.
> >> > > >
> >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be
> an
> >> > > > option, available with either OF_SEPARATE or OF_EMBED.
> >> > > >
> >> > > > This series makes this change, adding various missing devicetree
> files
> >> > > > (and placeholders) to make the build work.
> >> > >
> >> > > Adding device trees that are never used sounds like a hack to me.
> >> > >
> >> > > For QEMU, device tree is dynamically generated on the fly based on
> >> > > command line parameters, and the device tree you put in this series
> >> > > has various hardcoded <phandle> values which normally do not show up
> >> > > in hand-written dts files.
> >> > >
> >> > > I am not sure I understand the whole point of this.
> >> >
> >> > I am also confused and do not like the idea of adding device trees for
> >> > platforms that are capable of and can / do have a device tree to give
> us
> >> > at run time.
> >>
> >> (I'll just reply to this one email, since the same points applies to
> >> all replies I think)
> >>
> >> I have been thinking about this and discussing it with people for a
> >> few months now. I've been signalling a change like this for over a
> >> month now, on U-Boot contributor calls and in discussions with Linaro
> >> people. I sent a patch (below) to try to explain things. I hope it is
> >> not a surprise!
> >>
> >> The issue here is that we need a devicetree in-tree in U-Boot, to
> >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> >> Ilias' series and this one we can get ourselves on a stronger footing.
> >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> >> For more context:
> >>
> >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >>
> >> BTW I did suggest to QEMU ARM that they support a way of adding the
> >> u-boot.dtsi but there was not much interest there (in fact the
> >> maintainer would prefer there was no special support even for booting
> >> Linux directly!)
> >
> > i understand their point of view and agree with it.
> >>
> >> But in any case it doesn't really help U-Boot. I
> >> think the path forward might be to run QEMU twice, once to get its
> >> generated tree and once to give the 'merged' tree with the U-Boot
> >> properties in it, if people want to use U-Boot features.
> >>
> >> I do strongly believe that OF_BOARD must be a run-time option, not a
> >> build-time one. It creates all sorts of problems and obscurity which
> >> have taken months to unpick. See the above patch for the rationale.
> >>
> >> To add to that rationale, OF_BOARD needs to be an option available to
> >> any board. At some point in the future it may become a common way
> >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> >> to it. It doesn't make any sense to have people decide whether or not
> >> to set OF_BOARD at build time, thus affecting how the image is put
> >> together. We'll end up with different U-Boot build targets like
> >> capricorn, capricorn_of_board and the like. It should be obvious where
> >> that will lead. Instead, OF_BOARD needs to become a commonly used
> >> option, perhaps enabled by most/all boards, so that this sort of build
> >> explosion is not needed.
> >
> > If you mean that when boards are by construction providing a DTB to
> U-Boot then I agree very much. But I don’t understand how the patch set
> supports it as it puts dts files for those boards to be built.
> >>
> >> U-Boot needs to be flexible enough to
> >> function correctly in whatever runtime environment in which it finds
> >> itself.
> >>
> >> Also as binman is pressed into service more and more to build the
> >> complex firmware images that are becoming fashionable, it needs a
> >> definition (in the devicetree) that describes how to create the image.
> >> We can't support that unless we are building a devicetree, nor can the
> >> running program access the image layout without that information.
> >>
> >> François's point about 'don't use this with any kernel' is
> >> germane...but of course I am not suggesting doing that, since OF_BOARD
> >> is, still, enabled. We already use OF_BOARD for various boards that
> >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> >> (as I said in the cover letter "Most boards do provide one, but some
> >> don't."). So this series is just completing the picture by enforcing
> >> that *some sort* of devicetree is always present.
> >
> > That seems inconsistent with the OF_BOARD becomes the default.
>
> I think the key point that will get you closer to where I am on this
> issue, is that OF_BOARD needs to be a run-time option. At present it
> has build-time effects and this is quite wrong.

Doesn’t that mean that the current build system is not fully supporting
boards that do provide the DT and you try to hack your way in ? As I
replied to Tom, I could accept temporarily a void.dts containing nothing to
actually uallly pass any build problem until we properly fix the build
system.
(But no “close to real” fake dts in the dts section)

> If you go through all
> the material I have written on this I think I have motivated that very
> clearly.
>
> Another big issue is that I believe we need ONE devicetree for U-Boot,
> not two that get merged by U-Boot. Again I have gone through that in a
> lot of detail.
>
i know but a number of people do not agree with your position. U-Boot can
leverage many DTs coming from hats and capes to finalize the DT it passes
to OS. It can also leverage a file, a FIP section (NT_FW_CONFIG in TFA) a
FIT section formatted as FDT for its own configuration.

>
> >>
> >>
> >> I can't quite pinpoint the patch where U-Boot started allowing the
> >> devicetree to be omitted, but if people are interested I could try a
> >> little harder. It was certainly not my intention (putting on my
> >> device-tree-maintainer hat) to go down that path and it slipped in
> >> somehow in all the confusion. I'm not sure anyone could tell you that
> >> rpi_3 has an in-tree devicetree but rpi_4 does not...
> >>
> >> Anyway this series is very modest. It just adds the requirement that
> >> all in-tree boards have some sort of sample devicetree and preferably
> >> some documentation as to where it might come from at runtime.
> >
> > That’s a very good goal. But adding files in dts make them not samples
> but templates to be used and replace board provided DTB.
> > If you push all your DTS files in documentation, you do what you say:
> adding sample files.
> >>
> >> That
> >> should not be a tough call IMO. Assuming we can get the validation in
> >> place (mentioned by Rob Herring recently) it will be quite natural to
> >> sync them between (presumably) Linux and U-Boot.
> >>
> >> I am also quite happy to discuss what should actually be in these
> >> devicetree files and whether some of them should be essentially empty.
> >> As you probably noticed, some of them are empty since I literally
> >> could not figure out where they come from! But there needs to be at
> >> least some skeleton for U-Boot to progress, since devicetree is
> >> critical to its feature set.
> >
> > absolutely. And thank you for your efforts to make that center stage.
> This is also Linaro Edge group mist challenging  task on the next 6 moths.
> Knowing that we have lived in a floating situation for over 10 years, I
> just hope we get consensus across projects and distro providers about the
> right end goal and migration strategy.
> >>
>
> Thank you.
>
> >>
> >>
> >> It is high time we tidied all this up. I predict it will be much
> >> harder, and much more confusing, in 6 months.
>
> Just to set a road map here in case you can help unblock anything,
> here are the things I am aware of, excluding the things I have
> forgotten:
>
> - Ilias OF_PRIOR_STAGE, OF_HOSTFILE series
> - this series
> - the devicetree docs patch
> - devicetree bindings upstream for U-Boot (first patch under discussion)
> - bloblist as a means of passing devicetree, ACPI, tiny config info as

the “ABI” of U-Boot entry need more specification. Having something close
to Linux helped to get U-Boot in the RPI4 and other boards I believe. So we
could start from here. The blob list may be an extra arg (x0=DTB,
x1=bloblist in Arm).

>
> C structs to U-Boot (needs to be written)
> - VPL so we can handle verification (patches pending)
> - bootflow / VBE v2 series (coming next week)
>
> Regards,
> Simon
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

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

Posted by Simon Glass 1 week, 2 days ago
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

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

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

I have a long long reply to your first reply here saved, but, maybe
here's the biggest sticking point.  To be clear, you agree that U-Boot
needs to support being passed a device tree to use, at run time, yes?

And in that case, would not be using the "fake" tree we built in?

So is the sticking point here that we really have two classes of
devices, one class where we will never ever be given the device tree at
run time (think BeagleBone Black) and one where we will always be given
one at run time (think Raspberry Pi) ?

-- 
Tom

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

Posted by Simon Glass 1 week, 2 days ago
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

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

Posted by Andre Przywara 1 week, 2 days ago
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


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

Posted by François Ozog 1 week, 2 days ago
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

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

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

OK.

> > So is the sticking point here that we really have two classes of
> > devices, one class where we will never ever be given the device tree at
> > run time (think BeagleBone Black) and one where we will always be given
> > one at run time (think Raspberry Pi) ?
> 
> I'm not sure it will be that black and white. I suspect there will be
> (many) boards which can boot happily with the U-Boot devicetree but
> can also accept one at runtime, if provided. For example, you may want
> to boot with or without TF-A or some other, earlier stage.

I'm not sure I see the value in making this a gray area.  There's very
much a class of "never" boards.  There's also the class of "can" today.
Maybe as part of a developer iterative flow it would be nice to not have
to re-flash the prior stage to change a DT, and just do it in U-Boot
until things are happy, but I'm not sure what the use case is for
overriding the previous stage.

Especially since the pushback on this series I think has all been "why
are we copying in a tree to build with?  We don't want to use it at run
time!".  And then softer push back like "Well, U-Boot says we have to
include the device tree file here, but we won't use it...".

> I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
> provided a way to entirely omit a devicetree from U-Boot, thus making
> things like binman and U-Boot /config impossible, for example. So I
> want to claw that back, so there is always some sort of devicetree in
> U-Boot, as we have for rpi_3, etc.

I really want to see what the binary case looks like since we could then
kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
then also do a rpi_arm32_defconfig too.

I want to see less device trees in U-Boot sources, if they can come
functionally correct from the hardware/our caller.

And I'm not seeing how we make use of "U-Boot /config" if we also don't
use the device tree from build time at run time, ignoring the device
tree provided to us at run time by the caller.

-- 
Tom

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

Posted by Simon Glass 1 week, 1 day ago
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

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

Posted by François Ozog 1 week, 2 days ago
Le jeu. 14 oct. 2021 à 17:28, Tom Rini <trini@konsulko.com> a écrit :

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

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

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

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


>
> --
> Tom
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

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

Posted by François Ozog 1 week, 3 days ago
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

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

Posted by Andre Przywara 1 week, 3 days ago
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
> 


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

Posted by François Ozog 1 week, 3 days ago
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