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
