Freitag, 14. Dezember 2012

Graphics on the CuBox!!!

Finally, at least partial success on getting a graphical interface working on the CuBox. The trick was the bootargs line that the boot.scr needs to contain. How I did this was as follows:

  1. cd /boot
  2. vi boot.script
  3. append video=dovefb:lcd0:1280x720-24@60-edid clcd.lcd0_enable=1 clcd.lcd1_enable=0 to the bootargs line
  4. save and exit the editor
  5. run the command old boot.scr
  6. make a new boot.scr with mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n 'graphics maybe' -d boot.script boot.scr
  7. make sure a HDMI cable is plugged into the CuBox (and into a monitor)
  8. reboot
And this is what it looks like:

 

In the video you'll see that I tried to start YaST while running in a root session. The CuBox spat out an error: xdg-su: no graphical method available for invoking '/sbin/yast2' as 'root' - so maybe that is just not supported anywhere...
 

Donnerstag, 13. Dezember 2012

openSUSE 12.2 CuBox kernel RPM

Here are dropbox links to the kernel I compiled, for anyone who wants to do some testing. It would be especially good if somebody could test if the bugs that Christian found with the earlier 3.6 kernel that we were using are still present or if they have now been fixed:

  • CESA (crypto engine) doesn't work, even if the module is compiled in the kernel. This is apparently a known issue and requires out-of-tree patches.
  • Watchdog timer driver (so I can configure systemd to reboot the machine when it hangs) is not built, apparently due to a bug in Kconfig's . CONFIG_WATCHDOG_ORION has depends that do not include DOVE platform.
  • Same as above with sound output

kernel-cubox-3.4.20-0.armv7hl.rpm
kernel-cubox-debuginfo-3.4.20-0.armv7hl.rpm
kernel-cubox-debugsource-3.4.20-0.armv7hl.rpm
kernel-cubox-devel-3.4.20-0.armv7hl.rpm
kernel-cubox-devel-debuginfo-3.4.20-0.armv7hl.rpm

To install kernel-cubox-3.4.20-0.armv7hl.rpm you should (e.g. on your CuBox already running the openSUSE 12.2 image) grab the rpm:
wget http://dl.dropbox.com/u/90949965/kernel-cubox-3.4.20-0.armv7hl.rpm
Then "update" the kernel using:
rpm -U --oldpackage kernel-cubox-3.4.20-0.armv7hl.rpm

Reboot and (hopefully) you'll be running a new (well old as you have actually downgraded your kernel from 3.6 to 3.4) kernel which (hopefully) incorporates a whole load of improvements over the openSUSE generic kernel which we were using up to now.

Let me know how you get on!

Trying to get some graphics output on CuBox

I started doing some research to see if I could get some graphics output. I figured the JeOS image obviously has no graphics, so I installed the xfce pattern (it brought a whole load of xf86 drivers as well as xorg libs with it, so I figured that it would know what packages it needed).

After a reboot, the system booted right back into text mode. startx said something about no screens found. I installed Bill Merriams xorg-dove packages along with its requires (the libgfx proprietary stuff from Marvell, which is also on Bill's home project http://download.opensuse.org/repositories/home:/wmerriam:/branches:/openSUSE:/12.2:/ARM:/Contrib:/Cubox/standard/armv7hl/

After another reboot, still back in text mode. I tried Xorg -config and that told me there was no device to configure (I can see xorg-dovefb in the list of available drivers though).

 I saw on http://www.solid-run.com/phpbb/viewtopic.php?f=6&t=685&hilit=No+devices+to+configure that some chap suggests changing the boot command to include video=dovefb:lcd0:1280x720-24@60-edid clcd.lcd0_enable=1 clcd.lcd1_enable=0 (i.e. the bootargs command). I'd need an entirely new image for that, though, because those bootargs are entered in the uImage-setup of the JeOS-cubox package.

Trying to figure out where to go from here...

openSUSE on CuBox (Day 9)

Kernel woes! After successfully getting an openSUSE 12.2 image done for the CuBox last week (or was it the week before last), Alex Graf and I figured that it was about time that we went about getting graphics working on openSUSE on the CuBox. In order to do so, extensive work needed to be done on the kernel. Instead of reinventing the wheel, we decided that, since the CuBox is in the Contrib: section of openSUSE anyway, we could just compile and use a non-standard (as in not upstream) variant. Not exactly elegant, because it basically means a kind of proprietary kernel fork that somebody needs to look after specifically for CuBox, but better than only rudimentary support for a headless CuBox.

So, on Tuesday Alex Graf and I found a Xilka kernel version 3.4.7 which had the source code and patches readily availabile online. Seeing as openSUSE 12.2 uses a 3.4 kernel (at least the default does), we decided to see if we could apply the patches that the Xilka developers had for the CuBox to the openSUSE kernel. It turns out that they all applied cleanly and the kernel actually compiled without choking.

Once the kernel RPM was compiled, I copied it over to the CuBox and installed it in place of the standard kernel that comes with the image I built last week. The command rpm -U <kernel>.rpm didn't work directly, as the image I built has a 3.6 kernel and this new one is 3.4. rpm -U --oldpackage <kernel>.rpm worked fine though. It spat some warnings, but everything seemed to work.

After rebooting, however, the first thing that happened once the kernel started kicking was a fat kernel backtrace. It looked like there was a problem with SATA. Alex's helpful advice was to go back to the series.conf (where the patches and the order in which they are to be applied is defined) and comment out these ones. After recompiling and reinstalling the rpm, I rebooted. This time it got past the place where it died with a backtrace but just fell into a kernel panic:

VFS: Cannot open root device "disk/by-id/mmc-SU04G_0x609dcec5-part2" or
unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available
partitions:
b300         3872256 mmcblk0  driver: mmcblk
  b301          153604 mmcblk0p1 00000000-0000-0000-0000-000000000000
  b302         3210990 mmcblk0p2 00000000-0000-0000-0000-000000000000
  b303          506045 mmcblk0p3 00000000-0000-0000-0000-000000000000
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
 
Again, with Alex's help we traced this to the following missing lines in the config for the CuBox kernel:
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
So, I added those lines and rebuilt the kernel yet again. This time, it worked. What this means is that we now  have a CuBox specific kernel on openSUSE so we can start taking advantage of some of the work that others have been doing - like graphics, for example.
I'm working on getting the kernel source tree into the build service now. 
Stay tuned! 
 
 

Mittwoch, 5. Dezember 2012

If you are having trouble with the network interface on your CuBox (running openSUSE)

This blog post is a slight deviation from the main series that I'm doing on running openSUSE on CuBox as it relates to a very small (but very important) area - the network interface. If you've been following the posts I've been doing and maybe also the opensuse-arm@opensuse.org mailing list, you'll have seen that I was having issues with how the network interface doesn't come up after each reboot.

The CuBox network interface hardware has a so-called 'hardware address' - also called 'MAC address'. When openSUSE boots, it looks for network hardware with a MAC address that it recognises. For example, if openSUSE has already set up MAC address 00:50:4B:B7:1B:23 as eth0 with static IP 192.168.178.20 etc, as soon as that MAC address is seen when booting, the same network interface - eth0 - can be set up with those settings.

The problem actually occurred before openSUSE even booted - during the uboot stage. If you enter the uboot commandline interface (by pressing any key quickly when watching the CuBox start over a serial connection) you will see when you enter the printenv command that the CuBox saves some network relevant data to its own flash (i.e. permanently saves). One of the key value pairs that the CuBox saves is ethaddr. If there is a problem with the key value pair stored (e.g. uboot detects a bad signature in the flash etc), a new random MAC is generated and assigned to the hardware before control is handed over to openSUSE. That means that openSUSE will not recognise the network hardware as it has a different MAC address. This then means that the network interface will not be brought up. You will need to go through YaST -> Network Devices to setup a "new" interface. This will probably be eth1 (or ethn+1 where n is the number of the interface before your last reboot - I was on eth5 before I went to work on the problem).

The solution is to enter uboot and to save the current environment. Before reboot, check what the value of the MAC address of the the hardware is (ifconfig will help). After a reboot, press the infamous 'any' key quickly to enter the commandline interface. Then check what value is stored as ethaddr using the commant printenv ethaddr. It should be the same as the one that ifconfig showed. If not, fix it with setenv ethaddr <MAC address that ifconfig showed>. In my example above, that would be setenv ethaddr 00:50:4B:B7:1B:23. If you want you can also change the ip address with setenv ipaddr <whatever ip you want>. Check the rest of the output of printenv to see if you'll need to change anything else as well. Next, the really important command is: saveenv - that will unprotect the CuBox flash, write the relevant key value pairs and then reprotect the flash.

The result of the above should be that openSUSE will now recognise the MAC address of the hardware again - meaning that it will be able to setup the network interface automatically at boot time - saving you the bother of needing to reattach the serial cable to do it through YaST.

Have fun!

Dienstag, 4. Dezember 2012

Back to the bad old days for graphics on CuBox

After the good news about openSUSE 12.2 booting and running successfully in headless mode on the CuBox, the next step on the way to the ultimate home premium professional double scoop openSUSE experience on the CuBox is to get the graphics mode working.

Now, I knew from the start that this wasn't going to be easy. There were plenty of posts over on the solid-run forum about graphics not (or barely) working. The current workaround seems to be to use a frightful looking tarball loaded to the gills with Marvell proprietary code and other assorted binary only cruft (well, "loaded to the gills" might be a bit of an exaggeration, but some really important stuff in there is proprietary and the wheels kind of fall off the car if it isn't used).

To get started, I figured I'd have a look to see exactly what the license terms are for the "proprietary code". When I downloaded and unpacked the "big CuBox tarball" (available here) I found that it contained a "packages" directory, which itself contained (surprise!) many packages. I don't claim to know very much about graphics on the CuBox (or on any hardware at all for that matter), but I had seen already on the CuBox wiki that marvell-ipp is considered "proprietary". I figured that that package is as good a place to start as any, so I unpacked the package there (marvell-ipp_0.2.1-0ubuntu1~ppa10.tar.gz), fired off a find . -name "*icense*" and then opened the file ./marvell-ipp/lib/License.txt. It is a relatively bog standard hardware manufacturer license for software for end users - it forbids everything and the kitchen sink. The following section was, however, quite interesting:
2.1.2  Linux/FreeBSD Exception.  Notwithstanding the foregoing terms of Section 2.1.1, SOFTWARE designed exclusively for use on the Linux or FreeBSD operating systems, or other operating systems derived from the source code to these operating systems, may be copied and redistributed, provided that the binary files thereof are not modified in any way (except for unzipping of compressed files).

Now if marvell-ipp is "designed exclusively for use on the Linux ... systems [including systems derived from the source code thereof]", then it looks like permission is granted to copy and redistribute in unmodified form. It could be possible to allow such binaries to be distributed as part of the NonFree project of openSUSE - if such a project exists for the ARM port. All of this would need to be checked on a case-by-case basis though.

I haven't looked at the rest of the packages yet, though. What I really would be interested in, though, would be some kind of diagram or table explaining exactly what we need to redistribute for graphics to work. There is a table over at http://www.solid-run.com/mw/index.php/CuBox_Drivers_rebuild which breaks the components down into "Render", "Decode" and "More" - maybe somebody could make a real table out of it with additional columns to indicate if there already is an openSUSE package for the component - or what other work needs to be done to get one.

After getting to the top of Boot Hill, it looks like a long and winding road to the Graphical Palace, but we'll get there...

Montag, 3. Dezember 2012

openSUSE on CuBox (Day 8)

It works! I might have to swallow these words again later, but for now - it works! The submit request that I submitted to openSUSE:12.2:ARM:Contrib:Cubox was accepted - meaning that at some stage in the hopefully near future, the official openSUSE CuBox image will be updated to the one generated from the updated JeOS-cubox project.

What do I mean when I say it works? Well, obviously, there is no graphic support whatsoever - but you knew that anyway (on the upside, Bill Merriam is looking into this currently). If you generate a raw image from the openSUSE:12.2:ARM:Contrib:Cubox JeOS project (see my fourth post on openSUSE on CuBox to see how) and dd it onto a mini SD card, then it will boot without manual intervention. That doesn't mean you won't need a serial connection - you will, because the first thing you will have to do is use yast2-firstboot to configure the system (language, keyboard, timezone, root password etc). But you won't need workarounds like those described in my second post to get the kernel to boot.

After booting into yast2-firstboot, you configure the system. After the first reboot a different initrd is used than the one on the SD card. There was a bug here (in the uboot-setup.tgz) but that has now been fixed. What this means is that the first reboot now also works and gets you into a working openSUSE 12.2 system.

Once you are in the system, you can install additional software using zypper. For example, I needed the "screen" package - so I searched for it using zypper search screen. Then I installed it with zypper install screen. Worked fine. If you use YaST for system administration, you can install some useful additional modules like yast2-http-server, yast2-samba-server, yast2-runlevel. See what YaST modules are available with zypper search yast*.

If you meet bugs, which I hope you will (so we can fix them), I'm not sure where to report them yet. Probably on the Novell Bugzilla - but if you have a bug and you don't know what to do, I'd suggest you mention it on the #opensuse-arm irc channel on Freenode.

Have fun with openSUSE 12.2 on CuBox!

Freitag, 30. November 2012

Making yast2-ncurses look better when using through screen

In openSUSE on CuBox (Day 5) I posted a screenshot of how yast looks terrible when used in ncurses mode over the serial connection (i.e. when you connect to e.g. the CuBox using screen /dev/ttyUSB0 115200). Here is that screenshot again.
 As you can see, the background is really messed up. Things get much worse if there is any "movement" involved - for example progress bars.

I think I have found a solution - or at least a workaround. Alex Graf got me thinking that the problem is more than likely that yast in ncurses mode just can't deal with the $TERM that is set when coming through the serial connection. I researched this a little more.

When coming over a serial connection
echo $TERM
told me "linux".

When coming over SSH
echo $TERM
told me "xterm"

Now, that probably isn't altogether incorrect. Alex Graf and Juergen Weigert got me thinking that maybe the screen/ncurses combination just didn't support color in "linux" or "xterm" $TERM modes. I tried using TERM=vt100, TERM=vt200 and TERM=vt500 (as well as the color modes TERM=screen256-color, TERM=vt200-color) but that made things worse, in my opinion. What happened was that YaST was displayed in black and white with no highlighting to show which entry was selected. YaST became pretty much impossible to use.

It turned out that there is an informative page on the openSUSE wiki which deals with YaST Tips and Tricks. There I saw the information "The default setting of the YaST ncurses UI is that the init routine detects the terminal type and automatically chooses the appropriate color theme." However, then I saw the hint:

Since openSUSE 10.3 it's possible to set the color theme manually in /etc/sysconfig/yast2. E.g. if you want a black/white YaST set Y2NCURSES_COLOR_THEME to "mono". 
After some playing around and testing I found that, to get YaST working in ncurses mode over the serial connection (without messing up YaST over SSH), the following combination did the job:

Change the line Y2NCURSES_COLOR_THEME in the file /etc/sysconfig/yast2 from:
Y2NCURSES_COLOR_THEME=""
to
Y2NCURSES_COLOR_THEME="linux"
and also change:
TERM=screen; export TERM

For me, I then got an acceptable YaST. This is probably a bit of a hacky workaround, but maybe it could help somebody in the know identify the real problem and fix it properly.

That's all for now folks! Here's a screenshot of YaST in ncurses mode on the CuBox, over the serial connection...




openSUSE on CuBox (Day 7)

I started off today with the status that my CuBox image would boot into yast2-firstboot without manual intervention. After configuring the system in yast2-firstboot, I tried rebooting. On reboot, the boot process did not get past "loading initrd". I was told on the opensuse-arm mailing list that the initrd automatically gets overwritten after yast2-firstboot. Given that it was necessary to change ramdiskaddr from 0x300 to 0x500 to even get to yast2-firstboot, I knew where to look to address the reboot problem - to whatever script was called to rewrite the initrd.

Alex Graf put me on the right track. He pointed out that the uboot-setup.tgz file in the JeOS-cubox package also needs to be updated. The contents of this .tgz are used to rewrite the initrd. When you unpack uboot-setup.tgz,  you get a directory called kiwi-hook. In this directory are two files. I had forgotten to modify the setupUboot.sh file so that the ramdiskaddr there is also update to 0x5000 from 0x3000.

Once I fixed the setupUboot.sh and recreated uboot-setup.tgz, I called the precheckin.sh script (also in the JeOS-cubox package). This script regenerates the JeOS-cubox.kiwi file using the modifications I had made to the Images.kiwi.in file (i.e. changing the console line from ttyS0,115200n8 to ttySO,115200).

After recreating the new image, I dd'd it over to a mini SD card and tried it out. I got past yast2-firstboot and rebooted. This time I got past the "loading initrd" but the this error occurred:

High Capacity: Yes
Capacity: 3965190144
Bus Width: 4-bit
Loading file "/boot.scr" from mmc device 0:1 mmcda1
723 bytes read
## Executing script at 02000000
## Error: "kerneladdr" not defined
## Error: "ramdiskaddr" not defined
Loading file "uImage" from mmc device 0:1 (mmcda1)
3927920 bytes read
Loading file "initrd" from mmc device 0:1 (mmcda1)
undefined instruction
pc : [<9e34e23c>]          lr : [<036352b8>]
sp : 035ff530  ip : 03604478     fp : c6b2fd2b
r10: aad350f6  r9 : d13d13bf     r8 : 035fffcc
r7 : 8d7ea4d5  r6 : b697c9bf     r5 : 45f7c8d6  r4 : 4a59273d
r3 : ffffffff  r2 : 00000001     r1 : 007a1200  r0 : 00000000
Flags: nzcv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

The bootloader will continue looping to that point, until the power cable is pulled. So now it looks as though the new initrd - the one that is automatically created out of the setupUboot.sh in the kiwi-hooks directory (i.e. the contents of uboot-setup.tgz) somehow contains an illegal instruction. The next task is to identify what is going on there - which instruction is illegal.

Stay tuned! We're getting close.

Mittwoch, 28. November 2012

openSUSE on CuBox (Day 6)

It's been a couple of days since my last update but that's not because I was doing nothing. In fact, I've been investing more work than normal in openSUSE on CuBox these last couple of days. At the end of my last update, I had an image which basically worked and booted without manual intervention. I achieved this by modifying the uboot-image-setup script included in the JeOS-cubox package in the openSUSE:12.2:ARM:Contrib:Cubox project.

It turns out that, whereas my modifications lead to a system that boots each time (without manual intervention through uboot), the same modifications are problematic. This is because they depart from the generic structure that all other openSUSE on ARM devices use to boot. This means that we essentially create a kind of proprietary branch and would have to maintain this all by ourselves - without benefiting from all the hard work going on in the rest of the ARM port (well, not automatically benefiting, that is).

Another issue that my modifications created was the situation where the network interface on the CuBox would not be brought up automatically at each boot. What was happening is that the interface eth0 would not be found on reboot because the MAC address changed. The change happened because of the resetenv that I had inserted in the uboot-image-setup file. Because of this, it was necessary to log in to the CuBox over the serial interface in order to configure the "new" interface through (e.g.) YaST. This meant that each time the network interface id would increment by one - e.g. eth0, eth1, eth2. This was also not ideal.

Thus, what was suggested was that I revoke my submit request and try to continue editing the uboot-image-setup script (as well as the corresponding .kiwi file) to try to figure out exactly what change is needed to get the CuBox to boot. Thus far I think I've narrowed it down to the bootargs line. This line gets added to boot/boot.script in the image by the .kiwi file (in the same uppermost directory as the uboot-image-setup file). In the .kiwi file, the bootargs line appears to have ttyS0,115200n8 whereas the bootargs line I was using in uboot-image-setup had ttyS0,115200 only. I don't know what the 115200n8 is for or if it could even have an effect, but I'm going to change it in the .kiwi file to see if that is the place that is causing the trouble.

I'm out of the house today, without a CuBox, so I won't be able to test (well, I'm in the office in Nuremberg, where there are a couple of CuBox so if I get time, I may be able to test one).

Stay tuned! Check out some of the mail threads that have been generated around openSUSE on CuBox over on the opensuse-arm mailing list:

Freitag, 16. November 2012

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.

Savita Halappanavar

It is quite difficult to decide on how to start to address this topic. The bare facts of the matter are, that an Indian national in the seventeeth week of pregnancy was brought to a hospital in Galway (Ireland) as she was suffering intense pain. Upon examination it was discovered that the foetus was no longer viable and that a severe risk to the life of the woman had been brought about. I think that it is relatively safe to state that those facts are undisputed, though I learned of them through hearsay only.

It is at this stage that the reports of what happened begin to differ and it becomes evident that there are various tales being told. Apparently, reasonable medical opinion would advise that an immediate termination of the pregnancy be brought about to mitigate the danger to the life of the woman. However, the husband of the woman was (apparently) told that such a termination was not possible in the Republic of Ireland because "[the Republic of Ireland is] a catholic country" and that as long as a foetal heartbeat could be detected, a termination would not be (legally) possible.

The sad facts of the matter are that the woman died thereafter. I believe it is undisputed that a timely termination would have saved her life. The story attracted huge attention in Ireland and was also reported in Germany. In India, there were also various newspaper reports. Almost invariably, the reaction appeared to be that the unfortunate woman died because Ireland's legal system protected the right of her unborn child to a higher degree than it protected her right to life.

Without getting involved in relatively futile quasi religious debate on whether the termination of pregnancy is morally acceptable or not, I think it is useful to look at the actual legal background behind abortion in Ireland.

The Irish Constitution was approved by referendum in 1937. Historians agree that the catholic church (which was by far the strongest religious body in Ireland back then and still remains dominant today) - in particular Archbishop McQuaid (he  later became Archbishop, that is) exerted considerable influence on the drafters. In fact, while protecting freedom of religion and prohibiting an established church, the 1937 constitution did (in Art 44.1.2) "[recognise] the special position of the Holy Catholic Apostolic and Roman Church as the guardian of the Faith professed by the great majority of the citizens". This reference was only removed in the Fifth Amendment in 1972. At the time the consitution was approved by referendum, abortion was officially illegal according to Section 57 of the Offences Against the Person Act from 1861. No provision of the original constitution specifically addressed abortion. The Eighth Amendment to the constitution in 1983 introduced a new clause into the Fundamental Rights section - Article 40.3.3 which stated: "The State acknowledges the right to life of the unborn and, with due regard to the equal right to life of the mother, guarantees in its laws to respect, and, as far as practicable, by its laws to defend and vindicate that right." This clause served to make it impossible for the legislature to create a law in the future that would legalise abortion.

As can be seen from the text of the Eighth Amendment, however, that amendment did not per se completely outlaw abortion - what it did do was put the right to life of the unborn child on par with the right to life of the mother - meaning that it was at least perceivable that the legislature could still pass a law which allowed abortion when there was a danger to the life of the mother.

In 1992 the Supreme Court (the most superior court in Ireland which is ultimately responsible for interpreting the constitution - akin the Supreme Court of the United States) decided the Attorney General vs X case. This was a case where a 14 year old girl was raped and as a result of this was pregnant. The girl and her parents wished to travel to England to terminate the pregnancy (in fact, they had already arrived in England). The Attorney General applied for (and was granted, in the High Court) an interlocutory injunction to prohibit the girl from travelling outside the country for the purpose of terminating the pregnancy. The girl appealed to the Supreme Court.

The Supreme Court overturned the interlocutory injunction, ruling that the real test to be applied should be:

"if it is established as a matter of probability that there is a real and substantial risk to the life, as distinct from the health, of the mother, which can only be avoided by the termination of her pregnancy, such termination is permissible, having regard to the true interpretation of Article 40,s.3, sub-s. 3 of the Constitution"

(see paragraph 37 http://www.bailii.org/ie/cases/IESC/1992/1.html - this was delivered by Chief Justice Finlay but see also Justice Egan's commentary at paragraph 183).

Thus, after Attorney General vs X it seemed as though it would not be unconstitutional for the legislature to enact a law which allowed termination of pregnancy if it could be established "as a matter of probability that there is a real and substantial risk to the life, as distinct from the health ... of the mother".

In the wake of the death of the woman in the hospital in Galway, much of the outrage seems to be aimed at a perceived prohibition of abortion in Ireland. As can be seen from the Supreme Court decision, however, in the case of the woman in Galway, it would have been perfectly legal to terminate the pregnancy had the irish legislature enacted a law since the X case (1992) to create the exception to allow an abortion where there is a real and substantial danger to the life of the mother.

The real scandal here is, that successive governments did absolutely nothing to enact such legislation. In fact, just a couple of months ago the United Left (a relatively new political group in the parliament) introduced a bill which would have at least brought about a parliamentary debate on legislating for the X Case. It did not even receive enough votes for that! You can read one side of those developments here: http://www.claredaly.ie/labour-and-fine-gael-bear-responsibility-for-death-of-woman-who-was-denied-abortion/

In summary, it was successive irish governments' failure to enact legislation that brought about the situation where the doctor(s) in the Galway hospital departed from what reasonable medical practitioners would have done - to terminate the pregnancy to save the woman's life (that last sentence is opinion only - I do not know the full facts necessary).


Mittwoch, 14. November 2012

openSUSE on CuBox (Day 4)

I left off yesterday wondering how difficult it would be to start building openSUSE images for the CuBox. After searching a bit I found that the KIWI tool seems to be the right one for the job - and indeed it is the tool that is used in the openSUSE Build Service to get this kind of job done on a huge scale. So far, so good. I read through the instructions over on http://en.opensuse.org/SDB:KIWI_Cookbook_Start_Cooking to see what the basic steps for cooking up a raw image are.

First off, I needed the actual content of the image - i.e. the kernel and root filesystem. Conveniently, the openSUSE ARM contributors have already got one cooked up that they "made earlier". To get in on my development machine (my laptop), all I needed to do was (I already had the osc tool installed):

osc bco openSUSE:12.2:ARM:Contrib:Cubox JeOS-cubox

That left me with the project fully checked out on my local disk. I started fooling around with kiwi, trying to configure, prepare and build an image for CuBox - a complete waste of time. It turns out that the Build Service has this covered already. No need for messing around with local kiwi builds. To get a raw image for CuBox all I had to do was:

osc build images armv7l JeOS-cubox.kiwi

Make sure qemu-linux-user is installed beforehand though - actually, you'd be well advised to follow all the (brief) instructions about getting started with ARM development for openSUSE  over at http://en.opensuse.org/openSUSE:ARM_distribution_howto in order to get your development machine ready.

I didn't go making changes to the image yet - I just wanted to see how easy or difficult it is to create an image by myself.

In summary, building images for CuBox is child's play - the openSUSE ARM people have already done the grunt work and the Build Service takes all the sweat and cursing out of the actual cooking.

Next, time for some real work - debugging the booting of the CuBox to find out why manual intervention is needed during UBoot, to get the kernel to boot.

Dienstag, 13. November 2012

openSUSE on CuBox (Day 3)

My CuBox uses very very little power, which makes it ideal for my use as a NAS server. So it sits here on my desk 24/7 and is "always on". That's why I started today pretty much where I left off yesterday - with openSUSE 12.2 running on the CuBox, but pretty much unconfigured.

YaST works quite well on the CuBox. It didn't have all the modules installed that I typically need, but all modules are available for installation and are only a quick zypper install yast2-<module> away. Here's a video I recorded for example's sake - I use the YaST samba client module to change the group membership.


Other than that, I didn't get around to doing much with the CuBox today. I still haven't found any serious bugs that stop me from using openSUSE 12.2 as a production NAS. My samba setup is back up and running and the CuBox is successfully exporting the contents of my NTFS formatted external USB drive (note, you'll need the ntfs-3g package in order to do this - luckily this is also just a zypper in away).

I'm now looking into (re)building the openSUSE image for CuBox using kiwi and the Build Service. I'd like to make the boot process work out of the box, so the workarounds described yesterday aren't needed anymore. On the other hand, if this image is as stable as the debian image I had deployed since last year, I may not need to boot again...

Montag, 12. November 2012

openSUSE on CuBox (Day 2)

I blogged a couple of days ago about how there is an openSUSE 12.2 image for the CuBox and how I wasn't getting past the line that stated something like "loading kernel". Well, after some time on the #opensuse-arm channel and some help from mmeister there, the CuBox has now really lifted off on openSUSE.

So, what is needed to get the CuBox up and running on openSUSE? Here's the juicy stuff (first connect up your serial connection with screen /dev/ttyUSB0 115200 and hit any key on startup to stop autoboot and to get into the uboot command prompt).

setenv kerneladdr 0x2000000
setenv ramdiskaddr 0x3000000
mmcinfo
ext2load mmc 0:1 $kerneladdr boot/linux.vmx
ext2load mmc 0:1 $ramdiskaddr boot/initrd.uboot
setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p2"bootm $kerneladdr $ramdiskaddr

That should work for you and you should now be looking at openSUSE booting. There are a couple of interesting points to observe though - probably issues that need attention:

1. ext2load mmc 0:1 $kerneladdr boot/linux.vmx takes a long time
2. ext2load mmc 0:1 $ramdiskaddr boot/initrd.uboot takes ages (a minute)
3. once past that, booting itself takes a long time too

Other than that, the first thing that happens after booting is that you get landed into YaST - a very ugly YaST as the colours don't seem to work properly through screen. You get to choose your keyboard layout and language (works), your timezone (works) and you get to set up the root password and configure a local user (works).

As DHCP was automatically set up, you can check your ip address with ifconfig and try to log in through SSH - this is way more comfortable than messing about through the serial console.

So, the next things that need to be done (IMO) are:

1. see can we get a working boot.scr (i.e. so the above workaround isn't needed)
2. check to see if memory is being reserved for graphics (if so, stop this)
3. see if we can sort out the missing update repo

Freitag, 9. November 2012

openSUSE 12.2 on CuBox (Day 1)

On November 6th (2012) Jos announced openSUSE 12.2 for ARM. Devices like the BeagleBoard and PandaBoard are "officially" supported. Some other boards, including the CuBox are supported as "best efforts".

To get started, I had a look at the Wiki pages over on the Solid Run site. I noticed that there were entries for Fedora, Ubuntu and Gentoo etc under "Linux Distributions", but no entry for openSUSE (except that the wiki pointed out that Solid Run donated hardware to openSUSE - which they did). I figured that I might as well get a wiki page for openSUSE started. I copied the basic download and installation information from http://en.opensuse.org/HCL:CuBox and added some more information on how to get started as an openSUSE ARM developer/packager.

My own CuBox has been in action as a NAS server for almost a year now. Up until tonight, it was running on Debian. I never had a single issue with it - it ran the bones of twelve months without crashing once. An occasional apt-get update and apt-get upgrade kept it up to date and never caused grief. Thus, it was with a certain degree of apprehension that I decided to give openSUSE a spin.

To get a linux distribution "installed" on a CuBox all you really need to do (for a supported distribution) is to copy the distribution image to a micro SD card, stick the card in the CuBox and reboot - preferably watching the whole process on a connected serial console - using e.g. screen /dev/ttyUSB0 115200.

I first downloaded the appropriate openSUSE image (see http://en.opensuse.org/HCL:CuBox) and extracted it and dd'd it to the SD card as instructed. I stuck the SD card in the CuBox and started tracking the goings on of the bootloader through screen. I noticed pretty much immediately that not all was well in openSUSE land on CuBox. There were a series of nasty looking error messages, but it did look as though the bootloader finally found the linux kernel image, decompressed it and tried to boot from there. That's where nothing else worked. It is currently hanging at the "booting linux" statement.

Out of interest, I flashed my backup debian image to a different SD card and booted up on the CuBox. It booted as expected and got me into a root shell within seconds.

Thus, I anticipate a deal of debugging of the openSUSE image over the next couple of nights. Of the error message I did see, the ones relating to "kerneladdr" not defined and "ramdiskaddr" not defined seemed most serious.

You can have a look at the boot process here: http://pastebin.com/hHxiZJ5C

Montag, 2. Januar 2012

Electronics 2012

Gadgets I'm interested in at the moment
Going into 2012 there are a couple of electrical gadgets that I've got my eye on, for one reason or another. Here they are:


Raspberry Pi
These are little boards from the Raspberry Pi Foundation - a UK based non-profit. There are going to be two boards. The simple one will cost about $25 and the more expensive one will be $35. That will probably actually be in Euros by the time these things get into production. The simple board is missing e.g. network. The more expensive $35 board is quite interesting. It has HDMI, 10/100 network (it's a real pity that it doesn't have Gigabit Ethernet) and USB. There's an ARM (6 I think) running on the platform. It also has plenty of GPIO pins. At $35 it's definitely worth having.

CuBox
Now here's a box worth having, if it ever materialises. According to the website it has:
  • Linux based distributions like Ubuntu, Debian and others
  • Android
  • 800 MHz dual issue ARM PJ4 processor, VFPv3, wmmx SIMD and 512KB L2 cache.
  • 1080p Video Decode Engine
  • OpenGL|ES 2.0 graphic engine
  • HDMI 1080p Output (with CEC function)
  • 1GByte DDR3 at 800MHz
  • Gigabit Ethernet, SPDIF (optical audio), eSata 3Gbps, 2xUSB 2.0, micro-SD, micro-USB (console)
  • Standard Infra-red receiver for 38KHz based IR controllers.
  • No JTAG required. Unbrickable for Developers (**)
That's quite an impressive list. The fact that it can do hardware decoding, has Gigabit Ethernet, eSATA and HDMI means that this little guy looks like the ultimate mediabox. It can run XBMC but IMHO that could be a bit of a waste. At a bit under €100 I'd expect more than just XBMC from it. The good news is that it looks like the openSUSE ARM effort is now advanced enough that it might be possible to run openSUSE on the CuBox. Time will tell. The thing has to actually ship first.