[PATCH 0/9] dts: Move to SoC-specific build rules

[Simon Glass]

-Scott as it is bouncing

Hi,

On Fri, Dec 29, 2023 at 9:46 AM Peter Robinson <pbrobinson at gmail.com> wrote:
>
> On Fri, Dec 29, 2023 at 12:23 AM Tom Rini <trini at konsulko.com> wrote:
> >
> > On Thu, Dec 28, 2023 at 07:48:08PM +0000, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, Dec 28, 2023 at 3:40 PM Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > On Thu, Dec 28, 2023 at 03:09:40PM +0000, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, Dec 28, 2023 at 2:23 PM Tom Rini <trini at konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Dec 28, 2023 at 01:37:07PM +0000, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Wed, Dec 27, 2023 at 1:21 PM Tom Rini <trini at konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Wed, Dec 27, 2023 at 08:23:56AM +0000, Simon Glass wrote:
> > > > > > > >
> > > > > > > > > U-Boot builds devicetree binaries from its source tree. As part of the
> > > > > > > > > Kconfig conversion, the Makefiles were updated to align with how this
> > > > > > > > > is done in Linux: a single target for each SoC is used to build all the
> > > > > > > > > .dtb files for that SoC.
> > > > > > > > >
> > > > > > > > > Since then, the Makefiles have devolved in some cases, resulting in
> > > > > > > > > lots of target-specific build rules. Also Linux has moved to using
> > > > > > > > > subdirectories for each vendor.
> > > > > > > > >
> > > > > > > > > Recent work aims to allow U-Boot to directly use devicetree files from
> > > > > > > > > Linux. This would be easier if the directory structure were the same.
> > > > > > > > > Another recent discussion involved dropping the build rules altogether.
> > > > > > > > >
> > > > > > > > > This series makes a start at cleaning up some of the build rules, to
> > > > > > > > > reduce the amount of code and make it easier to add new boards for the
> > > > > > > > > same SoC.
> > > > > > > > >
> > > > > > > > > One issue is that the ARCH_xxx Kconfig options between U-Boot and Linux
> > > > > > > > > are not always the same. Given the large number of SoCs and boards
> > > > > > > > > supported by U-Boot, it would be useful to align these where possible.
> > > > > > > >
> > > > > > > > I don't know why we should start with this now, and further not being on
> > > > > > > > top of Sumit's series to remove our duplicate dts files. And that's
> > > > > > > > where we can have the conversation about for which cases it even makes
> > > > > > > > sense to build all of the dts files for a given SoC.
> > > > > > >
> > > > > > > This is a completely different series - there are no conflicts with
> > > > > > > Sumit's series so it can be applied before or after it.
> > > > > > >
> > > > > > > My goal here is to clean up our build rules, rather than just throwing
> > > > > > > them all away, for reasons we have discussed previously. I filed [1]
> > > > > > > to track that.
> > > > > >
> > > > > > Yes, I'm saying we shouldn't be doing anything this series does until
> > > > > > after Sumit's series has landed. Along with the fact that I don't like
> > > > > > what's going on in this series.
> > > > >
> > > > > This seems to again be the disagreement over whether a single DT
> > > > > should be build for each board, or all the DTs for an SoC?
> > > >
> > > > It's about the disagreement on what we should be building, and what that
> > > > infrastructure looks like. I do not like adding extra rules for
> > > > "clarity" because they don't make things clearer, they lead to the
> > > > unclear mess we have today getting worse. Most instructions are _not_
> > > > "now take this dtb and this binary and .." but just "take this binary",
> > > > because we already have the rules and logic to ensure we build the
> > > > required dtbs. I also don't like the parts of this series that amount
> > > > to deck shuffling when we should just be taking the chairs away. There's
> > > > just not nor will there be a case for omap3/4/5 platforms of "change the
> > > > dtb", so building more is pointless. For other SoCs, there may be some
> > > > cases of "this could have been just a DT change", like
> > > > rock5b-rk3588_defconfig / rock5a-rk3588s_defconfig could share a board
> > > > dir, but the configs are different and the dts are different, so I don't
> > > > know that you could really just swap the dtbs.
> > >
> > > It is true that we have a different defconfig for each board, but IMO
> > > that is not good. It is an artifact of the way the build system works.
> > > IMO Kconfig should be used to define sensible defaults so that the
> > > defconfigs are nearly empty. Perhaps config fragments can be part of
> > > the mix, if we can agree on [1].
> > >
> > > But if we let this genie out of the bottle, it will be impossible to
> > > put back in. The devicetree should control the hardware in U-Boot and
> > > it should be possible to use the same U-Boot proper on all boards
> > > which use the same SoC.
> >
> > We've never been past the point where a few examples of closely related
> > boards can re-use the same U-Boot build and just change the device tree.
> >
> > It's going to be very SoC specific if we can ever do things like that,
> > and it will also likely in turn become a question of where did the
> > tricky bits that U-Boot used to do get shoved instead. You're not going
> > to combine board/beagle/beagle/beagle.c and board/ti/omap3evm/evm.c (and
> > ignoring all of the other omap3 boards) and get one binary that works on
> > both, and just uses DT. Let alone that no one wants to do that work.
> >
> > You've mentioned Rockchip before as maybe a better example, but
> > https://patchwork.ozlabs.org/project/uboot/list/?series=383579&state=* was
> > leading me to think that no, there's too much "this is what THIS
> > hardware does" that means that no, there's going to be hardware
> > variation that one must just handle in C. Or get more and new bindings
> > accepted upstream to try and make that be data driven, and also possibly
> > have to deal with "that's policy, not hardware" type arguments and so
> > forth.

Oh wow yes that is crazy! But you can always check the compatible
string if really necessary. It would be nice to use a sysinfo driver
for this sort of thing. I should just be a full-time code reviewer...

>
> Related I've seen issues with nearly identical rockchips devices that
> use different memory chips that as a result need different U-Boot
> builds because the early boot part needs to initialise a completely
> different set of memory and the two different sets of rules aren't
> detectable at run-time nor are they even small enough to fit into
> smem.

Some of the differences are real/important, like memory settings, some
are not. For boards with enough SRAM that SPL can use DM/DT, we can
deal with these.

But even if SPL does need to be custom, that is better than having a
full, separate U-Boot for every single board.

>
> > > [1] https://patchwork.ozlabs.org/user/todo/uboot/?series=380278
> >
> > Note that patchwork is annoying here and that for a series you've
> > assigned, you need to click on a patch in it, then the series link again
> > to get:
> > https://patchwork.ozlabs.org/project/uboot/list/?series=380278
> > which works for everyone. And append '&state=*' so that archive links
> > will still show it later once it's been accepted or superseded or what
> > have you.

OK, yes, I should have noticed that sorry.

Regards,
Simon