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.y...@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.y...@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 <tr...@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 <s...@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_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.
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.
Thanks,
- Kever
Kind regards,
Shantur
