Hi Shantur,
On 2024/1/17 14:26, Shantur Rathore wrote:
Hi Kever,
On Wed, Jan 10, 2024 at 11:58 AM Shantur Rathorei@shantur.com wrote:
Hi Kever,
On Tue, Jan 9, 2024 at 10:55 AM Kever Yangkever.yang@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 Rinitrini@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 Rathorei@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 Glasssjg@chromium.org >> >> Signed-off-by: Shantur Rathorei@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