Re: [RFC PATCH 0/3] Minimal platform configuration

[Nishanth Menon <nm@ti.com>]

On 08:00-20230712, Simon Glass wrote:
> Hi Jason,
> 
> On Tue, 11 Jul 2023 at 16:28, Jason Kacines <j-kacines@ti.com> wrote:
> >
> > When someone attempts to bring up a custom board using TI SoCs (am62x in
> > this case), it often takes several days for someone to reduce the
> > current configuration from the TI EVM/SK boards to a configuration that
> > works for their board.
> >
> > The goal of these changes is to allow for a minimal boot configuration
> > to exist within UBoot that someone can access directly in order to
> > test their boards for a sign of life before beginning development. This
> > is all done with the hope to increase ease of use and reduce the
> > upbringing process from several days to a few hours.
> >
> > With the use of fragments, the base defconfigs reside in configs/ and
> > the config fragments reside in board/../
> >
> > There is still quite a lot of board specific code inside board_init_f()
> > that will need attention later, however this series begins the process
> > of splitting the am62x's configs into a separate generic defconfig
> > everyone can use for new board wakeups with individual board/ti/*.config
> > fragments for each board varient.
> 
> How about setting up some common defaults for your arch using Kconfig,
> so that the board defconfigs are much smaller?
> 
> In general, boards in U-Boot have far too many individual settings.
> Most of them should use a sensible default.
> 
> Going in the direction you have here just continues that tradition,
> inventing what I feel is an unnecessary solution.

Challenge here is SRAM. When we enable OSPI for example or USB DFU for a
group of our devices -> they follow a specific pattern of CONFIG
options, which over and over again, we mess up by having individual
config options being updated. This is similar in nature to the kernel
config fragment motivation as well - in fact just worse with SRAM
limitations with which SPL or early stages of bootloaders need to
function with.

Look at today's list:
am65x_evm_a53_defconfig
am65x_evm_r5_defconfig
am65x_evm_r5_usbdfu_defconfig
am65x_evm_r5_usbmsc_defconfig
am65x_hs_evm_a53_defconfig
am65x_hs_evm_r5_defconfig

The usbdfu or msc stuff just replicates it self over and over as people
enable that for next TI SoC and so and so forth.

Other patterns are stuff like Android configurations or distro boot
configurations - or uefi - instead of each vendor re-discovering the
right options, the opens up the possibility of standardized fragments
that any platform that chooses can pick.

I am with you that there are too many individual settings at times, and
there is a need to keep the defconfigs small as well. One thing we have
to fight against constantly is boot time memory availability and speed
of boot requirements. but those are details of the exact Kconfig options
enabled etc.. for us at least, config fragments opens up a sustainable
and low-fail option of consistently enabling features across SoCs and
platforms. I think many folks who struggle with the same will concur
as well. We are definitely open to following a structured set of rules
when and how it should be used.. but hopefully, this helps explains?
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D