Hi Kever, On Tue, Jan 9, 2024 at 10:55 AM Kever Yang <kever.y...@rock-chips.com> wrote: > > Hi Shantur, Tom, > > On 2023/12/10 04:45, Tom Rini wrote: > > On Sat, Dec 09, 2023 at 07:49:04PM +0000, Shantur Rathore wrote: > >> On Sat, Dec 9, 2023 at 7:18 PM Tom Rini <tr...@konsulko.com> wrote: > >>> On Fri, Dec 08, 2023 at 10:52:02AM +0000, Shantur Rathore wrote: > >>> > >>>> Hi Tom / Kever > >>>> > >>>> On Sun, Nov 19, 2023 at 5:24 PM Shantur Rathore <i...@shantur.com> wrote: > >>>>> Rockchip SoCs can support wide range of bootflows. > >>>>> Without full bootflow commands, it can be difficult to > >>>>> figure out issues if any, hence enable by default. > >>>>> > >>>>> Reviewed-by: Simon Glass <s...@chromium.org> > >>>>> > >>>>> Signed-off-by: Shantur Rathore <i...@shantur.com> > >>>>> --- > >>>>> > >>>>> (no changes since v1) > >>>>> > >>>>> arch/arm/Kconfig | 1 + > >>>>> 1 file changed, 1 insertion(+) > >>>>> > >>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > >>>>> index d812685c98..fca6ef6d7e 100644 > >>>>> --- a/arch/arm/Kconfig > >>>>> +++ b/arch/arm/Kconfig > >>>>> @@ -1986,6 +1986,7 @@ config ARCH_ROCKCHIP > >>>>> imply CMD_DM > >>>>> imply DEBUG_UART_BOARD_INIT > >>>>> imply BOOTSTD_DEFAULTS > >>>>> + imply BOOTSTD_FULL if BOOTSTD_DEFAULTS > >>>>> imply FAT_WRITE > >>>>> imply SARADC_ROCKCHIP > >>>>> imply SPL_SYSRESET > >>>> Can this please be merged in ? > >>> I wonder if we shouldn't really globally default to BOOTSTD_FULL if > >>> BOOTSTD_DEFAULTS for everyone. > >>> > >> Its matter of ~21KB in size, unless any platform is really to its > >> limits it should be alright. > > Maybe I need to re-check things too, since I wonder how much of that > > growth is re-enabling things that were removed when dropping the DISTRO > > stuff, and so for platforms just migrating over now it would be smaller > > in size if much. > > A board maintainer is free to enable this option, but I don't agree to > enable this for everyone. > > Not like rk3399 and rk3588, some of other SoCs always want a clean and > simple but usable U-Boot, > > eg. rk3036 and rk3308 are still in the list. >
The discussion is what we consider "usable U-Boot" By default bootstd doesn't have any options and not even to show what it's going to boot. Would it be acceptable if BOOTSTD_FULL is enabled for SoCs rather than boards? Kind regards, Shantur
