Am 08.04.2013 um 20:59 schrieb "G. Heim" <heelgeheim(a)hotmail.com>om>:
Thanks again. You wrote:
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
Basically I don't dare to install a new uboot and I'm not sure there is one
I tried a different approach, by compiling the kernel with:
# 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
You might guess... still nothing after booting on the mirabox, still stops after Starting
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
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
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
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!
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org