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

[Kever Yang]

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.

Thanks,

- Kever

>
> Kind regards,
> Shantur