I added the Theora support back to ogg-support and uploaded the source packages to extras-devel builder.

I didn’t change the mimetypes though, so all *.ogg files are seen as audio files even though they may contain video streams as well. I quickly transcoded the Big Buck Bunny video to lower resolution ogg containing Theora video and vorbis audio. The Media Player was able to show it although I should have used even lower resolution (and lower audio bitrate).

Comments are welcome.

Thanks to Movial Kilikali got a modern UI and looks quite nice now:

Kilikali development has moved to a GIT tree (branch generic-2) hosted by linux.onarm.com.

Although the UI got improved and the playback on n8×0 got fixes there are still some bigger task to be done. E.g. adding single files, adding directories recursively and skipping unknown media types. Integration with Light Media Scanner has also been discussed.

I finally compiled ogg-support for Diablo too. It’s available through the maemo downloads page.

I don’t know why the Chinook version didn’t work in Diablo any more. And I didn’t really want to start debugging why the Maemo’s mime libraries and the closed source Metalayer Crawler don’t want to work with the mimetypes copied from a desktop system. So, now there’s only one mimetype: audio/x-vorbis and no support for speex or theora anymore. On the good side, e.g. File Manager can now start OGGs to Media Player.

New feature is a Control Panel plugin to ignore the OGGs from the Maps application. After installing ogg-support wait several minutes for the Metalayer Crawler to finish and then start the CP plugin. Metalayer Crawler seems to be much much slower if you have the Media Player open while it indexes the files.

ARM (and Movial) has published a new site that provides Open Source components, middleware and utilities used to build a Linux Mobile software stack on ARM.

All components (applications, libraries, etc) are in GIT repositories. The build tool is called Matrix. Matrix clones all components under one directory and compiles them with a single command. With another command you get JFFS2 image although that’s not as simple as it should be.

ARM would like to get all contributions directly to upstream instead of providing large code dumps and states that developers are encouraged to participate in discussion forums and developer community of respective components used on this site. That’s why there are no new mailing lists nor forums available for the platform. There is #matrixhelp (#matrix was taken) on irc.ipv6.oftc.net for Matrix related issues though. Developing the components is convenient if you are familiar with GIT. It’s easy to test if your patch works and send it to the upstream project.

One of the supported hardware platforms is n8×0 which is nice as it’s commonly available. The downside is the closed source nature of it. There are two projects, example-project and Kaze that has n8×0 configured as one target platform. Kaze has XFCE desktop instead of Matchbox desktop that the example-project uses.

Kaze boots but most features need still work. WLAN works without encryption but WEP and WPA encryptions need to be fixed. ALSA works with alsa plugins through the DSP but the closed source DSP tasks need to be copied to the build system. Kaze has normal X.Org instead of Xomap, so there’s no XV extension, only stubs.

There was (again) some discussion on #maemo about gcc options regarding VFP usage so I decided to make a simple test with different gcc options using the Maemo’s cs2005q3.2-glibc2.5-arm toolchain. Nothing new here for people already familiar with the floating point stuff.

In the test I compiled a very simple test code with different -mfpu and -mfloat-abi options, -O2 and -march=armv6 were given in all cases. The asm code is linked in the table. The code is a simple for loop which could be optimized to one round but based on the results it looks like the gcc didn’t do this kind of tricks.

Although you can ask the default options from the gcc I decided to test also without the options. The test was run on n810 and results are in the table below.

Looks like the default for -mfpu is vfp and the default for -mfloat-abi is soft.

There are three different values, one takes some seconds, one takes some tens of seconds and one takes some minutes.

This was expected as there are three different ways to do floating point math. In the slowest one the kernel emulates the fpu after cpu has run into undefined floating point opcode. This is extremely slow as there are a lot of context switches. A faster way to do the floating point math without the hardware is to let the gcc to compile the floating point math to the binary itself (and something in libgcc?). The fastest way is to use the VFP hardware.

I finally got the Bluetooth working with my Gumstix running 2.6.25 and my linux setup. My patches are against two weeks old kernel but hopefully apply to current HEAD too. The patches include my kernel config: gumstix-verdex-bt.config too.

I had to configure the BT hardware using pxaregs and /prog/gpio in my startup scripts (copied from some OE image):


echo -n "Starting 32kHz clock..."
/usr/sbin/pxaregs OSCC_OON 1
while /usr/sbin/pxaregs OSCC_OOK | tail -n 1 | grep -q -v 1;do
echo -n '.'
sleep 1
done
echo "Settled"

echo "AF1 in" > /proc/gpio/GPIO42
echo "AF2 out" > /proc/gpio/GPIO43
echo "AF1 in" > /proc/gpio/GPIO44
echo "AF2 out" > /proc/gpio/GPIO45


I also had to patch my hciattach from bluez-utils 3.29. Those patches are here.

Light Media Scanner now uses libivorbis (Tremor) instead of floating point libvorbis. Ogg-support now depends on newer build of libivorbis that exports the symbols needed by LMS.

There’s now ogg-support-lightmediascanner meta package which depends on lightmediascanner0-ogg for easier installation with the Application Manager.

Unfortunately all other issues with ogg-support still remain.

I wanted try something other than JFFS2 as the rootfs and decided to go with UBIFS. Thanks to GIT’s brilliance I had no trouble pulling the UBIFS kernel patches from their tree to mine.

It seems that the UBIFS hasn’t had many NOR flash users before me and it needed some fixes. Artem Bityutskiy was extremely helpful in fixing the deficiencies and helping me out. After a few debug rounds I now have UBIFS root on my Gumstix.

I created the UBIFS image with the following commands:


sudo mkfs.ubifs --compr=zlib -r /tmp/rootfs -m 1 -e 130944 -c 120 -o ubifs.img
ubinize -o ubi.img -m 1 -p 128KiB -v ubinize.cfg


With this ubinize.cfg:


[ubifs]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=13MiB
vol_type=dynamic
vol_name=rootfs
vol_alignment=1
vol_flags=autoresize


Note that I have reserved 2MiB for the kernel partition.

I had to add one extra parameter to the kernel args to specify what MTD partition I wanted to use:

console=ttyS0,115200n8 root=ubi0:rootfs rootfstype=ubifs reboot=cold,hard ubi.mtd=1


Now my Gumstix boots with simplified kernel to busybox shell in roughly 4.2 seconds (counted from the bootm command in U-Boot).

I had to add a new category after all: gumstix. The embedded word has too broad a meaning.

Updating the kernel wasn’t such a big thing after all, even for a kernel n00b like me. I git cloned the vanilla tree from kernel.org and patched the generic (and one bluetooth) Gumstix patches from OE: arch-config.patch, board-init.patch, header.patch, mach-types-fix.patch, modular-init-bluetooth.patch, tsc2003-config.diff, tsc2003.c, and uImage-in-own-partition.patch. Most of them applied fine, I just had to manually apply simple Makefile patches and change pxa_init_irq call to pxa27x_init_irq.

I don’t know if it really works, but at least it booted:


root@gumstix-custom-verdex:~$ uname -a
Linux gumstix-custom-verdex 2.6.25-rc8-00151-gdc41023 #2 Fri Apr 4 23:43:25 EEST 2008 armv5tel unknown


It’s time to create a new category in my projects blog: embedded.

I got interested in microcontrollers some years ago and wrote something simple for 16F88 with assembler. Then I connected it to an old IPAQ using a serial connection. But the IPAQ isn’t a very good development platform so now I decided to buy a gumstix.

It’s 400Mhz verdex mainboard with 64M RAM and 16M flash. And a bluetooth. The mainboard is the smaller board upside down in the picture. The bigger board is a expansion board including 3x rs232, power plug, a USB mini-B connector and a bunch of GPIO lines.

The bootloader is U-Boot and the Linux distribution is based on OpenEmbedded. U-Boot is nice as I’m somewhat familiar with it but the OE I’m going to replace with something else.

I just booted it up to see how it looks inside:


cat /proc/cpuinfo
Processor : XScale-PXA270 rev 7 (v5l)
BogoMIPS : 415.33
Features : swp half thumb fastmult edsp iwmmxt
CPU implementer : 0x69
CPU architecture: 5TE
CPU variant : 0x0
CPU part : 0x411
CPU revision : 7
Hardware : The Gumstix Platform


Maybe the first thing would be to configure the kernel to support only those features included in my hardware setup.