From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 23 Feb 2018 13:29:19 -0500 Subject: [U-Boot] Support of kernels > 16 MiB on Raspberry Pi In-Reply-To: <20180223200019.37bf08c9@duuni> References: <1519329516.23822.16.camel@kurtz.be> <20180223145730.GK4311@bill-the-cat> <20180223200019.37bf08c9@duuni> Message-ID: <20180223182919.GC4311@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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: