Hi Tom, On Mon, 2 Oct 2023 at 10:22, Tom Rini <[email protected]> wrote: > > On Mon, Oct 02, 2023 at 09:39:18AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 2 Oct 2023 at 09:12, Tom Rini <[email protected]> wrote: > > > > > > 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 <[email protected]> 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 <[email protected]> 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 > > > > > > > > <[email protected]> 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. > > > > I'm really not sure that replacing build rules with a board CONFIG is > > a good idea. I suppose part of my confusion is why the Makefile is > > considered a problem? > > Because it's duplicative and as Rasmus points out, often wrong.
To me, that is under the control of the board maintainers. They should not put CONFIG_SYS_BOARD in the DT...it obviously goes against what DT is for and I'm not sure what binding would allow it anyway. If it helps, I could do a little series to remove those? I think it is just arch/arm/dts/rockchip-optee.dtsi ? This seems like a case of throwing the baby out with the bathwater. > > > > > > > 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. > > > > If they don't list something, it won't build, right? > > No, everyone builds fine since CONFIG_DEFAULT_DEVICE_TREE is pretty much > always set. And for run time, if we need more, *OF_LIST gets set. OK, makes sense. So what DT does u-boot.bin contain in that case? Just the default? And u-boot.img contains a FIT with all of them? > > > > [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 > > > > Yes exynos5 boards (the original reason for DT) have / had the same > > u-boot-nodtb.bin and you can add the DT you want to boot it on > > particular hardware. That is one of the goals of DT. > > Yes, but "and you concat the two files" isn't common. We _can_ keep the > EXYNOS list, if that's actually being used. But most of that list is > not, as far as I can tell, because the flow is "U-Boot binarie(s) + DTB > files + stuff" to get the correctly formatted blob for the firmware. I believe rockchip allows just the DT to be changed, to work on a board with the same SoC. In principle it would be possible to build a common u-boot-nodtb.bin too, e.g. for 32-bit. We are trying to use DT (and not custom C code) to deal with the differences between boards. So long as that is preserved, I am happy enough. > > > The OF_LIST option is a little vague but I think it means that the DTs > > are packaged into a FIT in u-boot.img - is that right? But they > > presumably have to be built first. > > No, they don't have to be built first because scripts/Makefile.dts > ensures that we build everything in *OF_LIST. That is from this commit: 3609e1dc5f4 dts: automatically build necessary .dtb files which was for use by custom boards using a private branch. Did it have a wider purpose that I didn't understand? Regards, Simon
