Hi Nishanth, On Thu, 13 Jul 2023 at 16:34, Nishanth Menon <[email protected]> wrote: > > On 08:00-20230712, Simon Glass wrote: > > Hi Jason, > > > > On Tue, 11 Jul 2023 at 16:28, Jason Kacines <[email protected]> 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
