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

[Simon Glass]

Hi Heinrich,

On Thu, 2 Dec 2021 at 09:47, Heinrich Schuchardt
<heinrich.schuchardt at canonical.com> wrote:
>
> On 12/2/21 16:58, 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.
>
> Distros like Ubuntu are provided as preinstalled images using U-Boot to
> launch Linux for usage with QEMU. A single image must be able to be
> usable in the future irrespective of the QEMU command line device
> configuration.
>
> This means that the devicetree coming from QEMU must be accurately
> parsed in U-Boot to setup the UEFI memory map. The number and type of
> CPUs and the NUMA configuration must be accurate. All devices enabled
> via the QEMU command line must be visible in the device-tree of Linux.
>
> Please, observe that information like number of CPU cores, number and
> type of block devices, namespace IDs used for NVMe drives, etc. cannot
> be available at build time.
>
> It this all guaranteed with this series? If not, this would
> unfortunately imply a NAK.

Yes, it is guaranteed and there is no change there.

Regards,
Simon