Hi Kever,
On Thu, Jan 18, 2024 at 3:10 AM Kever Yang kever.yang@rock-chips.com wrote:
Hi Shantur,
On 2024/1/17 17:38, Shantur Rathore wrote:
Hi Kever,
On Wed, Jan 17, 2024 at 9:18 AM Kever Yang kever.yang@rock-chips.com wrote:
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@shantur.com wrote:
Hi Kever,
On Tue, Jan 9, 2024 at 10:55 AM Kever Yang kever.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 Rini trini@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@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@chromium.org
Signed-off-by: Shantur Rathore i@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_SYSRESETCan 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.
My requirement is for RK3399, so I will enable BOOTSTD_FULL for it. While at it do you want me to enable it for RK3588 as well ?
You can add for RK3399 or both RK3399 and RK3588.
Patch v5 [0] has been submitted with RK3399 and RK3588
[0] - https://patchwork.ozlabs.org/project/uboot/patch/20240121220447.663407-1-i@s...
Kind regards, Shantur