Proposed k3-binman.dtsi and k3-binman-capsule.dtsi cleanup

[Randolph Sapp]

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.

Regards,
Randolph