[U-Boot] Support of kernels > 16 MiB on Raspberry Pi
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.
The background is that ever since the upgrade to 4.14, the kernel has been failing to unpack the initramfs, complaining about "junk in [the] compressed archive" and I am currently trying to find where to best file a bug report about this!
Best regards
Alexander Kurtz
[0] http://snapshot.debian.org/package/linux/4.13.13-1/#linux-image-4.13.0-1-arm... [1] http://snapshot.debian.org/package/linux/4.14.17-1/#linux-image-4.14.0-3-arm... [2] http://snapshot.debian.org/package/linux/4.15.4-1/#linux-image-4.15.0-1-arm6... [3] https://github.com/u-boot/u-boot/blob/master/doc/README.distro#L250
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...
Best Regards, Jaehoon Chung
The background is that ever since the upgrade to 4.14, the kernel has been failing to unpack the initramfs, complaining about "junk in [the] compressed archive" and I am currently trying to find where to best file a bug report about this!
Best regards
Alexander Kurtz
[0] http://snapshot.debian.org/package/linux/4.13.13-1/#linux-image-4.13.0-1-arm... [1] http://snapshot.debian.org/package/linux/4.14.17-1/#linux-image-4.14.0-3-arm... [2] http://snapshot.debian.org/package/linux/4.15.4-1/#linux-image-4.15.0-1-arm6... [3] https://github.com/u-boot/u-boot/blob/master/doc/README.distro#L250
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Hi!
Thanks for confirming this! I see four ways how this can be solved:
1. I can locally adjust the memory locations to make my > 16MiB kernel work. The commit mentioned by Jaehoon Chung does this via a custom boot.scr, I did this by bumping $scriptaddr and $ramdisk_addr_r interactively during bootup and storing the changes to the Micro SD card with the "saveenv" command. 2. I could place a "uEnv.txt on the Micro SD card with those bumped values in it. This would make this work-around deployable via Puppet, but unfortunately reading "uEnv.txt" on bootup seems to be a board-specific feature, and the RPI code currently doesn't seem to have this feature. [0] 3. I could ask Debian to patch the upstream default values for these memory locations. After all, a distro bootloader which doesn't boot the distro kernel is pretty useless, so I imagine they would probably consider this. 4. U-Boot upstream could adjust the memory locations themselves. I would be happy to submit a patch for this, however I want get some feedback first: Would you guys accept such a patch, bumping the supported kernel size to e.g. 32 MiB or even 64 MiB?
I would prefer 4>3>2>1, what do you think?
Best regards
Alexander Kurtz
[0] https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h#L129
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.
+ 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.
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.
Hi!
I just wanted to let you know that I recently upgraded to U-Boot 2018.07 from Debian Experimental [0] and everything works now! Thanks to everybody involved [1]!
Best regards
Alexander Kurtz
[0] https://tracker.debian.org/pkg/u-boot [1] https://github.com/u-boot/u-boot/commits/v2018.07/include/configs/rpi.h
On 02/22/2018 12:58 PM, 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.
Yes, I expect those values are broken for kernels over 16MiB (and perhaps even smaller ones too, which may use memory after the compressed image for BSS during boot, which could overlap the ramdisk).
participants (5)
-
Alexander Kurtz -
Jaehoon Chung -
Stephen Warren -
Tom Rini -
Tuomas Tynkkynen