RSS Feed

My random notes about the stuff I've done

Tag Archives: ARM

MeeGo 1.2 ARMv7 chroot (beta)

5 Comments

I’ve always liked the Scratchbox approach to cross-compiling. Run ./configure && make and you have an ARM binary, no need to explicitly tell the configure we are cross-compiling nor fix the bad behaving build scripts.

MeeGo doesn’t provide an SDK for the (ARM) platform. There’s an SDK for building Qt applications and there’s an QEMU for emulating the ARM device environment. For building the lower level components (Qt itself, GStreamer, etc) you are expected to use OBS. OBS is a very good build infrastructure tool, especially as you can link your own OBS to upstream OBS instances like MeeGo or OpenSUSE and have your OBS build only your own components or modified upstream components.

But OBS is a bit overkill when you are developing your own component that you don’t want to be a part of anything bigger yet. The OBS client side tool, osc, allows you to build components locally in a chroot but still you need an OBS account and those aren’t automatically available for everyone, not even in the community OBS.

I took the chroot created by osc build and modified it a bit with the help from stskeeps @ #meego-arm. The produced chroot is capable of building ARMv7 hard-float binaries without OBS or OBS account. It includes a minimal set of dependencies to make it smaller for easy download (it’s still 162MB), and the project specific dependencies can be installed normally with zypper from the standard MeeGo repositories.

The benefit from using a chroot over a QEMU image is the installed speed tools; many of the components taking time during a build are actually x86 binaries. These include e.g. bash, compilers and bzip2. Running these as emulated ARM binaries (or natively on an ARM hardware) would be much much slower.

I’ve used this approach with my own Qt + GStreamer project and it has been working well but that’s only a small use case so there can be all kinds of issues still. I use the same account inside the chroot and outside and bind mount my $HOME to the chroot so I can build project under my $HOME.

Current known issues:

  • Zypper doesn’t find noarch packages (this is an upstream bug, not related to my chroot).
  • Tested only on Debian Squeeze. At some point there was a linker issue on Ubuntu and I don’t know if that still exists.
  • My instructions mention libqt4-devel although the package name is libqt-devel.

If you want to try it out, it’s available via BitTorrent at http://tuomas.kulve.fi/tmp/torrent/ (temporary location). After extracting the tarball, see the readme file in the root directory.

Filed under Maemo, MeeGo
Jul 9, 2011

Pleco Phase01 completed

0 Comments

I started playing with microcontrollers in 2005 and, if not at the very start, at least very quickly I decided to aim to have some sort of remote controlled Linux device with controllable camera with digital wireless communication. Now, 6 years later, I have completed my first phase :)

Couple of photos of the earlier devices are shown in the project page.

After several planning iterations and code rewrites I ended up using Qt both on the remote controlled Gumstix and on the GUI controller. I decided that trying to optimize everything from the memory and CPU consumption to the network bandwidth just isn’t worth the time spent in implementing it. The most CPU intensive task is the video encoding to H263 and that’s done in the DSP. I’m running MeeGo on the Gumstix and it provides e.g. the GStreamer plugins for the DSP.

Using Qt framework with self made simple protocol over UDP I got the Phase01 code implemented quite quickly compared to my previous efforts. The protocol allows low priority packets (like periodic statistics and video stream) to be lost and guarantees the passing of high priority packets (control commands etc.). Also only the latest control command of each type is retransmitted, i.e. an old packet is not retransmitted if a new overriding command has already been given.

The controller GUI shows the states the slave sends, like motor speeds, WLAN signal strength, CPU load average and some protocol statistics like round trip time and the number of retransmissions.

Currently the motors are controlled using the a,s,d,w keys in 10% steps and the camera is controlled dragging the mouse left button pressed on top of the video window.

Here’s a video (direct link) of the Phase01. You need HTML5 video capable browser with Ogg Theora/Vorbis codecs.

Filed under MeeGo, Projects, gumstix
Apr 5, 2011

Learning OpenGL ES 2.0

1 Comment

I got (again) interested on OpenGL ES 2.0 and bought OpenGL® ES 2.0 Programming Guide.

The examples on the book can be downloaded from http://www.opengles-book.com/. Those are meant to be compiled with Microsoft Visual Studio.

I made a small patch that adds initial support for Linux/X11. It doesn’t support texture loading (because I misplaced my png loader somewhere), the WinCreate() is copypaste code I don’t fully understand and the WinLoop() is missing some functionality. But at least the Chapter 1 Hello Triangle compiles and runs in Fremantle on Beagle board :)

Compile and install the libes in a normal autotools manner. Then you can compile the examples by exporting the PKG_CONFIG_PATH and running gcc:


gcc `pkg-config libes --cflags --libs` Hello_Triangle.c -o Hello_Triangle

As usual, patches are welcome :)

Filed under Maemo
Apr 28, 2009

ALIP on n8x0

0 Comments

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 :)

Filed under Maemo
Feb 24, 2009

Linux on ARM

0 Comments

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

Filed under Maemo
Aug 20, 2008

2.6.25 and BT working on Gumstix

0 Comments

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"

/sbin/modprobe gumstix_bluetooth
/sbin/modprobe proc_gpio

echo "AF3 out" > /proc/gpio/GPIO9

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.

Filed under gumstix
May 8, 2008

UBIFS and Gumstix

9 Comments

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

Filed under gumstix
Apr 18, 2008

2.6.25 running on Gumstix

2 Comments

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

Filed under gumstix
Apr 8, 2008

Gumstix

0 Comments

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.

Gumstix Verdex

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.

Filed under gumstix
Apr 3, 2008

Speex encoder on n800′s DSP

0 Comments

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.

Filed under Maemo
Aug 31, 2007

Tags

ARM DSP Embedded Linux Gumstix Harmattan Linux Maemo Measurement MeeGo Microcontroller Multimedia My projects N800 N810 N900 N950 Ogg Open Source sharing

Archives

Meta