Hi Randolph, On Fri, 10 Jul 2026 at 16:20, Randolph Sapp <[email protected]> wrote: > > Hello, > > We've got a device that's making it's way upstream "AM62Lx" that will break > the > current assumption in k3-binman.dtsi that specific binaries should or should > not > be produced based on the selected *architecture*. > > Right now I've seen we're just adding a platform specific "*-binman.dtsi" to > get > around that, but realistically speaking it's not defining anything *new*. > > I've got 2 ideas on how to clean this up a little bit. Wondering if this is > worth doing and if so, which way we'll want to go. > > --- > > 1. New Kconfig options > > I've seen that sunxi-u-boot.dtsi has a nice Kconfig parameter for their binary > definitions. A pattern that rockchip-u-boot.dtsi has adopted mostly (with one > exception that's still checking the compilation architecture). > > I like this pattern. I think it's very clear that none of the binman > definitions > are actually architecture specific, it's just a byproduct of the specific > device's boot-flow. > > We could easily replicate this with a TI_K3_TIBOOT, TI_K3_TISPL, and > TI_K3_UBOOT > (or similarly named) Kconfig options to remove both the proposed platform > specific binman.dtsi and the current k3-binman-capsule-r5.dtsi in one go. > > It wouldn't require touching that many files, and we can keep a single clean > include at the top of the u-boot.dtsi files. It'll also clean up the current > conditional includes used for EFI capsule support. > > --- > > 2. Reuse existing Kconfig options > > Almost every K3 platform supporting capsules already has an ifdef for the A53 > and R5 target platform variants in their corresponding u-boot.dtsi. We could > reuse that pattern and simply split the current k3-binman.dtsi into two parts. > > This would be a little weird if we kept the r5 naming convention for the files > though, as the new platform doesn't have an r5 involved in the boot process. I > kind of want to use "primary" and "secondary" naming since the split would > appear to be arbitrary without this whole explanation. > > This also means we'll have to add this pattern to any platform's u-boot.dtsi > that wasn't already supporting capsules. It'll result in an immediate line > count > increase across multiple files and a rather messy diff. > > --- > > Curious what opinions people have before I start shuffling files on my end.
Option 1 seems much better to me. The real problem is that CONFIG_ARM64 is being used as a proxy for 'which images does this build produce', and this proxy is breaking down. So the fix is to make the condition say what it means. A few suggestions: - Name the options after the artefacts rather than the boot stage, e.g. TI_K3_BINMAN_TIBOOT3 / _TISPL / _UBOOT, since 'tiboot3.bin' etc. are the things being gated. Whatever the spelling, the option should read as "this build produces this image". - Make them hidden options (no prompt), selected by the SoC/target Kconfig entries. Boards should not be able to choose an inconsistent set, and it keeps the cost per target to a single select. - The two capsule files can then merge into one, with each gated on the same option as the image it wraps. Obviously the genuinely architecture-specific parts (the FIT arch properties, load addresses) should stay keyed off CONFIG_ARM64 Regards, Simon
