Hi Jonas, Il giorno mar 13 ott 2026 alle ore 23:01 Jonas Karlman <[email protected]> ha scritto: > > Hi Massimo, > > On 10/5/2026 1:44 PM, Massimo Pegorer wrote: > > Hi Jonas, > > > > Il giorno dom 4 ott 2026 alle ore 20:54 Jonas Karlman > > <[email protected]> ha scritto: > >> > >> Hi Massimo, > >> > >> On 10/2/2026 6:36 PM, Massimo Pegorer wrote: > >>> The configuration options SPL_BSS_START_ADDR and SPL_BSS_MAX_SIZE are > >>> guarded by SPL_HAS_BSS_LINKER_SECTION and SPL_BSS_LIMIT options in the > >>> common/spl/Kconfig file where they are originally defined. Addition of > >>> a second config statement without 'depends on' guard causes these two > >>> options to be put in the configuration even when the guard is not > >>> selected, which is unneeded and sounds wrong. > >>> > >>> Signed-off-by: Massimo Pegorer <[email protected]> > >>> --- > >>> arch/arm/mach-rockchip/Kconfig | 2 ++ > >>> 1 file changed, 2 insertions(+) > >>> > >>> diff --git a/arch/arm/mach-rockchip/Kconfig > >>> b/arch/arm/mach-rockchip/Kconfig > >>> index 1a2e7847c9e..5ed774159be 100644 > >>> --- a/arch/arm/mach-rockchip/Kconfig > >>> +++ b/arch/arm/mach-rockchip/Kconfig > >>> @@ -836,11 +836,13 @@ config SPL_HAS_BSS_LINKER_SECTION > >>> default y if ARM64 > >>> > >>> config SPL_BSS_START_ADDR > >>> + depends on SPL_HAS_BSS_LINKER_SECTION > >> > >> This change is causing make to prompt for SPL_BSS_MAX_SIZE when building > >> e.g. tinker-s-rk3288_defconfig. > >> > >> Maximum size in memory allocated to the SPL BSS (SPL_BSS_MAX_SIZE) [] > >> (NEW) > >> > >>> default 0x63f80000 if SPL_TEXT_BASE = 0x60000000 > >>> default 0x43f80000 if SPL_TEXT_BASE = 0x40000000 > >>> default 0x03f80000 if SPL_TEXT_BASE = 0x00000000 > >>> > >>> config SPL_BSS_MAX_SIZE > >>> + depends on SPL_BSS_LIMIT > >>> default 0x8000 if SPL_BSS_START_ADDR = 0x63f80000 > >>> default 0x8000 if SPL_BSS_START_ADDR = 0x43f80000 > >>> default 0x8000 if SPL_BSS_START_ADDR = 0x03f80000 > >> > >> Possible adding something like following? > >> > >> default 0x8000 if !SPL_HAS_BSS_LINKER_SECTION > > > > What about selecting SPL_BSS_MAX_SIZE default based on SPL_TEXT_BASE > > instead of > > SPL_BSS_START_ADDR? > > Unsure, the original intent of the BSS_START_ADDR dependency was to only > affect boards that had transitioned to use the common bss and stack > addresses introduced in the commit 008ba0d56d00 ("rockchip: Add common > default bss and stack addresses"). > > Not fully sure about current migration state for AArch64 targets, I do > not have any rk3368 boards so never tried to migrate targets for that > SoC to use these common addresses. Most/all other AArch64 targets should > now use these defaults so it is likely these checks can be simplified. > > > > > This seems to me more straightforward. As this configuration states, there > > are > > cases where SPL_HAS_BSS_LINKER_SECTION (and thus SPL_BSS_START_ADDR) is not > > needed, but SPL_BSS_MAX_SIZE is. Therefore, I would avoid a default > > definition > > based on SPL_BSS_START_ADDR. > > It is likely these complex conditions have overplayed its need now that > most AArch64 targets have been migrated to use these defaults. > > > > > On the other hand, I've just noticed that the value is the same in the three > > SPL_BSS_MAX_SIZE default statements, so it would probably be even clearer to > > have something like (not tested yet): > > > > config SPL_BSS_MAX_SIZE > > default 0x8000 if SPL_BSS_LIMIT > > > > What do you think? Thanks for your revision. > > Please check current values used for ARCH_ROCKCHIP boards using the > qconfig.py tool. If all boards use this value, we can likely just move > this default to normal "config SPL_BSS_MAX_SIZE" in common/spl/Kconfig. > > default 0x8000 if ARCH_ROCKCHIP
I will check. Thanks for your time in reviewing my patch. Regards, Massimo > > One goal should be to continue migrate as many boards/SoCs to use the > common bss and stack addresses. It should mostly be older ARMv7 SoCs > that I do not have access to that never have been migrated. I do have > access to rk322x boxes, and have some early work for that SoC, but too > much other work to try and upstream before circling back to rk322x :-) > > Regards, > Jonas > > > > > Regards, > > Massimo > > > >> > >> Regards, > >> Jonas >
