Hi Kever, On Wed, Jan 17, 2024 at 9:18 AM Kever Yang <kever.y...@rock-chips.com> wrote: > > Hi Shantur, > > On 2024/1/17 14:26, Shantur Rathore wrote: > > Hi Kever, > > On Wed, Jan 10, 2024 at 11:58 AM Shantur Rathore <i...@shantur.com> wrote: > > 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? > > Can you please suggest the way forward? > Initially the patch was for RockPro64 and then after discussion it was > suggested that as BOOTSTD_DEFAULT is very very limited > we should enable BOOTSTD_FULL for SoCs that can support multiple boot modes. > > Let's enable it for RK3588 first and then maybe other SoCs which not code > size sensitive. >
My requirement is for RK3399, so I will enable BOOTSTD_FULL for it. While at it do you want me to enable it for RK3588 as well ? Kind regards, Shantur