Hi Kever, On Thu, Jan 18, 2024 at 3:10 AM Kever Yang <kever.y...@rock-chips.com> wrote: > > Hi Shantur, > > On 2024/1/17 17:38, Shantur Rathore wrote: > > 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 ? > > You can add for RK3399 or both RK3399 and RK3588. >
Patch v5 [0] has been submitted with RK3399 and RK3588 [0] - https://patchwork.ozlabs.org/project/uboot/patch/20240121220447.663407-...@shantur.com/ Kind regards, Shantur