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

Tom Rini trini at konsulko.com
Sat Dec 9 21:56:27 CET 2023


On Fri, Dec 08, 2023 at 01:59:26PM +0000, Shantur Rathore wrote:
> Hi Peter,
> 
> On Fri, Dec 8, 2023 at 12:59 PM Peter Robinson <pbrobinson at gmail.com> wrote:
> >
> > On Fri, Dec 8, 2023 at 12:52 PM Shantur Rathore <i at shantur.com> wrote:
> > >
> > > Hi Jagan,
> > >
> > > On Fri, Dec 8, 2023 at 11:13 AM Jagan Teki <jagan at amarulasolutions.com> wrote:
> > > >
> > > > On Sun, Nov 19, 2023 at 10:54 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
> > > >
> > > > Yes, but better to give this option to specific board vendors as
> > > > defaults are enough to boot 1st bootflow and what ever media's it has.
> > > >
> > >
> > > Yes, that's correct it is enough to boot but by default there is no option
> > > to choose what to boot from.
> > > This was discussed in an earlier version of this patch [0] where I was
> > > explicitly enabling only for RP64.
> >
> > What actual extra functionality does this provide, what is the impact
> > on the size of images? You've not provided reasonable justification
> > outside of very vague statements, it would be useful to know what the
> > added options actually solves.
> 
> BOOTSTD_FULL enables all the options in bootflow commands. This is needed if
> - you want to choose between multiple available bootflows rather than
> just boot one default.
> - if you need to list the available bootflows that bootstd has found
> - if you need to select and boot any bootflow other than default.
> By default all other commands in U-boot come with options to show details
> For example, nvme info, nvme detail, usb info, usb tree but with
> bootstd no way to know anything.
> 
> Image size - u-boot.itd without BOOTSTD_FULL - 1193984 bytes
> Image size - u-boot.itb with BOOTSTD_FULL - 1214976 bytes
> Difference - 20992 bytes
> 
> According to binman for RK3399 u-boot can take upto 4M [1] so we have
> ample space.
> 
> This was discussed in the previous patch in the link below [0]
> 
> [0] - https://patchwork.ozlabs.org/project/uboot/patch/20231111001329.537704-1-i@shantur.com/
> [1] - https://github.com/shantur/u-boot/blob/master/arch/arm/dts/rk3399-u-boot.dtsi#L68

If I'm recalling everything right, this also brings "bootflow" as a
command more in line with what could be done with distro_bootcmd in
terms of "cover every possible case and let the user override things"

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231209/c2548951/attachment.sig>


More information about the U-Boot mailing list