Bug#870185: FATAL: kernel 4.11.0-0.bpo.1-marvell does not boot on QNAP TS-219P II
On Sat, 2017-08-12 at 21:49 +0100, Ben Hutchings wrote:
> On Mon, 2017-07-31 at 18:10 +0200, Robert Schlabbach wrote:
> > Ok, I figured it out. I noticed that the 4.11 kernel has a more
> > "generous" memory layout than the 4.9 one:
> >
> > kernel 4.9:
> >
> > [ 0.000000] Memory: 504492K/524288K available (3777K kernel code, 371K rwdata, 1128K rodata, 296K init, 247K bss, 19796K reserved, 0K cma-reserved, 0K highmem)
> >
> > kernel 4.11:
> >
> > [ 0.000000] Memory: 502648K/524288K available (4096K kernel code, 398K rwdata, 1132K rodata, 1024K init, 248K bss, 21640K reserved, 0K cma-reserved, 0K highmem)
> >
> > So I suspected that the 4.11 kernel might be overwriting/corrupting
> > the initrd.img provided in memory before it gets to unpack it, and
> > changed the memory location from 0xa00000 to 0xc00000:
> [...]
> > Voila! It's finally booting!
> >
> > So, was the 4.11 kernel compiled/linked with a wrong alignment
> > padding setting? Or should the bootloader environment be changed to
> > permanently use the higher address for passing initrd.img to the
> > kernel?
>
> Should this be assigned to flash-kernel?
Sadly probably not.
There are three relevant load addresses, the one in the uboot header
added to the kernel (added by flash-kernel) and the two baked into the
uboot boot script, one for the kernel and one for the initrd. In some
systems there is a forth one in the uboot header on the initrd binary
but the QNAP systems don't appear to use that one, the initrd in flash
is the raw one.
Robert is modifying the boot script load address for the initrd which
flash-kernel has no control over. flash-kernel only controls the
address in the kernel u-boot header and IIRC that has to match a build
time constant in the kernel, so while we could perhaps coordinate a
change here I don't think there would be an appropriate kernel load
address which would help very much here since AIUI the conflicting
addresses which cause overlaps are the boot script ones.
The only thing I can think of would be simply reducing the size of the
armel kernel binary. I believe Roger was already looking into that?
I don't think looking into reducing the size of the initrd will help
since it is loaded second in RAM. I suppose it is worth double checking that /etc/initramfs-tools/initramfs.conf is using MODULES=dep (instead of most). I think d-i arranges that automatically on these platforms so it is highly probably Robert is already using it, Robert can you confirm?
Relatedly it does seem here like perhaps the kernels limit on kernel
size on these platforms needs to be shrunk to take into account the
boot time RAM layout considerations and not just the flash partition
sizes. Roger, what do you think?
There is one other option, which is to ask people to adjust their u-
boot boot scripts as Robert has done, however the QNAP systems are
often run headless and without access to the serial console (it's a
special cable which only a minority of users will have access to) so
that really is a last resort.
There's also the chainloaded u-boot solution, but realistically noone
appears to be working on that (me included).
Ian.
Reply to: