openSUSE on CuBoX (Day 5)

Today I decided to try to get to grips with building a new, modified image for the CuBox. In my last post I explained how easy it is to build the standard openSUSE image for CuBox by simply checking out the project and using the osc tool to build. The procedure here is basically the same, except this time I'm going to edit some files to try to make the CuBox boot automatically (you'll remember from my first post that manual intervention is currently needed at the Uboot stage).

I cd'd into my branch of openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox and ran 'osc up' to make sure I was working on the latest sources.

Given that the openSUSE image itself actually works (i.e. once you get past the Uboot stage, the image boots and you can log in and play around with it), I figured that the real issue must be the boot.scr script, which is a generated file. You can't just go and edit boot.scr and hope to be successful - that file is created by a mkimage command.

In the checked out branch I found a file called uboot-image-setup. "Aha", I thought, "this has to be it". That file contained the following:

#!/bin/bash

set -x

file=boot/boot.script
echo 'printenv kerneladdr || setenv kerneladdr ${kernel_addr_r}'   >> $file
echo 'printenv ramdiskaddr|| setenv ramdiskaddr ${ramdisk_addr_r}' >> $file
#CuBox Hack
echo 'if itest 1$arcNumber == 13905; then'                         >> $file
echo '  setenv kerneladdr 0x2000000'                               >> $file
echo '  setenv ramdiskaddr 0x3000000'                              >> $file
echo 'fi'                                                          >> $file
echo -n 'setenv bootcmd "'                                         >> $file
echo -n 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx; '          >> $file
echo -n 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot; '      >> $file
echo 'bootm ${kerneladdr} ${ramdiskaddr}";'                        >> $file
echo 'boot' 
mkopts="-A arm -O linux -a 0 -e 0 -T script -C none";
inputf="boot/boot.script";
result="boot/boot.scr";
if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then
        echo "Failed to create uboot script image"
        exit 1
fi

For whatever reason, this was simply not working. You can see why in my first and second posts about openSUSE on CuBox (i.e. systems hangs where the kernel is supposed to boot). I decided to see if I could add the commands that I used when manually intervening (see http://c-farrell.blogspot.de/2012/11/opensuse-on-cubox-day-2.html) to the script and see would it work. It did - kind of. Without getting into further details, here is the uboot-image-setup that worked for me:

#!/bin/bash

set -x

file=boot/boot.script
echo 'resetenv' >> $file
echo 'setenv kerneladdr 0x2000000' >> $file
echo 'setenv ramdiskaddr 0x3000000' >> $file
echo 'ext2load mmc 0:1 0x2000000 boot/linux.vmx' >> $file
echo 'ext2load mmc 0:1 0x3000000 boot/initrd.uboot' >> $file
echo -n 'setenv bootargs "'  >> $file
echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file
echo 'bootm 0x2000000 0x3000000' >> $file
echo 'boot' >> $file
mkopts="-A arm -O linux -a 0 -e 0 -T script -C none";
inputf="boot/boot.script";
result="boot/boot.scr";
if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then
        echo "Failed to create uboot script image"
        exit 1
fi

I'm not entirely sure if the resetenv is absolutely necessary. I hope not, and I'll have to test without that line, but for now, the CuBox boots without manual intervention. You get a dog ugly YaST firstboot, which you can use to initially configure your CuBox. I've already asked Juergen Weigert if there is anything that can be done to get YaST to look a bit better when using screen. Here's a screenshot - as you can see the colours are all screwed up. YaST is functional, though.

 I submitted my change to uboot-image-setup to the openSUSE project. If it's accepted, we'll hopefully have a new CuBox image available for download here soon.

I'm going to have a look through the Solid Run Wiki and Forums next, to see if I can get an idea of what we'd need to do to get graphics up and running. I imagine there will be a hard brick (proprietary graphics driver) wall that we'll run into, but maybe we can make some progress before that and then try to solve the brick wall problem some other way.