Hi Tom, On Mon, 2 Oct 2023 at 08:09, Tom Rini <tr...@konsulko.com> wrote: > > On Sun, Oct 01, 2023 at 07:17:27PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Fri, 29 Sept 2023 at 10:02, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Fri, Sep 29, 2023 at 09:15:00AM -0600, Simon Glass wrote: > > > > Hi Rasmus, > > > > > > > > On Mon, 25 Sept 2023 at 13:05, Rasmus Villemoes > > > > <rasmus.villem...@prevas.dk> wrote: > > > > > > > > > > On 25/09/2023 20.19, Tom Rini wrote: > > > > > > On Mon, Sep 25, 2023 at 10:27:43AM +0200, Rasmus Villemoes wrote: > > > > > >> On 04/05/2023 14.35, Rasmus Villemoes wrote: > > > > > >>> On 03/05/2023 16.54, Tom Rini wrote: > > > > > >> > > > > > >>>> The one last problem now is on stm32mp15_dhcor_basic which is a > > > > > >>>> defconfig missing one from OF_LIST but including it in the its > > > > > >>>> file, so > > > > > >>>> the above is the patch we need. > > > > > >>>> > > > > > >> > > > > > >> Hi Tom > > > > > >> > > > > > >> Can I persuade you to try something like > > > > > >> https://source.denx.de/u-boot/u-boot/-/commit/a05e0d0e6b9103542a1076f9cab0005f400fa072 > > > > > >> again, but leaving the .dtbo targets in there? > > > > > >> > > > > > >> I could send a patch, but it's entirely mechanical, and not really > > > > > >> meant > > > > > >> for being applied until we know if there's more to be cleaned up. > > > > > > > > > > > > So what ended up being the problem I think is the case Simon > > > > > > pointed out > > > > > > where we do take the output from "make all" and concatenate one of > > > > > > the > > > > > > dtbs that was generated with u-boot.img or so, and it works. But > > > > > > maybe > > > > > > that should just list all of the valid DTBs that it needs in the > > > > > > defconfig to start with? I don't quite know, it was a case I hadn't > > > > > > considered at the time. > > > > > > > > > > > > > > > > Re-reading the thread, I can't see where that was mentioned. > > > > > > > > > > But yes, if some boards (still) need that, and have more than one > > > > > possible .dtb, the board can't set an OF_LIST different from the > > > > > default > > > > > consisting of DEFAULT_DEVICE_TREE because changing OF_LIST requires > > > > > SPL_LOAD_FIT || MULTI_DTB_FIT. > > > > > > > > > > How do we figure out if such boards even exist? > > > > > > > > Honestly at this point I've forgotten what this is all about. > > > > > > > > Perhaps the easiest approach is to create a new Kconfig to control > > > > whether a board-level .dtsi is included in the list of wildcard > > > > searches. Then you can enable it for your board without affecting > > > > others. > > > > > > That's getting things backwards, from what this cleanup does. Today we > > > have messy lists of "build these device trees" and then don't use most > > > of them, and some of the list is just Wrong (listing dts files as an > > > output). With the series to handle dtbo files, we could remove > > > virtually all of that, and the only use cases that don't Just Work still > > > are the ones I forget which board you mentioned (I think it was Samsung > > > tho?) where the defconfig doesn't list all of the device trees, just one > > > of them, and the other 5 that we build can also be easily used. Does > > > that ring a bell? > > > > Yes it does...but what is the problem here? > > Messy and unused and incorrect Makefile content.
The problem I see there is people using TARGET in arch/arm/dts/Makefile for example. There are 80 instances of that. The rules should depend on SoC (e.g. use ARCH_EXYNOS5), as Linux does it. > > > The DT files for an SoC are supposed to be buildable without needing > > to have the context of a particular board. > > They're still buildable, without an explicit rule, they just need to > (like they can now) be built explicitly. But isn't that creating dead code? It will rot. > > > I don't know what the point of the dtbo files is...is that for using > > overlays somehow at runtime? > > I think that side-tracked you from my question. > > > The defconfig does not need to mention all the DTs...we just need to > > make sure they get built. > > Why? This is the use case that I don't understand and isn't obvious. > > > Is this another instance of something that needs cleaning up, like the > > config fragments? > > No, this isn't like the config fragments. > > > I am find with making the boards list the DTs that they can run with, > > if there is an easy way of doing that. CONFIG_SPL_OF_LIST is just for > > SPL, I think. > > Yes, every board except for some use case you've described before as far > as I know lists the device trees that they use in the defconfig. Which > is why there's an impetus to clean up arch/*/dts/Makefile as 95% of > those lines can just be removed. It seems like you are wanting a board-level CONFIG which lists the DTs which need to be built for that board. Is that right? You are suggesting that this already exists, but I am not aware of it. Do you mean SPL_OF_LIST, perhaps? Regards, Simon