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

Kever Yang kever.yang at rock-chips.com
Wed Jan 17 10:17:45 CET 2024


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.

Thanks,

- Kever

>
> Kind regards,
> Shantur


More information about the U-Boot mailing list