On Fri, 2024-01-12 at 07:19 -0600, Nishanth Menon wrote: > 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)
Fwiw just testing; for the SK board the difference in size for tispl.bin and u-boot.img is about 200 kilobytes with this extra config. The SK board i have has about 32 megabytes for the hardware boot partition so unlikely an issue there; For the beagleplay it seems to be only 4M, but that's currently already on UDA indeed so shouldn't matter there. Mind i agree with you in general; and i was looking at moving the full u-boot into the hw boot partition on beagleplay already so the OS i flash doesn't have to be device specific. > > I am starting to wonder if > https://lore.kernel.org/u-boot/20231101170519.39627-1-...@ti.com/ > will help us here. Yes absolutely that would be perfect. Can i suggest we land it as is for now ("fat monolithic config") and once those patches land i'm happy to split things up? -- Sjoerd Simons Collabora Ltd.
