2012/8/26 Hauke Mehrtens <[email protected]>: > On 08/26/2012 03:03 PM, Rafał Miłecki wrote: >> This is some kind of continuation of: >> WNDR4500: OpenWRT freezing at "Starting program at 0x80001000" >> after more experiment and getting some knowledge about the problem. >> >> === >> >> The short summary: >> 1) When I prepare vmlinux.elf using >> mipsel-openwrt-linux-uclibc-objcopy without -O, it works. I can share >> such a image using tftpd and my laptop and boot from it using CFE tftp >> client on WNDR4500 >> 2) When I prepare trx and then chk from that vmlinux, it doesn't work. >> Installing such a .chk works fine, all data are correctly written to >> the 2nd flash, but it doesn't boot. It hangs like that: >> Checking crc...Loader:raw Filesys:raw Dev:nflash0.os File: Options:(null) >> Loading: ........ 4630972 bytes read >> Entry at 0x80001000 >> Closing network. >> Starting program at 0x80001000 >> >> The simplest (and most obvious) conclusion is that vmlinux is alright, >> but we can't make correct .chk image file. Not so easy... >> >> === >> >> I've decided to give OpenWRT chance to make .chk image using vmlinux >> from official Netgear's firmware. So I've just replaced path to >> vmlinux and used same tools, same commands OpenWRT does use normally. >> I've ever used mipsel-openwrt-linux-uclibc-objcopy from OpenWRT's >> directory! >> Then I've uploaded such a .chk image and booted from flash memory. It worked! >> >> Checking crc...Loader:raw Filesys:raw Dev:nflash0.os File: Options:(null) >> Loading: ....... 3784838 bytes read >> Entry at 0x80001000 >> Closing network. >> Starting program at 0x80001000 >> Linux version 2.6.22 ([email protected]) (gcc version 4.2.4) #223 >> Sun Aug 26 00:30:09 CEST 2012 >> >> Conclusion: OpenWRT tools and image build process is alright! >> >> === >> >> Another test was to use Netgear's tools to package OpenWRT's vmlinux. >> I've used mipsel-uclibc-linux26-objcopy from Netgear buildsystem, same >> for "lzma", "trx" and "packet". I've just replaced Netgear's vmlinux >> with OpenWRT's vmlnux. >> Finally I've uploaded .chk generated with Netgear's tools and... it didn't >> work. >> >> Checking crc...Loader:raw Filesys:raw Dev:nflash0.os File: Options:(null) >> Loading: ........ 4630372 bytes read >> Entry at 0x80001000 >> Closing network. >> Starting program at 0x80001000 >> >> Conclusion: Using Netgear tools doesn't help, vmlinux from OpenWRT >> still doesn't work >> >> === >> >> So we have two inconsistent conclusions here. Thanks to testing >> booting from tftp and elf, we can assume OpenWRT's vmlinux is alright. >> On the other hand packaging the same vmlinux with Netgear's tools >> results in non-bootable kernel. >> >> Do you have any idea what may be wrong? Is that possible for vmlinux >> to be so specific, that it's bootable using tftp and elf, but isn't >> bootable anymore after putting it compressed on flash memory? >> >> I'm not sure how I can compare vmlinux files for possible differences. >> Some quick test has shown: >> >>> file /home/zajec/openwrt.git/build_dir/linux-brcm47xx/linux-3.3.8/vmlinux >> /home/zajec/openwrt.git/build_dir/linux-brcm47xx/linux-3.3.8/vmlinux: >> ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically >> linked, BuildID[sha1]=0x5a4549b6018a9465864a805af9ffebf1f1f40701, with >> unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 >> = 0x3040000, not stripped >> >>> file >>> /home/zajec/tmp/WNDR4500-V1.0.0.58_1.0.13_src/src/linux/linux-2.6/vmlinux >> /home/zajec/tmp/WNDR4500-V1.0.0.58_1.0.13_src/src/linux/linux-2.6/vmlinux: >> ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically >> linked, stripped >> >> Does it mean anything? Can that BuildID/unknown capability be a source >> of problem? >> > > Hi Rafał, > > So you have these results: > OpenWrt image + OpenWrt tools -> not working > OpenWrt image + Netgear tools -> not working > Netgear image + OpenWrt tools -> working
That's right. > What about the LZMA loader used to load a LZMA compressed kernel, are > you using it? I thought you compressed the kernel with some special LZMA > setting and then you where able to boot. I don't use any gzipped LZMA loader (decompresser). I compress kernel with (no-optimal, dictionary less) LZMA and put that in the TRX. You can say, it's the LZMA compression that may cause the problems. Not really, as: 1) Using same LZMA compression on Netgear's vmlinux works 2) Using Netgear's LZMA compression doesn't help The LZMA settings I found out allow me to: 1) Pass early CFE test with OpenWRT's vmlinux (but it fails to start anyway) 2) Compress Netgear's vmlinux is the way it installs and runs correctly > Some devices have problems with the early printk, do you have > 116-MIPS-BCM47xx-Remove-CFE-console.patch in your kernel image? If your > device boots without 116-MIPS-BCM47xx-Remove-CFE-console.patch, could > you try a stock OpenWrt image and see if you get any message from the > Kernel, to rule out and problems with your recent kernel. I don't have that patch applied. I didn't think it's needed as elf tftp booting works fine (without this patch). I'll give it a chance anyway. > I think the CPU has problems accessing the last memory page could you > prevent that by modifying prom_init_mem() in prom.c, just hard code it > to 120MB ram. Can I do that by just putting "return;" after: max = ((unsigned long)(prom_init) | ((128 << 20) - 1)); ? -- Rafał _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
