[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#809476: Linux 4.4-rc6 fails to boot on QNAP TS-109



Package: linux
Version: 4.4~rc6-1~exp1
Severity: important

I tried to boot Debian's 4.4-rc6 kernel on my QNAP TS-109 and it failed
to boot with:
[   19.380002] Unpacking initramfs...
[   19.380044] Initramfs unpacking failed: junk in compressed archive

After spending ages bisecting and not getting anywhere, I spoke to Ben
Hutchings who thought it was a kernel size issue and that part of the
initramfs was now getting overwritten.  And he was right (disabling
some options made the kernel boot).

On the QNAP TS-109, the kernel/ramdisk are loaded like this:

> cp.b 0xff200000 0x800000 0x3fffff
> setenv bootargs console=ttyS0,115200n8 root=/dev/ram rw initrd=0x800000,0x3fffff
> bootm 0xff000000

So the ramdisk is copied to memory while the kernel is loaded from flash
(where we have a 2 MB limit due to the partition size).

u-boot loads it like this:

## Booting image at 00400000 ...
   Load Address: 00008000
   Entry Point:  00008000

This is the load address used by the original QNAP firmware.

I guess the kernel is uncompressed and overwrites part of the ramdisk
located at 0x800000.  I don't really get this part because
arch/arm/boot/Image is only 6.1 MB (but vmlinux is around 9 MB, even
on the kernel that works).

Anyway, I guess we have two options:

1) In addition to ensuring the compressed kernel is below 2 MB (to fit
in the flash partition) we should ensure that the uncompressed kernel
is smaller than some limit.

or:

2) We could change the load address to 0x00c08000 which is after the
ramdisk (the ramdisk is loaded at 0x800000 and can only be 4 MB due
to the size of the MTD partition).  u-boot says:
> Addresses 20M - 0M are saved for the U-Boot usage.
so I guess this is ok.  I made this change and the kernel and ramdisk
loaded correctly.

However, I don't fully understand the boot process.  I've copied some
ARM experts.  Can you comment whether using 0x00c08000 as the load
address is safe / the correct thing to do, or is there a better
solution?

If this is the right approach, I suggest the following patch to
flash-kernel:

diff --git a/db/all.db b/db/all.db
index 936d498..4344265 100644
--- a/db/all.db
+++ b/db/all.db
@@ -877,7 +877,7 @@ Kernel-Flavors: orion5x
 Machine-Id: 1565
 Mtd-Kernel: Kernel
 Mtd-Initrd: RootFS1
-U-Boot-Kernel-Address: 0x00008000
+U-Boot-Kernel-Address: 0x00c08000
 Required-Packages: u-boot-tools
 Bootloader-Sets-Incorrect-Root: yes
 
@@ -898,7 +898,7 @@ Kernel-Flavors: orion5x
 Machine-Id: 1601
 Mtd-Kernel: Kernel
 Mtd-Initrd: RootFS1
-U-Boot-Kernel-Address: 0x00008000
+U-Boot-Kernel-Address: 0x00c08000
 Required-Packages: u-boot-tools
 Bootloader-Sets-Incorrect-Root: yes
 

-- 
Martin Michlmayr
http://www.cyrius.com/


Reply to: