On 26.11.2012, at 14:11, Ciaran Farrell wrote:
On 26/11/12 14:05, Alexander Graf wrote:
On 25.11.2012, at 00:47, Cristian Rodríguez wrote:
Hi:
I stepped into issues in the latest cubox images booting.
after
Loading file "boot/initrd.uboot" from mmc device 0:1 (mmcda1)
** undefined instruction**
pc : [<96b6c61a>] lr : [<03635348>] sp : 035ff600 ip : 03604478 fp : da36f3e6 r10: bed5479d r9 : c57b9a3d r8 : 035fffcc r7 : c46396a8 r6 : dfb1fd5f r5 : c2595706 r4 : cbfa3250 r3 : ffffffff r2 : 00000001 r1 : 007a1200 r0 : 00000000 Flags: nzcv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
..
workaround setenv ramdiskaddr 0x5000000 instead of 0x3000000 ,however I have NO IDEA if this is gonna break something else, the machine appears to boot and behave correctly though. Do you have a document explaining the memory layout of the system handy? Then we can double-check whether that location is safe to use. And maybe that'd also give us a hint on why 0x3.. doesn't work for you.
Is Table 45 in http://www.marvell.com/application-processors/armada-500/assets/Armada-510-H... of any use? This document as well as three others are linked from http://www.solid-run.com/mw/index.php/CuBox_hardware_specification
Unfortunately not, but all things considered I'd say RAM starts at address 0. That basically means that instead of loading the initrd to offset 48MB, you load it to offset 80MB. I'd say the reason you need to do that is that for some reason the kernel is too big / has problems protecting the initrd region. But moving it higher up surely isn't a problem. I'll do the change throughout the code, including in second-boot u-boot scripts and in Factory. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org