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

Shantur Rathore i at shantur.com
Wed Jan 17 07:26:11 CET 2024


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.

Kind regards,
Shantur


More information about the U-Boot mailing list