[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