I'm doing some testing on a possible new recovery firmware based off LEDE (OpenWrt fork), but booting anything that isn't a Debian uImage gives weird results.
I suspect that there is something wrong in my images, but any opinion on it is welcome.
I build kirkwood generic target from source, and I took the zimage and appended the dtb as stated (different names to suit my case)
EDIT: I checked with ghex (a hex editor), the zimage I'm using does NOT have a dtb appended. Images I build show the text from the dtb at the end of the uImage or zImage.
But when I try booting it (either from NAND or from a usb thumbdrive)
with this bootcmd (or with fatload instead of nand read)
I get this
This means the Uboot detects a valid uImage and checksums match, but something fails when starting it.
Anything shown after that (if it worked at all) would have come first from the uImage's onboard kernel decompression tool, and then from kernel itself.
For example if I try to start stock kernel image i get also a "decompressing image ..............................................................................................(and so on).............done, booting" before it hangs, so the uImage's decompressor works even if the kernel fails afterwards.
Same thing as above happens with trying to boot a zimage with the dtb appended
For the sake of doing it (as it usually works too) I used also the "go" command instead of bootm/z
And it hangs there.
But it does not end here. I tried also with other uImages+appended-dtb generated by LEDE build system.
That's called "uImage" but cannot start with a bootm? Wat?
But the plot thickens, I also try bootz on the same thing
So, with bootz it starts it. Also tried with "go" command and it starts it too.
What happens if I try to bootz my own uImages?
Also tried to change memory address for loading and starting, same results.
ARGHHHH :(
I'm now going to try out other things like making the images from Debian, in the box (as currently I'm making them with the mkimage of OpenSUSE, since I'm using OpenSUSE), or trying to see where the damn LEDE buildsystem assembles the images and mimic it (and/or use its own tool to do it, as the build system builds also the whole toolchain from source), so I can at least get a uImage that boots with bootz for lulz but at least boots.
EDIT: for those interested, these are the images I'm using (if it gives a 404 error retry later, it's probably still uploading) https://dl.dropboxusercontent.com/u/47541136/linux/tools_for_Kirkwood_installer/uImages_to_test.tar.bz2
I suspect that there is something wrong in my images, but any opinion on it is welcome.
I build kirkwood generic target from source, and I took the zimage and appended the dtb as stated (different names to suit my case)
EDIT: I checked with ghex (a hex editor), the zimage I'm using does NOT have a dtb appended. Images I build show the text from the dtb at the end of the uImage or zImage.
cp -a zImage-3.17.0-kirkwood-tld-1 zImage.fdt cat dts/kirkwood-goflexnet.dtb >> zImage.fdt mv uImage uImage.orig mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-3.17.0-kirkwood-tld-1 -d /media/sdb1/boot/zImage.fdt /media/sdb1/boot/uImage sync
But when I try booting it (either from NAND or from a usb thumbdrive)
with this bootcmd (or with fatload instead of nand read)
bootcmd_recovery=run recovery_bootargs; nand read 0x8000 nand0,7 ; bootm 0x8000
I get this
NAND read: device 0 offset 0x4640000, size 0xa00000 10485760 bytes read: OK ## Booting kernel from Legacy Image at 00008000 ... Image Name: Recovery-nsa310b-lmsensor-redusb Created: 2016-08-29 21:58:22 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1873248 Bytes = 1.8 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ...
This means the Uboot detects a valid uImage and checksums match, but something fails when starting it.
Anything shown after that (if it worked at all) would have come first from the uImage's onboard kernel decompression tool, and then from kernel itself.
For example if I try to start stock kernel image i get also a "decompressing image ..............................................................................................(and so on).............done, booting" before it hangs, so the uImage's decompressor works even if the kernel fails afterwards.
Same thing as above happens with trying to boot a zimage with the dtb appended
NSA310> fatload usb 0 0x8000 zimage-kirkwood-nsa310b-lmsensor-redusbled reading zimage-kirkwood-nsa310b-lmsensor-redusbled 1873248 bytes read in 85 ms (21 MiB/s) NSA310> bootz 0x8000 Kernel image @ 0x008000 [ 0x000000 - 0x1c6408 ] Starting kernel ...
For the sake of doing it (as it usually works too) I used also the "go" command instead of bootm/z
NSA310> fatload usb 0 0x8000 uimage-kirkwood-nsa310b-lmsensor-redusbled reading uimage-kirkwood-nsa310b-lmsensor-redusbled 1873312 bytes read in 91 ms (19.6 MiB/s) NSA310> go 0x8000 ## Starting application at 0x00008000 ...
And it hangs there.
But it does not end here. I tried also with other uImages+appended-dtb generated by LEDE build system.
NSA310> fatload usb 0 0x8000 lede-kirkwood-dockstar-uimage reading lede-kirkwood-dockstar-uimage 1871076 bytes read in 89 ms (20 MiB/s) NSA310> bootm 0x8000 Wrong Image Format for bootm command Error occured, error code = 112 ERROR: can't get kernel image!lolwtf?
That's called "uImage" but cannot start with a bootm? Wat?
But the plot thickens, I also try bootz on the same thing
NSA310> bootz 0x8000 Kernel image @ 0x008000 [ 0x000000 - 0x1c6408 ] Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.4.19 (alby@openSUSE-xeon) (gcc version 5.4.0 (LEDE GCC 5.4.0 r1435) ) #0 Tue Aug 23 22:21:34 2016 [ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=0005397f [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] Machine model: Seagate FreeAgent Dockstar ## and goes on and on for a while until it finally figures out something is wrong as this isn't a Dockstar, panics and reboots.
So, with bootz it starts it. Also tried with "go" command and it starts it too.
What happens if I try to bootz my own uImages?
NSA310> fatload usb 0 0x8000 uimage-kirkwood-nsa310b-lmsensor-redusbled reading uimage-kirkwood-nsa310b-lmsensor-redusbled 1873312 bytes read in 91 ms (19.6 MiB/s) NSA310> bootz 0x8000 Bad Linux ARM zImage magic!No. Still not like it.
Also tried to change memory address for loading and starting, same results.
ARGHHHH :(
I'm now going to try out other things like making the images from Debian, in the box (as currently I'm making them with the mkimage of OpenSUSE, since I'm using OpenSUSE), or trying to see where the damn LEDE buildsystem assembles the images and mimic it (and/or use its own tool to do it, as the build system builds also the whole toolchain from source), so I can at least get a uImage that boots with bootz for lulz but at least boots.
EDIT: for those interested, these are the images I'm using (if it gives a 404 error retry later, it's probably still uploading) https://dl.dropboxusercontent.com/u/47541136/linux/tools_for_Kirkwood_installer/uImages_to_test.tar.bz2