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

[Simon Glass]

Hi Heinrich,

On Fri, 3 Dec 2021 at 03:04, Heinrich Schuchardt
<heinrich.schuchardt at canonical.com> wrote:
>
> On 12/2/21 17:50, Simon Glass wrote:
> > 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.
>
> Compiling qemu_arm64_defconfig yields dtbdump.efi. I used this to dump
> the devicetree exposed to UEFI binaries. The number of CPUs and the
> memory size matches the call parameters of QEMU. Emulated devices like
> SCSI and NVMe drives and TPMv2 work inside U-Boot.
>
> I also tested:
>
> * qemu-riscv64_smode_defconfig as fw_jump payload for OpenSBI
> * qemu-riscv64_spl_defconfig
>
> and found no issues.
>
> Tested-by: Heinrich Schuchardt <heinrich.schuchardt at canaonical.com>

Thank you for testing it. I have added your tag to the three patches
for QEMU devicetree (arm/riscv) since I don't have a way to add to the
whole series and I'm not sure it applies in any case.

Regards,
Simon