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 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/ >> >> I am able to use >> QEMU versions that differ by two years, partly because I am not trying >> to do anything clever. >> >> I have sent a patch to add an indication of where the devicetree came >> from, to help with visibility on this. Regards, Simon
