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

Tom Rini trini at konsulko.com
Fri Dec 3 15:55:31 CET 2021

On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 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. The
> qemu-riscv64_spl problem is fixed.

Note that I can't run-time test this as the last patch fails to apply
and is dependent on non-trivial missing changes ("/* The devicetree is
typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
and that's part of the unchanging context where things fail to apply).

So, here's my first bit of confusion.  Today, I build for rpi_arm64 and
no dtb files are built.  I run this on my Pi 3 and everything works.
With your series, I see all the dtbs have been built, and dts/dt.dtb and
u-boot.dtb have a Pi 4 dtb in them.  Should this even run now?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211203/50e85a5d/attachment.sig>

More information about the U-Boot mailing list