Hi Peter, On Mon, 27 Sept 2021 at 02:48, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Sun, 26 Sept 2021 at 19:55, Simon Glass <s...@chromium.org> wrote: > > In the case of U-Boot at least, it uses the devicetree for > > configuration (it is a boot loader, so there is no user space to > > provide configuration). So the current setup is not sufficient to boot > > it correctly in all cases. On the other hand, the 'virt' feature is > > very useful for testing U-Boot, so it would be great to be able to > > support this. > > So what is missing in the QEMU-provided DTB that it needs?
Quite a lot. Here are some examples: U-Boot has limited pre-relocation memory so tries to avoid binding/probing devices that are not used before relocation: https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html#pre-relocation-support There is a configuration node (which is likely to change form in future releases, but will still be there) https://github.com/u-boot/u-boot/blob/master/doc/device-tree-bindings/config.txt Then there are various features which put things in U-Boot's control dtb, such as verified boot, which adds public keys during signing: https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/signature.txt#L135 More generally, the U-Boot tree has hundreds of files which add properties for each board, since we try to keep the U-Boot-specific things out of the Linux tree: $ find . -name *u-boot.dtsi |wc -l 398 Quite a bit of this is to do with SPL and so far it seems that QEMU mostly runs U-Boot proper only, although I see that SPL is starting to creep in too in the U-Boot CI. So at present QEMU is not able to support U-Boot fully. It would be great to add this as we use QEMU heavily in CI testing, e.g. see the second column here: https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/9260 Regards, Simon