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

Simon Glass sjg at chromium.org
Wed Nov 3 02:20:48 CET 2021


Hi François,

On Wed, 27 Oct 2021 at 14:07, François Ozog <francois.ozog at linaro.org> wrote:
>
> Hi Simon
>
> Le mer. 27 oct. 2021 à 20:23, Simon Glass <sjg at chromium.org> a écrit :
>>
>> Hi François,
>>
>> On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog at linaro.org> wrote:
>> >
>> >
>> >
>> > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg at chromium.org> wrote:
>> >>
>> >> Hi François,
>> >>
>> >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog at linaro.org> wrote:
>> >> >
>> >> > Hi Simon
>> >> >
>> >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
>> >>
>> >> I think we are going to have to disagree on this one. I actually used
>> >> the qemu one in testing/development recently. We have to have a way to
>> >> develop in-tree with U-Boot. It does not impinge on any of your use
>> >> cases, so far as I know.
>> >
>> > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing.
>> > I understand the advanced debug/development scenario you mention.
>> > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms.
>> > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
>>
>> We have this situation with rpi 1, 2 and 3 and I don't believe anyone
>> has noticed. U-Boot handles the build automatically. If you turn off
>> OF_BOARD, it will use the U-Boot devicetree always so you know what is
>> going on.
>>
>> We can add a message to U-Boot indicating where the devicetree came
>> from, perhaps? That might be useful given everything that is going on.
>>
>> As in this case, quite often in these discussions I struggle to
>> understand what is behind the objection. Is it that your customers are
>> demanding that devicetrees become private, secret data, not included
>> in open-source projects? Or is it just the strange case of QEMU that
>> is informing your thinking? I know of at least one project where the
>> first-stage bootloader produces a devicetree and no one has the source
>> for it. I believe TF-A was created for licensing reasons...so can you
>> be a bit clearer about what the problem actually is?
>
> there are situations where U-Boot must have a dtb. Then those dTB sources are logically found in the dts directory.
> There are situations where U-Boot should not have a dtb. In that case there should be no element in the dts directory. Otherwise it creates confusion.
> Now as you point out, we need “playgrounds” to deal with some situation. So having examples in an ad-hoc directory, different from dts is fine. I proposed documentation but you may find a better place.
> In other words, dts shall host only dt source when U-Boot cannot do but make a dTB for a platform.
> As you have seen in different mail thread (firmware sustainability and OCP checklist) freedom is important to Linaro and there are no hidden Trojan horse for licensing.

I don't understand what you are getting at with the Trojan horse. But
you have no objection to requiring boards to supply a DT (whether in
documentation or arch/arm/dts) to be in U-Boot?

>
>
>> If a board is
>> in-tree in U-Boot I would like it to have a devicetree there, at least
>> until we have a better option. At the very least, it MUST be
>> discoverable and it must be possible to undertake U-Boot development
>> easily without a lot of messing around.
>
> You can if you keep two dts directories separate:
> dts for boards for which U-Boot must have one
> debug-dts for boards for which U-Boot get the DT at runtime but for which you want a playground for debug/easier development.
>>
>>
>> >>
>> >>
>> >> But trying to do any driver / core work for a board where you don't
>> >> have the devicetree is currently not possible. The devicetree is a
>> >> core component and being unable to modify it is simply not practical.
>> >> We are talking here about an option that can be enabled or disabled.
>> >> In my case I am able to disable it locally and do my development work.
>> >>
>> >>
>> >> BTW I've got the bloblist handoff working with a devicetree inside it,
>> >> for qemu_arm. I need to try it on a real board to figure out what the
>> >> difference is.
>> >>
>> > That's great news and much needed for stabilizing the inbound ABI from prior loader to U-Boot. Let's create another thread to discuss this important topic.
>> >>
>>
>> My scenario is not all that advanced and I am using qemu_arm to test
>> the bloblist handoff stuff and include it in CI, with a suitable
>> devicetree and a binman node.
>>
>> Regards,
>> Simon
>>
>> >> >
>> >> > Cheers
>> >> >
>> >> > FF
>> >> >
>> >> > Le mar. 26 oct. 2021 à 02:24, Simon Glass <sjg at chromium.org> a écrit :
>> >> >>
>> >> >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
>> >> >> there are only three ways to obtain a devicetree:
>> >> >>
>> >> >>    - OF_SEPARATE - the normal way, where the devicetree is built and
>> >> >>       appended to U-Boot
>> >> >>    - OF_EMBED - for development purposes, the devicetree is embedded in
>> >> >>       the ELF file (also used for EFI)
>> >> >>    - OF_BOARD - the board figures it out on its own
>> >> >>
>> >> >> The last one is currently set up so that no devicetree is needed at all
>> >> >> in the U-Boot tree. Most boards do provide one, but some don't. Some
>> >> >> don't even provide instructions on how to boot on the board.
>> >> >>
>> >> >> The problems with this approach are documented in another patch in this
>> >> >> series: "doc: Add documentation about devicetree usage"
>> >> >>
>> >> >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
>> >> >> can obtain its devicetree at runtime, even it is has a devicetree built
>> >> >> in U-Boot. This is because U-Boot may be a second-stage bootloader and its
>> >> >> caller may have a better idea about the hardware available in the machine.
>> >> >> This is the case with a few QEMU boards, for example.
>> >> >>
>> >> >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an
>> >> >> option, available with either OF_SEPARATE or OF_EMBED.
>> >> >>
>> >> >> This series makes this change, adding various missing devicetree files
>> >> >> (and placeholders) to make the build work.
>> >> >>
>> >> >> Note: If board maintainers are able to add their own patch to add the
>> >> >> files, some patches in this series can be dropped.
>> >> >>
>> >> >> It also provides a few qemu clean-ups discovered along the way.
>> >> >>
>> >> >> Note: This breaks the qemu-riscv64_spl test, which still needs
>> >> >> investigation.
>> >> >>
>> >> >> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>> >> >>
>> >> >> Changes in v5:
>> >> >> - Bring into the OF_BOARD series
>> >> >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed
>> >> >> - Refer to the 'control' DTB in the first paragraph
>> >> >> - Use QEMU instead of qemu
>> >> >> - Merge RISC-V and ARM patches since they are similar
>> >> >> - Add new patches to clean up fdtdec_setup() and surrounds
>> >> >>
>> >> >> Changes in v3:
>> >> >> - Clarify the 'bug' refered to at the top
>> >> >> - Reword 'This means that there' paragraph to explain U-Boot-specific things
>> >> >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs
>> >> >>
>> >> >> Changes in v2:
>> >> >> - Fix typos per Sean (thank you!) and a few others
>> >> >> - Add a 'Use of U-Boot /config node' section
>> >> >> - Drop mention of dm-verity since that actually uses the kernel cmdline
>> >> >> - Explain that OF_BOARD will still work after these changes (in
>> >> >>   'Once this bug is fixed...' paragraph)
>> >> >> - Expand a bit on the reason why the 'Current situation' is bad
>> >> >> - Clarify in a second place that Linux and U-Boot use the same devicetree
>> >> >>   in 'To be clear, while U-Boot...'
>> >> >> - Expand on why we should have rules for other projects in
>> >> >>   'Devicetree in another project'
>> >> >> - Add a comment as to why devicetree in U-Boot is not 'bad design'
>> >> >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
>> >> >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover
>> >> >>   points raised on v1
>> >> >> - Add 'Why does U-Boot have its nodes and properties?'
>> >> >> - Add 'Why not have two devicetrees?'
>> >> >>
>> >> >> Ilias Apalodimas (1):
>> >> >>   sandbox: Remove OF_HOSTFILE
>> >> >>
>> >> >> Simon Glass (25):
>> >> >>   doc: Add documentation about devicetree usage
>> >> >>   arm: qemu: Mention -nographic in the docs
>> >> >>   arm: riscv: qemu: Explain how to extract the generated dt
>> >> >>   arm: qemu: Add a devicetree file for qemu_arm
>> >> >>   arm: qemu: Add a devicetree file for qemu_arm64
>> >> >>   riscv: qemu: Add devicetree files for qemu_riscv32/64
>> >> >>   arm: rpi: Add a devicetree file for rpi_4
>> >> >>   arm: vexpress: Add a devicetree file for juno
>> >> >>   arm: xenguest_arm64: Add a fake devicetree file
>> >> >>   arm: octeontx: Add a fake devicetree file
>> >> >>   arm: xilinx_versal_virt: Add a devicetree file
>> >> >>   arm: bcm7xxx: Add a devicetree file
>> >> >>   arm: qemu-ppce500: Add a devicetree file
>> >> >>   arm: highbank: Add a fake devicetree file
>> >> >>   fdt: Make OF_BOARD a bool option
>> >> >>   Drop CONFIG_BINMAN_STANDALONE_FDT
>> >> >>   doc: Update info on devicetree update
>> >> >>   fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup()
>> >> >>   fdt: Drop #ifdefs with MULTI_DTB_FIT
>> >> >>   fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup()
>> >> >>   fdt: Drop #ifdef around board_fdt_blob_setup()
>> >> >>   fdt: Use if() for fdtcontroladdr check
>> >> >>   fdt: Drop OF_CONTROL check in fdtdec_setup()
>> >> >>   fdt: Drop remaining preprocessor macros in fdtdec_setup()
>> >> >>   fdt: Don't call board_fdt_blob_setup() without OF_BOARD
>> >> >>
>> >> >>  Makefile                                  |    7 +-
>> >> >>  arch/arm/dts/Makefile                     |   20 +-
>> >> >>  arch/arm/dts/bcm2711-rpi-4-b.dts          | 1958 +++++++++++++++++++++
>> >> >>  arch/arm/dts/bcm7xxx.dts                  |   15 +
>> >> >>  arch/arm/dts/highbank.dts                 |   14 +
>> >> >>  arch/arm/dts/juno-r2.dts                  | 1038 +++++++++++
>> >> >>  arch/arm/dts/octeontx.dts                 |   14 +
>> >> >>  arch/arm/dts/qemu-arm.dts                 |  402 +++++
>> >> >>  arch/arm/dts/qemu-arm64.dts               |  381 ++++
>> >> >>  arch/arm/dts/xenguest-arm64.dts           |   15 +
>> >> >>  arch/arm/dts/xilinx-versal-virt.dts       |  307 ++++
>> >> >>  arch/powerpc/dts/Makefile                 |    1 +
>> >> >>  arch/powerpc/dts/qemu-ppce500.dts         |  264 +++
>> >> >>  arch/riscv/dts/Makefile                   |    2 +-
>> >> >>  arch/riscv/dts/qemu-virt.dts              |    8 -
>> >> >>  arch/riscv/dts/qemu-virt32.dts            |  217 +++
>> >> >>  arch/riscv/dts/qemu-virt64.dts            |  217 +++
>> >> >>  arch/sandbox/cpu/cpu.c                    |   21 +-
>> >> >>  arch/sandbox/include/asm/u-boot-sandbox.h |    8 -
>> >> >>  configs/bcm7260_defconfig                 |    1 +
>> >> >>  configs/bcm7445_defconfig                 |    1 +
>> >> >>  configs/highbank_defconfig                |    2 +-
>> >> >>  configs/octeontx2_95xx_defconfig          |    1 +
>> >> >>  configs/octeontx2_96xx_defconfig          |    1 +
>> >> >>  configs/octeontx_81xx_defconfig           |    1 +
>> >> >>  configs/octeontx_83xx_defconfig           |    1 +
>> >> >>  configs/qemu-ppce500_defconfig            |    2 +
>> >> >>  configs/qemu-riscv32_defconfig            |    1 +
>> >> >>  configs/qemu-riscv32_smode_defconfig      |    1 +
>> >> >>  configs/qemu-riscv32_spl_defconfig        |    4 +-
>> >> >>  configs/qemu-riscv64_defconfig            |    1 +
>> >> >>  configs/qemu-riscv64_smode_defconfig      |    1 +
>> >> >>  configs/qemu-riscv64_spl_defconfig        |    3 +-
>> >> >>  configs/qemu_arm64_defconfig              |    1 +
>> >> >>  configs/qemu_arm_defconfig                |    1 +
>> >> >>  configs/rpi_4_32b_defconfig               |    1 +
>> >> >>  configs/rpi_4_defconfig                   |    1 +
>> >> >>  configs/rpi_arm64_defconfig               |    1 +
>> >> >>  configs/sandbox64_defconfig               |    2 +-
>> >> >>  configs/sandbox_defconfig                 |    2 +-
>> >> >>  configs/sandbox_flattree_defconfig        |    2 +-
>> >> >>  configs/sandbox_noinst_defconfig          |    2 +-
>> >> >>  configs/sandbox_spl_defconfig             |    2 +-
>> >> >>  configs/tools-only_defconfig              |    2 +-
>> >> >>  configs/vexpress_aemv8a_juno_defconfig    |    1 +
>> >> >>  configs/xenguest_arm64_defconfig          |    1 +
>> >> >>  configs/xilinx_versal_virt_defconfig      |    1 +
>> >> >>  doc/board/emulation/qemu-arm.rst          |   10 +-
>> >> >>  doc/board/emulation/qemu-riscv.rst        |    3 +
>> >> >>  doc/develop/devicetree/control.rst        |    7 +-
>> >> >>  doc/develop/devicetree/dt_qemu.rst        |   48 +
>> >> >>  doc/develop/devicetree/dt_update.rst      |  498 ++++++
>> >> >>  doc/develop/devicetree/index.rst          |    2 +
>> >> >>  dts/Kconfig                               |   37 +-
>> >> >>  include/asm-generic/global_data.h         |    8 +
>> >> >>  include/fdtdec.h                          |   21 +-
>> >> >>  lib/fdtdec.c                              |  116 +-
>> >> >>  scripts/Makefile.spl                      |    4 +-
>> >> >>  tools/binman/binman.rst                   |   20 -
>> >> >>  59 files changed, 5560 insertions(+), 164 deletions(-)
>> >> >>  create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
>> >> >>  create mode 100644 arch/arm/dts/bcm7xxx.dts
>> >> >>  create mode 100644 arch/arm/dts/highbank.dts
>> >> >>  create mode 100644 arch/arm/dts/juno-r2.dts
>> >> >>  create mode 100644 arch/arm/dts/octeontx.dts
>> >> >>  create mode 100644 arch/arm/dts/qemu-arm.dts
>> >> >>  create mode 100644 arch/arm/dts/qemu-arm64.dts
>> >> >>  create mode 100644 arch/arm/dts/xenguest-arm64.dts
>> >> >>  create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
>> >> >>  create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
>> >> >>  delete mode 100644 arch/riscv/dts/qemu-virt.dts
>> >> >>  create mode 100644 arch/riscv/dts/qemu-virt32.dts
>> >> >>  create mode 100644 arch/riscv/dts/qemu-virt64.dts
>> >> >>  create mode 100644 doc/develop/devicetree/dt_qemu.rst
>> >> >>  create mode 100644 doc/develop/devicetree/dt_update.rst
>> >> >>
>> >> >> --
>> >> >> 2.33.0.1079.g6e70778dc9-goog
>> >> >>
>> >> > --
>> >> > François-Frédéric Ozog | Director Business Development
>> >> > T: +33.67221.6485
>> >> > francois.ozog at linaro.org | Skype: ffozog
>> >> >
>> >
>> >
>> >
>> > --
>> > François-Frédéric Ozog | Director Business Development
>> > T: +33.67221.6485
>> > francois.ozog at linaro.org | Skype: ffozog
>> >
>
> --
> François-Frédéric Ozog | Director Business Development
> T: +33.67221.6485
> francois.ozog at linaro.org | Skype: ffozog
>


More information about the U-Boot mailing list