[1/1] config: CONFIG_SPL_SIZE_LIMIT for VisionFive 2

The size of SPL including the 1 KiB header added by spl_tool may not exceed
128 KiB. Without the header this leaves 127 KiB for spl/u-boot-spl.bin.

We should check this value when building to avoid oversized binaries.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
---
 configs/starfive_visionfive2_defconfig | 1 +
 1 file changed, 1 insertion(+)

On 5/16/23 6:11 AM, Heinrich Schuchardt wrote:
> The size of SPL including the 1 KiB header added by spl_tool may not exceed
> 128 KiB. Without the header this leaves 127 KiB for spl/u-boot-spl.bin.
> 
> We should check this value when building to avoid oversized binaries.
> +CONFIG_SPL_SIZE_LIMIT=0x1fc00
Hi Heinrich, would you mind specify where the limit is coming from? I flashed my
vf2 board with a ~140KiB SPL without any problem.

On 5/16/23 21:33, Bo Gan wrote:
> On 5/16/23 6:11 AM, Heinrich Schuchardt wrote:
>> The size of SPL including the 1 KiB header added by spl_tool may not 
>> exceed
>> 128 KiB. Without the header this leaves 127 KiB for spl/u-boot-spl.bin.
>>
>> We should check this value when building to avoid oversized binaries.
>> +CONFIG_SPL_SIZE_LIMIT=0x1fc00
> Hi Heinrich, would you mind specify where the limit is coming from? I 
> flashed my
> vf2 board with a ~140KiB SPL without any problem.


https://github.com/starfive-tech/Tools/commit/8c5acc4e5eb7e4ad012463b05a5e3dbbfed1c38d

seems to have changed the limit in the tooling.

@Samin,

Could you, please, indicate how the 180048 bytes was derived and what is 
the physical limit for the SPL size.

Best regards

Heinrich

@Heinrich Some background information I discovered by experimenting with my vf2 board:

The only reasonable place to load SPL is the L2 LIM, which is 2M in size mapped at
0x8000000. This region consists of 16 0x20000 sized regions, each one can be used as
either L2 cache way or SRAM (not both). From top to bottom, you have way 0-15. When
ways are enabled, they can't be disabled without reset. Effectively, as you enabling
more and more L2 cache, this SRAM region shrinks. The way 0 is always enabled, so SPL
can only use at most 0x1e0000 bytes of memory.

On 5/16/23 12:56 PM, Heinrich Schuchardt wrote:
> 
> https://github.com/starfive-tech/Tools/commit/8c5acc4e5eb7e4ad012463b05a5e3dbbfed1c38d
> 
> seems to have changed the limit in the tooling.

I don't know how they derive the number 180048, but my guess is they just pick some
number that fits their u-boot build. For correctness, it really depends on how ROM is
loading SPL, and where does ROM allocate its data/stack during loading, so it won't
collide with the SPL being loaded. It might also be that ROM uses S7 DTIM to load SPL,
and doesn't touch L2 LIM at all. The ROM is close-sourced, thus, not very easy to know
without reverse-engineering it. The defconfig already defines

> https://github.com/u-boot/u-boot/blob/6e1852c/configs/starfive_visionfive2_defconfig#L37
> CONFIG_SPL_MAX_SIZE=0x40000
> CONFIG_SPL_BSS_START_ADDR=0x8040000

256KiB of SPL sounds like a reasonable number to me. 128KiB might be a little bit small
when you have max loglevels enabled, and -DDEBUG. I think we can probably just change
CONFIG_SPL_MAX_SIZE to CONFIG_SPL_SIZE_LIMIT, and be done with it.

On 5/17/23 02:17, Bo Gan wrote:
> @Heinrich Some background information I discovered by experimenting with 
> my vf2 board:
> 
> The only reasonable place to load SPL is the L2 LIM, which is 2M in size 
> mapped at
> 0x8000000. This region consists of 16 0x20000 sized regions, each one 
> can be used as
> either L2 cache way or SRAM (not both). From top to bottom, you have way 
> 0-15. When
> ways are enabled, they can't be disabled without reset. Effectively, as 
> you enabling
> more and more L2 cache, this SRAM region shrinks. The way 0 is always 
> enabled, so SPL
> can only use at most 0x1e0000 bytes of memory.
> 
> On 5/16/23 12:56 PM, Heinrich Schuchardt wrote:
>>
>> https://github.com/starfive-tech/Tools/commit/8c5acc4e5eb7e4ad012463b05a5e3dbbfed1c38d
>>
>> seems to have changed the limit in the tooling.
> 
> I don't know how they derive the number 180048, but my guess is they 
> just pick some
> number that fits their u-boot build. For correctness, it really depends 
> on how ROM is
> loading SPL, and where does ROM allocate its data/stack during loading, 
> so it won't
> collide with the SPL being loaded. It might also be that ROM uses S7 
> DTIM to load SPL,
> and doesn't touch L2 LIM at all. The ROM is close-sourced, thus, not 
> very easy to know
> without reverse-engineering it. The defconfig already defines
> 
>> https://github.com/u-boot/u-boot/blob/6e1852c/configs/starfive_visionfive2_defconfig#L37
>> CONFIG_SPL_MAX_SIZE=0x40000
>> CONFIG_SPL_BSS_START_ADDR=0x8040000
> 
> 256KiB of SPL sounds like a reasonable number to me. 128KiB might be a 
> little bit small
> when you have max loglevels enabled, and -DDEBUG. I think we can 
> probably just change
> CONFIG_SPL_MAX_SIZE to CONFIG_SPL_SIZE_LIMIT, and be done with it.

128 KiB is exceeded when adding the not yet merged patch series for 
updating the DTB based on EEPROM data. This is why I hit the old limit 
in spl_tool.

I would prefer if we could add the functionality of spl_tool into 
U-Boot's mkimage and let binman handle invoking it.

CONFIG_SPL_SIZE_LIMIT would be without the 1 KiB header added by 
spl_tool. So should CONFIG_SPL_MAX_SIZE and CONFIG_SPL_SIZE_LIMIT be set 
to 0x3FC00?

Best regards

Heinrich