N800

ALIP on n8x0

tuomas

ARM and Movial announced a second stable release of ARM Linux Internet Platform (ALIP) generic repository. ALIP got other updates as well, see a blog post about them in Movial’s Sandbox or the actual release notes.

The Kaze project for n8x0 devices was updated to use the generic-2 branch as well. There are no built images provided, but ALIP is relatively easy to compile if one is already familiar with Scratchbox. The ALIP rootfs works with the Maemo kernel and initfs and it can be booted nicely from an MMC/SD card, so no need to destroy the Maemo from the device just to test ALIP.


Kaze on n8x0

ALIP requires newer SB components (and specific toolchains) but the newer SB components should work just fine with Maemo targets and Maemo toolchains. Or the newer SB can be installed in a different directory from tarballs and used concurrently with the Maemo SB.

Follow the From scratch instructions but replace alip-project with kaze-project and don’t pass the -cbeagleboard. You should pass -c multimedia to include 3rd party provided (by me actually) gst-ffmpeg to the build.

If you want to include WebKit engine and Midori UI to it, add “midori” to the components file.

Unfortunately the X driver for OMAPs (xf86-video-omapfb) in the stable branch in omap-repository has a bug concerning n8x0 devices and you should use master branch of it if you want to test video playback. The easiest way to switch using master branch for this component is to clone the n8x0 configuration repository and switch the branch before running the matrix install.


git clone git://linux.onarm.com/git/n8x0/config/n8x0.git
vi n8x0/suite/n8x0-recommended
# Add the branch: Component("xf86-video-omapfb", branch="master")
matrix install -c multimedia

After the install you should include the binary DSP tasks from the device (they are proprietary and cannot be distributed). Use the helper script (get_nokia_binaries.sh) in src/platform-n8x0 that fetches them from the device over ssh and reinstall the component before creating the rootfs image:


matrix install-only -c multimedia platform-n8x0

Lots of things are still broken:

  • Power button tries to suspend, which fails and does nothing.
  • WLAN encryption keys are not stored succesfully.
  • WPA doesn’t work (WEP and unencrypted do work).
  • Midori should be started after networking.
  • There’s no ssh client (but dbclient as it’s dropbear).
  • Power management.
  • Default XFCE theme doesn’t look cool.
  • Etc.

But I believe that with some work Kaze on n8x0 will become decent enough for everyday use and will provide up to date components long after Nokia has dropped the n8x0 support.

If you have any questions, visit #alip @ freenode.

PS. If you want an open source media engine with D-Bus API checkout the Octopus. It’s a work in progress but handles basic audio and video playback on n8x0 just fine :)

Speex encoder on n800’s DSP

tuomas

I’ve been wanting to run things on OMAP‘s DSP processor since the day I tested an OMAP1510 development board some years ago. Finally after a Proof of concept G.711 dsptask mail by Simon Pickering I decided to cut’n’paste that and try.

I knew the Speex had already been ported to the DSP (TMS320C55) used by OMAP1 (770) and OMAP2 (n800) so I started porting it to the DSP Gateway to be able to use it in my n800.

The DSP Gateway’s DSP tasks are seen as /dev/dsptask/<taskname> devices on ARM side and are interacted with read, write, and ioctl calls. Very linux stylish and convenient in my opinion. On the DSP code one struct defines callbacks for these calls. The code overhead on DSP side is some tens of lines.

Speex has speex_alloc functions that can be overwritten if the default memory allocation is not suitable. In the existing DSP port these were overwritten with functions using preallocated global char arrays that are used for all allocations, freeing is not possible. The DSP char is 16 bits as is int. The long is 32 bits and a pointer is 23 bits. Long long is 40 bits. I had some problems with calculating with pointers (casting a pointer to long didn’t produce valid looking value) in the existing implementation so I rewrote the allocation functions to use arrays and indexes. Also the existing implementation printed pointer values as %x which seemed to print completely different values than %p. I did use dbg() however, not fprintf.

The dbg() prints will be shown in dmesg or syslog on the ARM side if the kernel is compiled with mbox debug. The n800 stock kernel is not, but it’s almost trivial to compile a kernel of your own. My kernel with mbox debugs and built-in ext3 is here.

Other than the allocation functions there was not much to port, couple of functions calling the speex’ init and encode functions. I did have an odd problem though: the DSP seemed to jam after some tens of seconds and the DSP kernel was rebooted. After I added poll_disable(task) in my encoding callback function, the jamming was gone. The function will disable the polling for 10 seconds. Afaik, that should be called only if the completion of the function takes more that 10 seconds, which it doesn’t.

My speex patch against the git head is available, if somebody wants to test it. There can be some weirdness as this is my first test with the DSP stuff and I don’t even know how to use the git ;)

If my measurements are correct it takes roughly 40 ms to encode one 20 ms frame without compiler optimizations. With -o3 it takes a bit over 20 ms. The speex is meant to be portable and has a header defining some math functions. The functions are ported to different CPUs like ARMv5 and Blackfin. Maybe some DSP guru quickly ports those to the TMS320C55 too? :)

I think the best place for DSP information for the tablets is in maemo.org wiki as I hope it will be kept up to date with the latest projects and tweaks. One thing to be added there would be a note about the skeleton page. I used the Active Block Receiving and Active Block Sending.

Streaming DVB-T as ogg to N800

tuomas

Transcode DVB-T with VLC on mediaserver (low resolution because of low(?) CPU):


vlc --program=241 dvb: --dvb-frequency=674000000
--dvb-srate=6900000 --dvb-transmission=8
--dvb-guard=8 --dvb-hierarchy=-1
--dvb-bandwidth=8 --sout #transcode{width=128, height=96, vcodec=theora, vb=300, acodec=vorb, ab=96}: std{access=http, mux=ogg, url=example.server.fi:8000}

Watch stream on N800:


gst-launch-0.10 gnomevfssrc location=http://example.server.fi:8000 ! oggdemux name=demuxer ! {queue ! theoradec ! xvimagesink} {demuxer.!queue ! vorbisdec ! audioconvert ! dsppcmsink}

Tested with VLC 0.9.0 and self compiled theora, ogg, vorbis libs. The transcoding parameters are just the ones I got first working :)

EDIT: It seems that I almost reinvented the wheel again. See MoRpHeUz’s blog (especially this) for more details.

N800 and GCC options

tuomas

I was a a bit surprised to hear that Nokia doesn’t compile the Maemo stuff with any ARMv6 specific GCC options. According to someone in IRC the gain is insignificant compared to increased size (and thus booting time) when not using thumb mode.

I decided to test this out and compiled a bunch of packages with -mcpu=arm1136j-s -mfpu=vfp -mfloat-abi=softfp GCC options and without -mthumb.

The performance tests included measuring rootfs booting time, gtk-perf, cairo-perf, encoding and decoding with theora and decoding with vorbis. Memory comsumption was not measured, even though it should have been. None of the tests were made with scientific accurance and there can be errors in the tests, although zuh double checked most of the tests. There aren’t much details here, but I should have them written down, so ask if you have any questions.


thumb

I took some of the gtk, hildon, glib, xlib, etc libraries and binaries that were compiled with -mthumb and compared the sizes. The sizes increased 23% in average, the minimum increase being 8% and the maximum 30%.

Booting time was calculated by measuring the time between setting the clock in /etc/init.d/rcS and running the last init.d script. This is not very accurate since processes are started to background etc. The booting time increased roughly 8% (2 seconds on my MMC).

Encoding with theora was a bit of a surprise. The encoding time with theora compiled with no GCC options and with –disable-float was even slightly faster than with floats and the mentioned ARMv6 GCC options. Decoding with theora seemed to be roughly 5% faster with the new options.

The biggest practical difference in this test came with vorbis decoding. Decoding with ARMv6 options took only 30% of the time when compared to no options.

Gtk-perf doesn’t cover many widgets but hopefully shows the direction of the performance differences. The improvement was around 14%.

Cairo-perf doesn’t give one nice number to for making hasty conclusions, but the improvements varied from 1.05x to 7x, while the average was 1.8x. cairo-perf-diff-files reported over 800 speedups and two slowdowns.

zuh writes about memory comsumption, thumb mode swithing, gtk-perf and cairo-perf in more detail in Movial‘s syslog.

For me the disk space isn’t an issue and I don’t boot the device so often that the two second delay in bootup really matters. So, for me the little speedups are welcome. I can even tolerate the memory loss reported by zuh.