Hi Tom,
On 8/24/26 6:55 PM, Tom Rini wrote:
On Mon, Aug 24, 2026 at 04:31:29PM +0200, Quentin Schulz wrote:
Hi Jonas,
On 8/13/26 11:09 AM, Jonas Karlman wrote:
Hi Quentin,
On 8/12/2026 11:49 AM, Quentin Schulz wrote:
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.
Thanks for looking deeper, I will drop these two in v2.
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.
Agree, I thought I had seen DTB may need to use a 4 MiB aligned address,
e.g. for RISC-V, but ARM seem to only need it to be any 64-bit aligned
address.
8-byte alignment is required by the Device Tree spec, c.f.
https://devicetree-specification.readthedocs.io/en/latest/chapter5-flattened-format.html#alignment
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.
My local Rockchip ARMv7 kernel without loadable module support is now
around 26M for Image and 9.9M for zImage, it used to be just below 32M
for Image when I also enabled more debugging options and partial support
for other SoCs. So support for up to 32M uncompressed would be nice :-)
What's the benefit of using an uncompressed image in your workflow?
I have made some minor adjustments, see below, that seem to work to boot
into a minimal initramfs busybox rootfs in my lab.
Looking closer at ARM kernel booting, I can see that during
decompression the kernel will be decompressed to close to start of DRAM,
and if the compressed and decompressed images overlaps the compressed
image will be copied to end of the target uncompressed image before it
continues.
See
https://people.kernel.org/linusw/how-the-arm32-linux-kernel-decompresses.
"Close to start of DRAM" depends on TEXT_OFFSET of the kernel I think.
U-Boot also tries to move ramdisk and FDT to end of memory to reduce the
chance of the kernel decompression to overwrite FDT or ramdisk.
Unless initrd_high and fdt_high are set I believe?
And setting those in your default environment in tree gets me very
cranky because it often ends up breaking users in unexpected ways (for
example, yes, you put things in non-overlapping correctly aligned
places, but some other user that just picked up the board didn't know
and loaded some FIT image and ... now it blows up. And this is based on
history of that happening).
It was not a suggestion for people to use it, just to make sure I
understood cases in which they aren't moved around. I vaguely remember
those variables from 10y ago on Allwinner when somehow this fixed
stuff/made things worse, so I am just simply aware of those variables :)
Cheers,
Quentin
