* ATH79: zboot and kernel parameters @ 2014-08-04 23:14 Phil Sutter 2014-08-12 1:29 ` Phil Sutter 0 siblings, 1 reply; 3+ messages in thread From: Phil Sutter @ 2014-08-04 23:14 UTC (permalink / raw) To: linux-mips; +Cc: Wu Zhangjin 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ATH79: zboot and kernel parameters 2014-08-04 23:14 ATH79: zboot and kernel parameters Phil Sutter @ 2014-08-12 1:29 ` Phil Sutter 2014-08-13 16:59 ` Phil Sutter 0 siblings, 1 reply; 3+ messages in thread From: Phil Sutter @ 2014-08-12 1:29 UTC (permalink / raw) To: linux-mips, Wu Zhangjin 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ATH79: zboot and kernel parameters 2014-08-12 1:29 ` Phil Sutter @ 2014-08-13 16:59 ` Phil Sutter 0 siblings, 0 replies; 3+ messages in thread From: Phil Sutter @ 2014-08-13 16:59 UTC (permalink / raw) To: linux-mips; +Cc: Wu Zhangjin 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-08-13 16:59 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-08-04 23:14 ATH79: zboot and kernel parameters Phil Sutter 2014-08-12 1:29 ` Phil Sutter 2014-08-13 16:59 ` Phil Sutter
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.