On Tue, Nov 02, 2021 at 07:32:54PM -0600, Simon Glass wrote: > Hi Tom, > > On Tue, 2 Nov 2021 at 10:57, Tom Rini <tr...@konsulko.com> wrote: > > > > On Tue, Nov 02, 2021 at 08:59:45AM -0600, Simon Glass wrote: > > > Hi François, > > > > > > On Mon, 1 Nov 2021 at 11:33, François Ozog <francois.o...@linaro.org> > > > wrote: > > > > > > > > Hi Simon > > > > > > > > Le lun. 1 nov. 2021 à 17:58, Simon Glass <s...@chromium.org> a écrit : > > > >> > > > >> Hi Peter, > > > >> > > > >> On Mon, 1 Nov 2021 at 04:48, Peter Maydell <peter.mayd...@linaro.org> > > > >> wrote: > > > >> > > > > >> > On Tue, 26 Oct 2021 at 01:33, Simon Glass <s...@chromium.org> wrote: > > > >> > > > > > >> > > Add this file, generated from qemu, so there is a reference > > > >> > > devicetree > > > >> > > in the U-Boot tree. > > > >> > > > > > >> > > Signed-off-by: Simon Glass <s...@chromium.org> > > > >> > > > > >> > Note that the dtb you get from QEMU is only guaranteed to work if: > > > >> > 1) you run it on the exact same QEMU version you generated it with > > > >> > 2) you pass QEMU the exact same command line arguments you used > > > >> > when you generated it > > > >> > > > >> Yes, I certainly understand that. In general this is not safe, but in > > > >> practice it works well enough for development and CI. > > > > > > > > You recognize that you hijack a product directory with development hack > > > > facility. There is a test directory to keep things clear. There can be > > > > a dev-dts or something similar for Dev time tools. > > > > I have only seen push back on those fake dts files in the dts > > > > directory: I guess that unless someone strongly favors a continuation > > > > of the discussion, you may consider re-shaping the proposal to address > > > > concerns. > > > > > > As stated previously, I would like to have at least a sample DT > > > in-tree for all boards. I cannot see another way to get the Kconfig > > > > What's the point of having a sample when it's not going to always be > > correct or may be actively wrong and we can tell interested developers / > > users how to get the correct DTB/DTS to examine? > > > > > options in line. If we are able to put these files somewhere else in > > > the future and get them out of U-Boot, with perhaps just an overlay > > > for development purposes, I'd be keen to see it. But for now, this is > > > where we are, I believe. > > > > > > In this particular case, this is not just a dev hack. It is also for > > > CI tests which need to use a devicetree. See for example here: > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-...@chromium.org/ > > > https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-...@chromium.org/ > > > > This example would probably be better done on vexpress_ca9x4 where we do > > test in CI via QEMU but do not need to modify a device tree that is > > passed on to us, we already control the source of truth DTB in this > > case. > > But that board: > > - uses OF_EMBED, which it should not > - does not use SPL, which I need
Check out the other hardware then that we emulate today, and or maybe something off of https://qemu.readthedocs.io/en/latest/system/target-arm.html that we could add. My point is that by picking the QEMU targets for where to test this feature you've gone with "I've introduced this feature so now I need to introduce this other change I've been arguing for too" in an artificial manner as it would only be used like that for testing. -- Tom
signature.asc
Description: PGP signature