Hi Tom, On Sun, Dec 31, 2023 at 7:01 AM Tom Rini <tr...@konsulko.com> wrote: > > On Sun, Dec 31, 2023 at 05:45:00AM -0700, Simon Glass wrote: > > -Scott as it is bouncing > > > > Hi, > > > > On Fri, Dec 29, 2023 at 9:46 AM Peter Robinson <pbrobin...@gmail.com> wrote: > > > > > > On Fri, Dec 29, 2023 at 12:23 AM Tom Rini <tr...@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 <tr...@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 <tr...@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 <tr...@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. > > I'm not sure that's a use case anyone else has or wants, and I disagree > that building a unique SPL and then more generic U-Boot is a win, in > practical and effort terms.
Think about firmware update where you could have an update that supports all rk3399 boards, rather than 110 separate (and duplicate) firmware updates. > The only win I see there is it would be part > of what I've said before about how I do not want the "XPL" series you've > talked about before, but instead think Yamada-san was right in hindsight > and in short we should have "fooboard_defconfig", > "fooboard_spl_defconfig" and "fooboard_tpl_defconfig" and you make each > config and build each config by itself. In that context, yes, you could > have barvend-fooboard_rev1_spl_defconfig, > barvend-fooboard_rev2_spl_defconfig and barvend-fooboard_defconfig to > get a more generic U-Boot build. But nothing so much like an OS kernel > because we care about binary size and rarely does the OS vendor (but > some production cases in turn do), so outside of SoC-vendor where > showing off features is more important than size, most of the time, will > you see an actual use for SoC-generic U-Boot build. We'll see. The size cost for making things generic across an SoC is likely very small, particularly if the settings are in the DT where they belong. But I do accept we are not seeing the pressure yet. For XPL, there are pros and cons, but I thought we talked about that at the time and agreed that the need for Kconfig dependencies between phases makes having separate defconfigs too painful? Regards, Simon