[U-Boot] Support of kernels > 16 MiB on Raspberry Pi

[Tom Rini <trini@konsulko.com>]

On Fri, Feb 23, 2018 at 08:00:19PM +0200, Tuomas Tynkkynen wrote:
> + agraf
> 
> On Fri, 23 Feb 2018 09:57:30 -0500
> Tom Rini <trini@konsulko.com> wrote:
> 
> > On Fri, Feb 23, 2018 at 04:47:06PM +0900, Jaehoon Chung wrote:
> > > On 02/23/2018 04:58 AM, Alexander Kurtz wrote:  
> > > > Hi!
> > > > 
> > > > I am using U-Boot to boot Debian Buster arm64 (standard kernel with a
> > > > dracut-based initramfs) via an extlinux.conf on my Raspberry Pi 3. 
> > > > 
> > > > Recently, the Debian kernel grew beyond 16 MiB:
> > > > 
> > > >     4.13: /boot/vmlinuz-4.13.0-1-arm64 == 16448000 bytes (< 16 MiB) [0]
> > > >     4.14: /boot/vmlinuz-4.14.0-3-arm64 == 17539584 bytes (> 16 MiB) [1]
> > > >     4.15: /boot/vmlinuz-4.15.0-1-arm64 == 17867264 bytes (> 16 MiB) [2]
> > > > 
> > > > https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h#L129 says:
> > > > 
> > > >     #define ENV_MEM_LAYOUT_SETTINGS \
> > > >     "fdt_high=ffffffff\0" \
> > > >     "initrd_high=ffffffff\0" \
> > > >     "fdt_addr_r=0x00000100\0" \
> > > >     "pxefile_addr_r=0x00100000\0" \
> > > >     "kernel_addr_r=0x01000000\0" \
> > > >     "scriptaddr=0x02000000\0" \
> > > >     "ramdisk_addr_r=0x02100000\0" \
> > > > 
> > > > Am I correct in assuming that this default configuration will break
> > > > with kernels > 16 MiB? The Readme [3] seems to confirm this, but I
> > > > wanted to ask for explicit confirmation here.  
> > > 
> > > Especially, this is occurred about arm64 kernel.
> > > Because it wil be overlapped with other image address, if kernel image is over than 16MB.
> > > 
> > > In my case, i'm using the private boot.scr.img for booting script.
> > > I had just added the kernel_addr_r=0x02d000000.
> > > 
> > > Just Refer to below:
> > > https://review.tizen.org/git/?p=platform/kernel/u-boot.git;a=commit;h=8fdfbbeb8a4b2f8c8e66824709e48d9abdb23534  
> > 
> > I would strongly recommend setting the values here based on what
> > linux/Documentation/arm/Booting and linux/Documentation/arm64/boot.txt
> > describe as the maximum limits for each of these locations.  And take a
> > peek at include/configs/ti_armv7_common.h in U-Boot on how I set these
> > for the various TI platforms.
> > 
> 
> I sent a patch for the load addresses a while ago, for which I never got
> around to writing a follow-up it seems:
> 
> https://lists.denx.de/pipermail/u-boot/2017-June/295889.html
> 
> FWIW, I have my doubts of the relocation mechanism used for DTs and initrds
> because on ARM, the size of the lowmem mapping in Linux (which dictates the
> highest permitted address) depends on not only build-time options like
> CONFIG_VMSPLIT_* but also on boot-time options like vmalloc=xxxM.
> 
> Also, at least when using the extlinux.conf boot method, because the files
> (kernel, DTB, initrd) are first loaded to RAM to the addresses specified
> in the environment and only then relocated, the files can still smash each
> other in memory during load time. So enabling relocation doesn't actually
> help, tweaking the load addresses is still required.

It's true that on ARM you can have different splits, but at least when I
wrote the limits for TI, I either picked the smallest possible, or said
"if you have less than 256MB on your system, you need to make these
manually".  I honestly don't recall which atm.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180223/11a221a7/attachment.sig>