[PATCH v4 5/7] configs: am62x_evm_*: Enable USB and DFU support

[Sjoerd Simons]

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-afd@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.