On Mon, Oct 02, 2023 at 08:43:41AM -0600, Simon Glass wrote: > 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.
It shouldn't be there at all since there's almost no cases where we "just" take an arbitrary dtb file and u-boot.img and then the system boot. That's what this series is about fixing. > > > 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. No, that's the problem we have today, people list something in the Makefile, since they think they need to list something, and then put the device trees they use in the defconfig. [snip] > > > 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? I mean today CONFIG_DEFAULT_DEVICE_TREE + CONFIG_OF_LIST + CONFIG_SPL_OF_LIST is set and correct for everyone board except some use case you have, which I think is something about exynos? And so we only need scripts/Makefile.dts in arch/*/dts/Makefile -- Tom
signature.asc
Description: PGP signature
