Re: [PATCH 2/6] rockchip: rk3506: Update ENV_MEM_LAYOUT_SETTINGS

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).

-- 
Tom

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQTzzqh0PWDgGS+bTHor4qD1Cr/kCgUCaox3igAKCRAr4qD1Cr/k
CiCPAQCrA3j+AQJ+HUwqGdbELLsmKK3UDowK4phn4qgx6b6HfQD+NWOG8IdMkUwx
q1wFt/TwZJcx0NJeKzvk5wwb0BlqHAI=
=oOSV
-----END PGP SIGNATURE-----