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=8fdfbb...
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.