On 14:09-20240112, Sjoerd Simons wrote: [...]
diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig index aa96c1b3125..f335eb11e63 100644 --- a/configs/am62x_evm_a53_defconfig +++ b/configs/am62x_evm_a53_defconfig
Should we make the a53 also a defconfig fragment allowing reuse across multiple boards?
Pros and cons. having all the various options (USB boot, ETH boot, misc other) as fragments would allow easier re-use but make it more complicated for the end-user to get a "full-featured" u-boot.
My personal preference, as i'm coming with a distribution background, is to always enable as much as possible in a default build to allow maximum flexibility for end-users; Those that need space/performance/whatever optimisation can always do custom builds.
It would be great if we could have a level of indirection here where by default a set of fragments get included such that it's invisible to the end-user that the underlying config is actually quite modular. But I don't think that's currently possible, hence preferring a fat defconfig such that the user/distro can just do `make am62x_evm_a53_defconfig` (and similar for beagleplay)
I understand, but I am looking to reduce duplication between boards and making it easier for new board devs to be able to pick the feature group they need - almost all am62x users who desire dfu on a53 will need the same options enabled. This also keeps the default u-boot foot print lower to allow for emmc boot0 partition limitations if any (I removed that dependency on beagle by using uda, but other platforms still keep u-boot in emmc boot0 and depending on the part and TEE binary size, the available space can be constraining)
I am starting to wonder if https://lore.kernel.org/u-boot/20231101170519.39627-1-afd@ti.com/ will help us here.