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
