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 Ciaran

Alex

-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Mon, 26 Nov 2012 14:21:30 +0100 Alexander Graf wrote:

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

My take of this is that there is something wrong with initrd provided with the cubox image, thus the "undefined instruction". I think this is why Christian had to use a different image. I got a good initrd by running "zypper in --force kernel-cubox". I was able to do that by initially booting without an initrd, and mounting /dev/mmcblk0p1 at /boot. This puts the uImage and initrd in the root of /dev/mmcblk0p1, rather than the boot subdirectory. Since the newest uboot from Solid-run loads at 0x3600000 I think the initrd is too large to load at 0x3000000. So I ended up with a boot.script like this: setenv initrd_high "0xffffffff" setenv fdt_high "0xffffffff" setenv bootargs "loader=uboot console=ttyS0,115200n8 root=/dev/mmcblk0p2 showopts ${append}" setenv kerneladdr 0x1000000 setenv ramdiskaddr 0x2000000 setenv bootcmd "ext2load mmc 0:1 ${kerneladdr} uImage; ext2load mmc 0:1 ${ramdiskaddr} initrd; bootm ${kerneladdr} ${ramdiskaddr}"; boot The contents of /boot are now like this: boot config-3.6.0-1.2-cubox initrd-3.6.0-1.2-cubox symvers-3.6.0-1.2-cubox.gz uImage boot.scr do_purge_kernels lost+found sysctl.conf-3.6.0-1.2-cubox uImage-3.6.0-1.2-cubox boot.script initrd symtypes-3.6.0-1.2-cubox.gz System.map-3.6.0-1.2-cubox vmlinux-3.6.0-1.2-cubox.gz I also added to /etc/fstab: /dev/mmcblk0p1 /boot ext2 rw,relatime,errors=continue,user_xattr,acl 1 2 I don't know if this will work with the old u-boot and I don't know if it is consistent with other ARM platforms. But it works for me. Bill -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 26.11.2012, at 19:07, Bill Merriam wrote:

On Mon, 26 Nov 2012 12:19:25 -0500 Bill Merriam wrote:

...

On Mon, 26 Nov 2012 14:21:30 +0100 Alexander Graf wrote:

...

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

My take of this is that there is something wrong with initrd provided with the cubox image, thus the "undefined instruction". I think this is why Christian had to use a different image. I got a good initrd by running "zypper in --force kernel-cubox". I was able to do that by initially booting without an initrd, and mounting /dev/mmcblk0p1 at /boot. This puts the uImage and initrd in the root of /dev/mmcblk0p1, rather than the boot subdirectory.

Since the newest uboot from Solid-run loads at 0x3600000 I think the initrd is too large to load at 0x3000000. So I ended up with a boot.script like this:

setenv initrd_high "0xffffffff" setenv fdt_high "0xffffffff" setenv bootargs "loader=uboot console=ttyS0,115200n8 root=/dev/mmcblk0p2 showopts ${append}" setenv kerneladdr 0x1000000 setenv ramdiskaddr 0x2000000 setenv bootcmd "ext2load mmc 0:1 ${kerneladdr} uImage; ext2load mmc 0:1 ${ramdiskaddr} initrd; bootm ${kerneladdr} ${ramdiskaddr}"; boot

The contents of /boot are now like this:

boot config-3.6.0-1.2-cubox initrd-3.6.0-1.2-cubox symvers-3.6.0-1.2-cubox.gz uImage boot.scr do_purge_kernels lost+found sysctl.conf-3.6.0-1.2-cubox uImage-3.6.0-1.2-cubox boot.script initrd symtypes-3.6.0-1.2-cubox.gz System.map-3.6.0-1.2-cubox vmlinux-3.6.0-1.2-cubox.gz

I also added to /etc/fstab:

/dev/mmcblk0p1 /boot ext2 rw,relatime,errors=continue,user_xattr,acl 1 2

I don't know if this will work with the old u-boot and I don't know if it is consistent with other ARM platforms. But it works for me.

Bill

I see Alexander has already moved the boot addresses to 0x2000000 and 0x5000000. I will try that.

One thing that puzzles me, one of the reasons for using an initrd is so we can resize the root partition to make use of all of the mmc card, but I can't see anywhere that happens. Is there a script in mkinitrd that figures out there is free space on the card and resizes the root partition?

There are 2 separate initrds in the game: 1) the kiwi created firstboot initrd 2) the mkinitrd created initrd used on every boot thereafter The firstboot initrd is the one that does the resize magic. It's very big, but it only gets executed once. On firstboot, a new initrd gets created using mkinitrd tailored exactly to your board. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org