2012/8/26 Rafał Miłecki <[email protected]>: > 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)); > ?
Wohoo, I've applied ~10 patches I suspected to be important and it worked! Hooray =) Now I just have to find out, which one is the important one! Then I can start sending my patches :) -- Rafał _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
