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

[Heinrich Schuchardt]

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>