On 12/2/21 17:50, Simon Glass wrote:
Hi Heinrich,
On Thu, 2 Dec 2021 at 09:47, Heinrich Schuchardt
<heinrich.schucha...@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.schucha...@canaonical.com>
