Hi Heinrich, On Fri, 3 Dec 2021 at 03:04, Heinrich Schuchardt <heinrich.schucha...@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.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>
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
