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?