rockchip64/rk3318-box: move stack further from base addr to allow bigger uboot image

[alex3d]

Description

Move stack pointer further from base address to allow bigger uboot images.
Currently uboot stack pointer located 1MiB after text base, and uboot size with defconfig is barely less than 1MiB (1001472). So any small modification in code/config/compiler-version could overflow text area (my uboot blown up after I enabled verbose logging to debug btrfs boot problem).

How Has This Been Tested?

• Build and boot rk3318-box

Checklist:

• I have performed a self-review of my own code

[alex3d]

cc @paolosabatino

[paolosabatino]

Stupid uboot defaults... I agree on moving the stack pointer a bit away, but just a question: did you check it does not overlap with other areas dedicated to kernel, initd, device trees/overlays, ...?

[ColorfulRhino]

Interesting PR, I would like to learn more about this :)

Stupid uboot defaults... I agree on moving the stack pointer a bit away, but just a question: did you check it does not overlap with other areas dedicated to kernel, initd, device trees/overlays, ...?

How can you even check such things?
Like how would someone find out which addresses are the correct ones or to which addresses you have to write what?

This is very low level stuff 😄

[paolosabatino]

Interesting PR, I would like to learn more about this :)

You wouldn't, trust me! 😄

How can you even check such things? Like how would someone find out which addresses are the correct ones or to which addresses you have to write what?

This is very low level stuff 😄

The hard thing is to collect all the various addresses that are sparsed among the boot script (this is for rockchip64) but mostly in the uboot header files or uboot config (like CONFIG_TEXT_BASE, or CONFIG_CUSTOM_SYS_INIT_SP_ADDR this PR changes). There isn't a rule on where spot them, you just have to know, guess, or inspect the config file hunting for them.

Then comes the easy part: bring on the calculator and verify there is enough space to accomodate what they should accomodate. For example, assuming the physical RAM base address is 0x0 (this number depends upon the SoC), let's consider the u-boot proper base address CONFIG_TEXT_BASE set to 0x20000 and you expect its code to not exceed 1mb, then you should have nothing else in the memory range 0x20000:0x120000

[Kwiboo]

Please see u-boot/u-boot@008ba0d and u-boot/u-boot@f01a399 for new sane default stack and bss addresses that you can use. That fix/change is included in U-Boot v2024.07-rc1 and newer.

If you do not want to bump U-Boot to v2024.07-rc1 you can also use my stable rk3xxx-2024.04 branch. That branch includes all my (and others) Rockchip related fixes backported from v2024.07-rcX. It also includes a generic-rk3328_defconfig target that you probably also can use for rk3318 boards.

[alex3d]

I'm nowhere near uboot memory layout expert, it would be good if you can check my math.
AFAIK u-boot stack grows down as usual, so after this change space used will be from 12 MiB to some unknown location bellow it. Given that SP was TEXT_BASE+1MiB with nearly 1MiB u-boot "text", I suppose u-boot uses very little stack space (tens of KiB?).
One address close to new SP is LOAD_ADDR - it seems only small things are loaded there (scripts, etc).
Actially I've selected new SP value from grepping "not too big" CONFIG_CUSTOM_SYS_INIT_SP_ADDR from already existing armbian configs (for other boards).

u-boot config:
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc00000 (12 MiB)
CONFIG_TEXT_BASE=0x200000 (2 MiB)
CONFIG_SYS_LOAD_ADDR=0x800800 (~8.002 MiB)

u-boot env:
fdt_addr_r=0x01f00000 (31 MiB)
kernel_addr_r=0x02080000 (32.5 MiB)
kernel_comp_addr_r=0x08000000 (128 MiB)
loadaddr=0x800800 (~8.002 MiB)
pxefile_addr_r=0x00600000 (6 MiB)
ramdisk_addr_r=0x06000000 (96 MiB)
scriptaddr=0x00500000 (5 MiB)

boot-rockchip64.cmd:
load_addr=0x9000000 (144 MiB)

[alex3d]

Please see u-boot/u-boot@008ba0d and u-boot/u-boot@f01a399 for new sane default stack and bss addresses that you can use.

Thanks!
New default SP is 64 MiB, so it is not possible to cherry pick only this value to v2024.01 (too close to current kernel address 32.5 MiB).

[paolosabatino]

@alex3d It looks safe to me!

I just checked against v2024.04: existing v2024.01 patches apply correctly, uboot config has no new symbols and it compiles too. I just did not check on a device if it boots.

v2024.07-rc1 requires some HDMI/VOP patches rework instead. My plan would be to accept this fix right now, then rework the broken HDMI/VOP patches in this weekend and bump directly to v2024.07 as suggested by @Kwiboo, skipping v2024.04 completely.

[paolosabatino]

New default SP is 64 MiB, so it is not possible to cherry pick only this value to v2024.01 (too close to current kernel address 32.5 MiB).

Ah right, rockchip64 kernels are somehow big, though they should not exceed the 32mb marker (but who knows in the future...).. I wonder if it is sensible to move kernel and initramfs >= 64Mb and reserve a vast enough amount of space for them (eg. 64Mb for the kernel, 128mb for the initramfs) just for rk3328 (perhaps rk3399 too?)

From what I read in the commit, there should be ~27.5mb memory usable for the kernel since it starts at 32.5M and bss + stack starts at 60M; I guess we're really tight or even already outside the boundary with current kernel sizes

[ColorfulRhino]

2024.07 mainline is pretty stable actually, I've been using it for a while now on rk3588.

[Kwiboo]

From what I read in the commit, there should be ~27.5mb memory usable for the kernel since it starts at 32.5M and bss + stack starts at 60M; I guess we're really tight or even already outside the boundary with current kernel sizes

Once U-Boot proper is fully loaded and running, loading kernel, initrd etc can be done to any memory starting from 2M+ and can overwrite the stack location used by prior stages in the bootflow, U-Boot is fully relocated to top of total memory (including its new stack).

[paolosabatino]

@Kwiboo thanks for the clarification. I have to admit I never understood how and why relocation happens.

@alex3d Let's merge this, then I will rework the patches to move immediately to uboot v2024.07 and benefit from the rockchip fixes

[alex3d]

Heh, with relocation all that hunting for used address was really not needed :)

Just checked it in uboot console on rk3318-box. Only 82Mb from the top of ram are reserved and all remaining ram could be rewritten by memtest without problems for uboot.

=> bdinfo
...
 reserved.cnt = 0x1 / max = 0x10
 reserved[0]    [0x7aede000-0x7fffffff], 0x05122000 bytes flags: 0
...
=> mtest 0 7aedc000
Testing 00000000 ... 7aedc000:
Iteration:     27
Tested 26 iteration(s) with 0 errors.
=>