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. -- Tom
signature.asc
Description: PGP signature
