[PATCH v3] arch: arm: Kconfig: Enable BOOTSTD_FULL for Rockchip SoCs

[Shantur Rathore]

Hi Kever,

On Thu, Jan 18, 2024 at 3:10 AM Kever Yang <kever.yang at 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.yang at 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 at shantur.com> wrote:
> >>
> >> Hi Kever,
> >>
> >> On Tue, Jan 9, 2024 at 10:55 AM Kever Yang <kever.yang at 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 <trini at 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 at 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 <sjg at chromium.org>
> >>
> >> Signed-off-by: Shantur Rathore <i at 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-1-i@shantur.com/

Kind regards,
Shantur