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

[Shantur Rathore]

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 ?

Kind regards,
Shantur