Hi Jonas,
On 8/3/26 9:09 PM, Jonas Karlman wrote:
The RK3506G1 has 64 MiB integrated DDR2, the RK3506G2 has 128 MiB
integrated DDR3 and the RK3506B support external memory up to 1 GiB.
Current memory layout cause issues using compressed kernels or ramdisk
due to the default load addresses being used.
RK3506 is an Aarch32 SoC, and Linux kernels on that architecture are
self-decompressing, U-Boot doesn't do anything with compressed kernels.
You can see that kernel_comp_addr_r is only ever used in cmd/booti.c
which depends on ARM64 to be actually built.
I simply recommend getting rid of this variable as it's quite
misleading. All other Aarch32 Rockchip SoCs we support don't seem to be
setting this variable, so no additional cleanup to do.
Same for kernel_comp_size.
Change the default load addresses to also work on SoC variants with
limited memory, keep all default addresses in the 0-64 MiB range.
old new
scriptaddr 5 MiB 2 MiB
pxefile_addr_r 6 MiB 1 MiB
kernel_addr_r 32.5 MiB 8 MiB
kernel_comp_addr_r 128 MiB 48 MiB
fdt_addr_r 30.5 MiB 4 MiB
fdtoverlay_addr_r 31.5 MiB 6 MiB
ramdisk_addr_r 96 MiB 48 MiB
That leaves less than 18MiB for an initramfs (don't forget U-Boot proper
is located at the end of the DRAM as far as I remember), which is very
little.
Do we really need 2MiB for the DTB and DTBO? 1MiB ought to be enough for
the DTB and I'm sure less than 1MiB ought to be enough per overlay
(overlay are loaded and applied one after the other). This should free
an additional 2MiB for either the kernel or initramfs.
The multi_v5_defconfig and multi_v7_defconfig zImage kernels as built by
KernelCI are respectively 7.5 and 11.6MiB as of yesterday, c.f.
https://dashboard.kernelci.org/build/maestro%3A6a7b3f4762f33761c0aedc06
https://dashboard.kernelci.org/build/maestro%3A6a7b3f6562f33761c0aedc2f
So maybe we can reserve a bit less than 40MiB for the kernel? But maybe
kernel_addr_r is also used for FIT images which may be much bigger than
the size of the kernel alone? The load/entry properties are required for
images of type kernel according to the FIT spec so that part isn't
something we need to deal with.
Have you figured out how to identify the variant of the RK3506 already?
Another option is to dynamically modify those variables (if they aren't
already part of the environment) based on the size of available DRAM
(and/or SoC variant). I don't like the idea too much but that could be a
way to stretch the available memory for each binary loaded by U-Boot as
much as possible.
Cheers,
Quentin
