Hi Shantur,
On 2024/1/17 14:26, Shantur Rathore wrote:
Hi Kever,
On Wed, Jan 10, 2024 at 11:58 AM Shantur Rathore<[email protected]> wrote:
Hi Kever,
On Tue, Jan 9, 2024 at 10:55 AM Kever Yang<[email protected]> 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<[email protected]> 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<[email protected]> 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<[email protected]>
Signed-off-by: Shantur Rathore<[email protected]>
---
(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
