OMAP3 SGX EGL Drivers Add Wayland Support

Just in case anyone was wondering this is a pretty big deal. Imagination Technologies, whose 3D graphics cores drive most mobile displays, has announced support for the EGL_KHR_Image_Pixmap extensions used by the Wayland display server protocol.

For those who haven't been following, Wayland has gained a lot of momentum as a non-X-based window compositor for Linux-based operating systems. Wayland facilitates client-side rendering, similar to the Quartz compositor used in Mac OS X. It has since been adopted by Meego and Ubuntu as their preferred compositing backend.

The stated goal of Wayland is to provide a user experience where "every frame is perfect". This is a rather necessary and long overdue improvement since traditional Linux desktops based on the aging X11 display server tended to suffer from artifacts such as tearing, visible redrawing, and flickering. However, Wayland retains the capabilities to encapsulate the traditional rootless X server for legacy applications. Wayland rendering targets already exist for popular toolkits such as GTK+ and QT among others.

Check out the video below for a (slightly older) demo.

Today, Wayland support exists for graphics chipsets from Intel, AMD, NVIDIA (nouveau) and SGX (OMAP3) platforms. OMAP4 support probably isn't far off.

I guess it's time to fire up the old BeagleBoard ;-) Incidentally, happy birthday!

The USRP E100

I thought that I would take a moment to plug a product that I think has great potential for anyone working, experimenting, or interested in learning about digital wireless communication - the USRP E100. This device, jointly developed by Ettus Research and OpenSDR, was announced just a few months ago. It's a tightly-integrated embedded Linux solution for research into digital baseband signal processing for wireless systems.

I've worked with previous products from Ettus, like the USRP2, and have had 99% good experiences. The entire USRP product family is supported with GNURadio, which greatly facilitates signal visualization, processing, and software interfacing. The one down-side of using the USRP2 was that the only way to connect with it was by using a Gb ethernet cable (which is not a standard feature on laptop / desktop computers). The Gb ethernet port did not make the USRP2 'networkable' since it was only used for data transfer using raw ethernet packets.

The main differentiator of the E100 is that this device ships with a modular ARM board from GumStix. The stock GumStix board is powered by an OMAP3 (Cortex-A8) chip from Texas Instruments. The modular design makes repairs and upgrades easy (any COM can be used with conformant electrical and mechanical specifications). The OMAP3 has appeared in several mobile phones, but (more importantly) has also been the driving force behind a tidal wave of low-cost and powerful embedded Linux developer boards such as the BeagleBoard and BeagleBoard xM. Texas Instruments really has made a great contribution back to the developer community just by making these developer boards available. The OMAP3 processor is capable of running just about every operating system in existence, ranging from Windows Mobile to Ubuntu or Android (all flavours of Linux, and FreeBSD too). The E100 (probably) ships with Ångström by default. As for interfacing, the E100 even exposes HDMI, ethernet, and USB ports so this SDR box can literally be it's own work-station. I really wish this was available back when I was working on the USRP2!

So - that's great - an SDR device that eliminates the need for an external laptop or desktop computer so the entire system consumes much less power in total.

There's just one more thing...

The way that the OMAP3 interfaces with the radio hardware is super-efficient. The TX and RX buffers are mapped directly in to the OMAP3's MMU. To the layman, this means that the Linux kernel can easily expose the radio as a regular device to userspace using Phil Ballister's driver, which is on its way upstream. Furthermore, users of TI's Code Composer Studio (or developers who choose to use CGT directly) can write DSP firmware for OMAP3's integrated C64x+ DSP. Thus, keen developers can run code on the DSP to control the baseband radio and process baseband signals directly (the way nature intended). Naturally, only one processor on the chip can 'own' the radio buffers at one time (without proper synchronization).

To summarize: the USRP2 E100 is the ideal product for most engineers researching embedded RF systems and digital baseband processing.

PS: Nice work Phil! (he was my co-mentor for GSOC2010). I would love to use the E100 for some of my more recent work with ahumanright.org to engineer a low-cost / low-power satellite modem...

Motorola Q9h

So I wrote Motorola recently to see if they would like to cooperate in my effort to port Linux and Android to the Q9h, and although a couple of engineers on the motodev site seemed enthusiastic, I still haven't heard any kind of definitive reply.

The next logical step was to disassemble a broken Motorola Q9h I found on eBay :) I'm not entirely finished this tear-down yet, because I'm still trying to pry-off a few remaining EMI shields, but its coming along smoothly.

 I'd have to say, that I'm amazed with all of the components that went into this device from various vendors. Of course, there's the TI OMAP2420, a TI power management chip, some Samsung memory, Elpida memory, a Broadcom (I'm guessing bluetooth) transceiver, several FreeScale parts that I haven't yet identified, the SiRF 5000 AGPS receiver, a few random sensors (ambient light, ...), etc.

I'll be specifically looking for a 'companion chip' sort of like the TWL4030, to see what I can get out of the USB pins. I believe that D+ / D- are not fully muxed with UART2, but they are with GPIO 107 / 108, which means I might have to write a small soft-uart driver for the Linux kernel. 

Most of the Linux-OMAP code for the 2420 device is already present upstream in the kernel (mainly written by Nokia engineers), so in terms of the Linux porting effort, it's really just a matter of configuration. There may be a couple of non-standard peripheral devices, but I'm not expecting any major difficulties.

I hope you eagerly await some photos of the internals :) I'll have to take a pause in order to get back to the library and resume studying for my wireless communication exam, but I should be done the teardown in another day or two.

Wish me luck!

Update-20091002: Teardown
Update-20091002: OpenEZX Page