On 2/12/24 12:51, Quentin Schulz wrote:
Hi Jonas,
On 2/12/24 12:08, Jonas Karlman wrote:
Hi Quentin,
On 2024-02-12 11:37, Quentin Schulz wrote:
Hi Jonas,
On 2/12/24 01:59, Jonas Karlman wrote:
With the stack and text base used by U-Boot SPL and proper on RK3399 there is a high likelihood of overlapping when U-Boot proper + FDT nears 1 MiB in size.
Currently the following memory layout is used:
- 0x00000000 (@0 MiB): U-Boot SPL text base
- 0x00040000 (@256 KiB): TF-A
- 0x00200000 (@2 MiB): U-Boot proper text base
- 0x00300000 (@3 MiB): U-Boot proper init stack
- 0x00400000 (@4 MiB): U-Boot SPL init stack
- 0x00400000 (@4 MiB): U-Boot SPL bss
- 0x02000000 (@64 MiB): U-Boot SPL reloc stack
- 0x08400000 (@132 MiB): optional OPTEE
SPL load TF-A, U-Boot proper and optional OPTEE after SPL stack has relocated, meaning that there is room for close to 2 MiB (@2-4 MiB). However, the initial stack used by U-Boot proper is limiting the size of U-Boot proper + FDT to below 1 MiB (@2-3 MiB).
Instead change to use the following memory layout:
- 0x00000000 (@0 MiB): U-Boot SPL text base
- 0x00040000 (@256 KiB): TF-A
- 0x00200000 (@2 MiB): U-Boot proper text base
- 0x00400000 (@4 MiB): U-Boot SPL init stack
- 0x00800000 (@8 MiB): U-Boot proper init stack (changed)
- 0x02000000 (@32 MiB): U-Boot SPL bss (changed)
- 0x04000000 (@64 MiB): U-Boot SPL reloc stack
- 0x08400000 (@132 MiB): optional OPTEE
This should leave room for loading and running a U-Boot proper close to 6 MiB (@2-8 MiB) in size. When U-Boot proper has relocated is should be possible to use @2-132 MiB and @164 MiB+ for scripts, kernel etc.
With the moved SPL reloc stack it is also possible to use a much larger malloc area in SPL, e.g. using default SPL_STACK_R_MALLOC_SIMPLE_LEN.
Signed-off-by: Jonas Karlman jonas@kwiboo.se
Do we not need to update memory addresses in the environment as well?
The addresses in environment is to my knowledge only used in U-Boot proper after relocation. And at that time we should be free to use @2+ MiB up to somewhere close to gd ram_top/relocaddr. The optional Rockchip OPTEE blobb may occupy @132-164 MiB, but I do not think loading OPTEE blobs works as-is, so that may not be a big issue.
Upstream OP-TEE OS seems to support RK3399, c.f. https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/plat-rockchip/p...
It does indeed. I run the quarterly release tests on a RockPi4B. We record which platforms have been tested in the commit description for each release tag. For example, see [1].
In the configuration I test, OP-TEE is loaded at 0x30000000 and uses 32MB (for some reason the Linux DT reserves 36MB but I don't think it matters much).
[1] https://github.com/OP-TEE/optee_os/commit/18b424c23aa5a798dfe2e4d20b4bde3919...