On Wed, Oct 27, 2021 at 12:34:26PM -0600, Simon Glass wrote: > Hi all, > > On Wed, 27 Oct 2021 at 08:56, Tom Rini <tr...@konsulko.com> wrote: > > > > On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote: > > > > > > François Ozog <francois.o...@linaro.org> writes: > > > > > > > Hi Simon > > > > > > > > The only place I could agree with this file presence is in the > > > > documentation directory, not in dts. It creates a mental picture for > > > > the reader > > > > an entirely bad mind scheme around Qemu and DT. > > > > > > > > And even in a documentation directory I would place a bug warning: > > > > don’t use this with any kernel , Qemu generates a DT dynamically > > > > based on cpu, memory and devices specified at the command line. > > > > > > Certainly for the arm, aarch64 and riscv "virt" machines you should > > > always use the QEMU generated DTB. I'm not entirely clear what a > > > qemu_arm and qemu_arm64 def targets are meant to be in this context. > > > > Agreed. We cannot include random device trees in U-Boot for devices > > that generate their own at run time or otherwise have the source of > > truth elsewhere. > > Until we have a way of bringing in the u-boot.dtsi that people in QEMU > can agree on, I don't see an alternative. I will send a series for the > bloblist handoff next week and I think you will all see what I mean.
I think the alternative is that QEMU in U-Boot just can't be used for certain features. Which is annoying in that it would be good to use it to test certain feature, yes. It's generating a good and valid enough dtb for Linux, so it should be good enough for us in general. -- Tom
signature.asc
Description: PGP signature
