[RFC PATCH 0/3] Minimal platform configuration

[Simon Glass]

Hi Nishanth,

On Thu, 13 Jul 2023 at 16:34, Nishanth Menon <nm at ti.com> wrote:
>
> On 08:00-20230712, Simon Glass wrote:
> > Hi Jason,
> >
> > On Tue, 11 Jul 2023 at 16:28, Jason Kacines <j-kacines at 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?

Yes, thank you.

Regards,
Simon