Cristian's kernel makes openvpn and other stuff work

While using the kernel I compiled (to get support for graphics working) I discovered that openvpn would not work. /var/log/messages spat out this error:

Cannot open TUN/TAP dev /dev/net/tun: No such file or directory
(errno=2) 

When I checked with "modprobe tun" I saw that is wasn't loaded. Apparently, the kernel was built without TUN support. A post on the opensuse-arm@opensuse.org mailing list helped - Cristian advised to try out his kernel (which you can download here).

I installed the new kernel (3.7.7) with zypper up - that worked flawlessly. One reboot later and openvpn was working. Some of the other things that Cristian has got working are:
- systemd should work completely fine.
- webcams, USB digital TV adapters, assorted USB devices



Cristian is still doing work on the kernel and will push the changes as soon as he's ready.

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...

 

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! 

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!

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...