ATH79: zboot and kernel parameters

ATH79: zboot and kernel parameters

[Phil Sutter]

Hi,

I have this Routerboard 493g from Mikrotik, thanks to the
OpenWrt-provided patches Linux-3.14.9 runs fine on it.

On top of that, I have added the necessary things to allow for zboot and
indeed it can boot a compressed kernel. The only problem with that is
for some reason the kernel parameters passed on by the boot loader do
not make it into the kernel.

I have tried printing the parameters from inside decompress.c by
mimicking the way head.S stores them for later access from inside C
code, but had no luck so far. For whatever reason, the variables'
contents seem to be zero.

Do you maybe have an idea what could be the culprit difference in
between an uncompressed kernel image and the decompressor that makes the
registers a0 to a4 inaccessible? Mostly due to my practically
non-existing knowledge about assembly I am stuck at this point.

Best wishes, Phil

Re: ATH79: zboot and kernel parameters

[Phil Sutter]

On Tue, Aug 05, 2014 at 01:14:43AM +0200, Phil Sutter wrote:
> I have this Routerboard 493g from Mikrotik, thanks to the
> OpenWrt-provided patches Linux-3.14.9 runs fine on it.
> 
> On top of that, I have added the necessary things to allow for zboot and
> indeed it can boot a compressed kernel. The only problem with that is
> for some reason the kernel parameters passed on by the boot loader do
> not make it into the kernel.
> 
> I have tried printing the parameters from inside decompress.c by
> mimicking the way head.S stores them for later access from inside C
> code, but had no luck so far. For whatever reason, the variables'
> contents seem to be zero.

Further investigation shows that registers a0 and a1 are indeed set by
the boot loader no matter if booting a compressed or uncompressed
kernel. In both cases a0 contains the value 0xB, a1 contains 0xA0872200.

The difference shows when accessing the memory at the location pointed
to by a1: the expected array of eleven char-pointers contains zeroes.

The boot laoder passes the following parameters:
console=ttyS0,115200 parts=1 boot_part_size=4194304 gpio=4023
HZ=340000000 mem=256M kmac=D4:CA:6D:A0:48:3A board=493G ver=3.10 boot=1
mlc=5

The uncompressed kernel sees the following values inside the
char-pointer array:
- a0871e00
- a0871e15
- a0871e1d
- a0871e34
- a0871e3e
- a0871e4b
- a0871e54
- a0871e6b
- a0871e76
- a0871e7f
- a0871e86

The values' distances match the parameters' lengths, so the boot loader
keeps the above kernel command line as continuous memory at address
0xa0871e00.

Explicitly printing (char *)0xa0871e00 does not show anything, so I
expect the memory at this address to be zero as well.

While searching for the code that could corrupt the mentioned memory
locations, I commented out the part of arch/mips/boot/compressed/head.S
commented to "Clear BSS" - and there it is, correct values show up.
Further debugging shows that _edata and _end are computed by the linker
to 0x804DFA40 and 0x808E1A50. Assuming these are in KSEG0 they include
the KSEG1 addresses above.

Putting this all together it occurs to me that vmlinuz is loaded to an
address so that it's bss section covers the area used by the boot loader
to pass it's parameters to the kernel. In order to overcome this, I have
tried to change the load address specified in arch/mips/ath79/Platform,
but without luck so far. Am I on the right track? Is this the right
place to fix this issue or are there alternative knobs to turn?

Best wishes, Phil

Re: ATH79: zboot and kernel parameters

[Phil Sutter]

Hey,

On Tue, Aug 12, 2014 at 03:29:42AM +0200, Phil Sutter wrote:
> On Tue, Aug 05, 2014 at 01:14:43AM +0200, Phil Sutter wrote:
> > I have this Routerboard 493g from Mikrotik, thanks to the
> > OpenWrt-provided patches Linux-3.14.9 runs fine on it.
> > 
> > On top of that, I have added the necessary things to allow for zboot and
> > indeed it can boot a compressed kernel. The only problem with that is
> > for some reason the kernel parameters passed on by the boot loader do
> > not make it into the kernel.
> > 
> > I have tried printing the parameters from inside decompress.c by
> > mimicking the way head.S stores them for later access from inside C
> > code, but had no luck so far. For whatever reason, the variables'
> > contents seem to be zero.
> 
> Further investigation shows that registers a0 and a1 are indeed set by
> the boot loader no matter if booting a compressed or uncompressed
> kernel. In both cases a0 contains the value 0xB, a1 contains 0xA0872200.
> 
> The difference shows when accessing the memory at the location pointed
> to by a1: the expected array of eleven char-pointers contains zeroes.
> 
> The boot laoder passes the following parameters:
> console=ttyS0,115200 parts=1 boot_part_size=4194304 gpio=4023
> HZ=340000000 mem=256M kmac=D4:CA:6D:A0:48:3A board=493G ver=3.10 boot=1
> mlc=5
> 
> The uncompressed kernel sees the following values inside the
> char-pointer array:
> - a0871e00
> - a0871e15
> - a0871e1d
> - a0871e34
> - a0871e3e
> - a0871e4b
> - a0871e54
> - a0871e6b
> - a0871e76
> - a0871e7f
> - a0871e86
> 
> The values' distances match the parameters' lengths, so the boot loader
> keeps the above kernel command line as continuous memory at address
> 0xa0871e00.
> 
> Explicitly printing (char *)0xa0871e00 does not show anything, so I
> expect the memory at this address to be zero as well.
> 
> While searching for the code that could corrupt the mentioned memory
> locations, I commented out the part of arch/mips/boot/compressed/head.S
> commented to "Clear BSS" - and there it is, correct values show up.
> Further debugging shows that _edata and _end are computed by the linker
> to 0x804DFA40 and 0x808E1A50. Assuming these are in KSEG0 they include
> the KSEG1 addresses above.
> 
> Putting this all together it occurs to me that vmlinuz is loaded to an
> address so that it's bss section covers the area used by the boot loader
> to pass it's parameters to the kernel. In order to overcome this, I have
> tried to change the load address specified in arch/mips/ath79/Platform,
> but without luck so far. Am I on the right track? Is this the right
> place to fix this issue or are there alternative knobs to turn?

Meanwhile I found a fix for the issue, namely adjusting the
BOOT_HEAP_SIZE in arch/mips/boot/compressed/Makefile. Limiting it from
4MB to 1MB was sufficient to allow at least gzip and lzma decompressors
to succeed.

I wonder why no other platform had to adjust this until now, but OTOH
there are not as many users of ZBOOT yet. While I know about the
platform specific (ifdef'd) code in the above Makefile, is there any
means to adjust the heap size from within board code?

Cheers, Phil