Am 08.04.2013 um 20:59 schrieb "G. Heim" <heelgeheim@hotmail.com>:
Hi Alex,
This does sound quite old, yeah. Can you update your u-boot version to something more recent? There's a good chance Linux never gets to see
Thanks again. You wrote: the dtb
Basically I don't dare to install a new uboot and I'm not sure there is one from Globalscale.
I tried a different approach, by compiling the kernel with: CONFIG_ARM_APPENDED_DTB=y # CONFIG_ARM_ATAG_DTB_COMPAT is not set
According to serveral sources one should be able to take the generated zImage, add armada-370-mirabox.dtb to it (as in "cat zImage armada-370-mirabox.dtb > mynewzImage") and convert it to a uImage with mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n linux-3.9-rc5 -d mynewzImage uImage
You might guess... still nothing after booting on the mirabox, still stops after Starting kernel:
3466263 bytes read ## Booting kernel from Legacy Image at 06400000 ... Image Name: linux-3.9-rc5 Created: 2013-04-08 17:31:00 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3466199 Bytes = 3.3 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
The next thing you could try here would be to find out what the kernel is doing. Either by enabling early printk or by manually dumping the kernel's log buffer. Do you have an ARM JTAG available? If so, you could check where the kernel hangs and dump the log_buf variable. If you don't have a JTAG, you can at least try the poor man's alternative. Shorten pin 15 and the opposing pin (gnd) on the JTAG header. That will reset the SoC, but leave RAM intact. Then in u-boot, do: # md.b <address> 500 This should log the kernel's printk buffer. To get <address>, load the vmlinux file that matches your zImage in gdb. Then do (gdb) x /2c log_buf That won't be able to dump anything, but will give you the virtual address of log_buf. Let's assume it's 0xc0100000 for this example. You need to make a physical address out of this. Cut off the beginning 0xc and add the offset, where your soc starts its ram. IIRC the Marvells start RAM at address 0, so you can simply do: # md.b 0x100000 500 Keep in mind that the log_buf address differs on different kernel builds, so you need to really pull it out of your own vmlinux binary.
Compared to my previous uImage it is a bit larger which is due to the armada-370-mirabox.dtb I think, but other than that I don't see anything that hints that it understands the dtb...
I see quite some emails on the http://www.spinics.net/lists/arm-kernel email list discussing kernel things about the mirabox, supposedly some of the persons on there have a running mirabox with a new kernel (at least newer than I have). Do you know anyone over there which I can ask if I can use their kernel source & kernel image?
Well, if you see people who are apparently having something working, just approach them :) Alex
I have uploaded my linux 3.9 rc 5 .config file here: http://pastebin.com/fswx9Q23.
If you have more things I might try, that would be wonderful, if not, then thanks a lot for taking the time to think this over!
Best regards,
Ge
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org