This post is about running Debian GNU/Linux on the Mesada/Flexiview FV-1 “AndroidTV” unit. This post has been a bit delayed, I got very sidetracked with other things this month!

By following these steps, you should be able to use the FV-1 a bit like a normal desktop Linux computer. However, it’s still a long way from my dream goal of running XBMC for Linux.

(Edit 11 March – added a couple more notes about exactly how poor the UI graphics performance is.)

What This Is

A lightly customised installation of Debian Wheezy, set up initially with a minimal “LXDE core.” Kernel is 3.3rc from linux-samsung-soc, plus some minor patches for FV-1 hardware support.

Debian Installation

This configuration has the kernel loaded into the internal flash of the FV-1. However, the root filesystem with Debian is external – on either a USB device or an SD card.

If you want to reverse back to Android after testing Debian, you should be able to perform a normal FV-1 firmware upgrade using their “SDtool” to prepare an SD card.

In theory, it should also be possible to install Debian into the internal flash. However, the m-boot bootloader is quite peculiar so I haven’t tried.

How to install

1) Download an SD card image to flash the kernel – use this one if you to boot Debian from an SD card, and this one to boot Debian from a USB device. The only difference between the two is the kernel commandline in the config, you can see the configs here.

2) Work out what device name your SD card reader in your computer has. It will probably look like /dev/sdX (for USB card readers) or /dev/mmcblkX (for built-in card readers). I’ll be using /dev/sdX for the sample commands here. You can probably work this out by inserting an SD card, waiting for it to mount on the desktop, and then typing “mount” to see what is mounted.

3) Flash your SD card with the kernel upgrade. This will erase any content already on the card.
umount /dev/sdX1
dd if=kernel-boot-usb.img of=/dev/sdX
sync


4) Remove the SD card and insert it into the FV-1. Power on the FV-1. The red light will come on, followed by the green light. After 1 minute or so the green light will start blinking. This means the new kernel has finished flashing. Power off the FV-1 and remove the SD card.

5) Download the rootfs tarball. This is the filesystem that the kernel will boot into.

6) You then unpack the rootfs, to your SD card or USB device. If you only have one SD card, you can reuse the one which you just used for the kernel (although you’ll need to repartition and reformat it.) I suggest formatting as ext3.

7) Once your SD card is ready, unpack the rootfs:

cd /media/[path-to-my-SD-card-mountpoint]
sudo tar zxvf ~/path/to/rootfs.tgz
sync
cd ..
eject [path-to-my-SD-card-mountpoint]


8) Insert the card back to the FV-1, and power on.

9) The FV-1 will boot to a login screen, using the lightdm login manager. Alternatively, if you don’t have a screen then you can connect an ethernet cable – the FV-1 will establish a connection using DHCP and you will be able to ssh into it.

10) The default username is ‘user’ and the password is ‘android’

11) The stock image only has a very basic LXDE GUI desktop (lxde-core.) When you first log in, go to the LXDE menu (bottom-left) and choose Accessories -> LXTerminal.

12) Use “passwd” to change the default password.

13) Optionally, use “sudo adduser (username)” to add a new user then “sudo usermod -aG sudo (username)” to give them sudo. Then reboot and login as your new user, and “sudo deluser user” to remove the initial user.

14) If you’re not in the US, edit /etc/apt/sources.list and change to a local mirror for packages.

15) To install a full GUI LXDE environment, run “sudo apt-get update” then “sudo apt-get install lxde”. It may also be possible to remove lxde-core and install other desktop environments like Xfce4, GNOME, KDE – as described in the Debian documentation.

16) When installing LXDE (or any other environment), the gdm3 package may prompt you to choose a default login manager. Keep the current “lightdm”. Any new manager will need to be preconfigured to use Xwrapper.sh to launch X (see below.)

17) Happy computing! From now on, everything should behave like a standard Debian Wheezy system.

Keep reading for the status of the hardware support.

Things That Work

X11 graphics

Up to 1920×1080 over HDMI, 16-bit colour.

USB, ethernet, SD card slot.

Things That Might Work

HDMI audio output

I’m using an HDMI->DVI cable and a computer monitor, so I haven’t been able to test audio output.

Things That Don’t Work

Wifi & Bluetooth

This is another case where having the actual GPL source release would be very helpful. The wl12xx_sdio driver detects the chip correctly, sometimes successfully uploads firmware, and very occasionally I’ve managed to get it to associate and send/receive packets. More commonly it just crashes with MMC read/write errors.

My vague theories for why it is not working include:

• An incorrectly set clock frequency (if I force lower the SDIO frequency it becomes more reliable but not 100% reliable.)
• Samsung HSMMC driver bug of some kind.
• A floating GPIO line that I don’t know about.
• Unpublished differences between Samsung’s SWB-T37 chip and the original TI WL1271.

Changing screen resolution normally

The X server is launched via a custom wrapper script, /usr/local/bin/Xwrapper.sh, that sets the screen resolution for the HDMI output before X starts. Out of the box it is set for 720p (1280×720), but you can edit that file to get 1080p (1920×1080) or 480p (720×480.)

Detecting available screen resolutions

The mainline kernel has no support for DDC/EDID (receiving monitor identification data) over HDMI on the Samsung S5PV210 SoC.

Blanking/unblanking the screen

This includes restarting the X server – any time HDMI output is disabled and then reenabled it hard locks the system. I’ve committed a note on the fv1_hacks branch showing where the system locks the second time around, but I haven’t worked anything else out yet.

To work around the issue there’s also a custom xorg.conf installed, disabling all screen blanking functions.

I think the lockup may be related to the fact that (unlike fancier hardware) the FV-1 has no system-controlled voltage regulators. This means some HDMI subsystems that would otherwise be disabled when HDMI output stops stay running, and cause problems. This is only a theory, though.

Video acceleration

This is the big one. Currently single buffered, software acceleration only – means any graphics-intensive or interactive operations tend to use a lot of CPU time and can be very jerky.

The videobuf2-fb driver that the XServer runs on (ie a framebuffer driver that maps to a V4L2 output device) is only a proof of concept, made by Samsung. It would be possible to add some more features, at least in principle. Or alternatively to write an Xorg driver that outputs directly to v4l2 (this is how Android does it.)

3D acceleration

I’ve been messing with the PowerVR drivers for the SGX540 core, but it’s all a closed-source restricted mess and very unlikely it can be made to work. Hopefully the FSF will get some traction behind their goal of open source PowerVR SGX drivers.

SD card plugging & unplugging

For some reason the Card Detect interrupt doesn’t work on the SD card slot. An SD card will work fine if its inserted at boot time, but not if it’s plugged/unplugged later on. I’ve committed what I think should work to a branch (can even see the CD line changing state and attach the interrupt to it), but I can’t make it actually work.

RF remote control

I spotted data from this coming in over the i2c bus but I haven’t tried to decode it, or work out functions like pairing, or discover if it has its own GPIO interrupt line. There’s a kernel driver for the remote in the vendor’s kernel, but due to GPL violation that’s not of any help.

Restarting

The system won’t reboot, you have to shutdown and then cycle the power by plugging/unplugging the cord!

That’s All

I hope this is of some use. Patches are very welcome if anyone works any of the issues out. :)

I’m calling this a “technical review” because I’m not going to spend much time talking about using Android on this device. The reason for that will become apparent.

I recently purchased two “Android TV” boxes from aliexpress, for investigation and general hackery.

You can buy these from various online vendors (dealextreme, aliexpress, etc.) Also under other names – for instance it’s sold here in Australia as the Kogan Agora TV.

The “original” product is the Flexiview FV-1, made by Mesada Technology, Shenzhen.

High-Level Specifications

• Cortex-A8 1Ghz CPU (Samsung S5PV210 SoC)
• 512Mb RAM
• Hardware supports 1080p video decoding, 2d/3d acceleration
• HDMI output
• Wifi, bluetooth, ethernet connectivity
• 3 USB 2.0 ports
• RF remote with wiimote-like infared pointing feature

Price varies between $130 & $150 online.

Bear in mind that like most of these “shanzhai-esque” products, what’s advertised on the web page may be different to what you get. There are a few similar-looking products out there – I’ve seen ones with SoCs from Rockchip and Amlogic. Also, specs and build quality can vary widely depending on vendor.

First Impressions

The hardware is cheap & cheerful. The marks and scratches visible in the photos weren’t me, it was like that out of the box. Nevertheless, things mostly work and the build quality seems OK. One thing I did notice is that the video output can be a bit picky on the stock firmware – only some of my monitors worked, and I saw reports of some TVs not working. I think the requirement may possibly be supporting a 720p YPbPr video mode.

The other cheap and nasty bit is the little plastic “door” on the front covering 2 USB ports. It’s hard to open and close, and I doubt any serious user would leave it there for long.

Android TV?

Three word review of the “Android TV” experience: “really, don’t bother.”

If you’ve never heard of “Android TV”, that’s because it doesn’t really exist. There is a thing called “Google TV”, but those products are relatively rare and closed-source and not available for $130.

“Android TV” really means “the plain vanilla phone operating system, with a remote control that emulates a mouse & keyboard which you then use to control an interface designed for touch-screens.”

Sound nearly unusable? It is. A touchscreen interface is not a PC, which is in turn not a remote control interface. It’s horrid.

The device works pretty well with a wireless keyboard and/or mouse. Which is fine, but you’d be just as well off buying a tablet with an HDMI port (for less money) or even just hooking up an old PC.

I didn’t use Android much – I can confirm the browser works quite nicely. However, looking around the internet I saw a lot of reports of patchy video playback. Which is disappointing.

Firmware Updates

As usual for these devices, the vendor offers no after-sales support. Firmware updates are scattered around the net in strange places (others are hidden in various giant forum threads!)

So why did you buy two?

I bought these because I have a weakness for cheap low-power ARM hardware. I wanted to see how easy it was to port GNU/Linux, and maybe have a stab at porting XBMC. I’ll put details about running GNU/Linux in a follow-up blog post.

Of course, to get hacking, you need to open the cover:

Here’s the board. The sloppily attached cable is the serial console. Thanks to eDIY NZ for posting the serial cable pinout online – it’s a 3.3v lvTTL port, 115200bps. Looking top-to-bottom in this photo the pinout is 3.3v/TX/RX/GND. The hot glue was originally for strain relief!

For a serial link, I used my favourite source – a mobile phone USB<->Serial cable that I got for $2 at an op shop¹.

Also note the unpopulated USB port, some unpopulated front & rear connectors, and the button cell battery. The battery surprised me, I wonder why they didn’t drop it to save on BoM (bill-of-materials) cost.

The large clear LEDs at the front are the IR LED beacon for the “wiimote-style” remote. The red LED is for power (amusingly, HDMI standby power can come from the monitor and light it even when the unit is off!) The green LED is connected to a GPIO.

Under the covers

Pry off the RF shielding and things are a bit more interesting. “Open in New Tab” on the images if you want to be able to read chip names.

Left hand area contains:
* Power regulation.

Middle area contains:
* Asix AX88772A USB to 10/100 Ethernet adapter
* RAM
* System-On-A-Chip (Samsung S5PV210)
* Sandisk flash memory. I believe this is an “embedded MMC” interface – it shows up as an SD card to the kernel.

Right area contains:
* TI WL1271 combined Wifi & Bluetooth adapter, packaged by Samsung as the SWB-T37 and connected via SDIO.

On the underside, the most interesting thing is the Nordic Semiconductor nRF24LE1 2.4Ghz digital transceiver under the left-hand shield. This is connected via SPI and talks to a similar model IC in the remote control. I haven’t looked at the protocol yet.

Under the main cover, it looks like there is an unpopulated LCD interface. Plus something else totally unpopulated on the bottom left. Given that Mesada also make many GPS devices, maybe there is a car GPS that uses this board?

PCB identifier for this batch is 9000J-MSD-SACC-PCB-110107. Which I guess makes it just over one year old!

GPL? What’s a GPL?

As I’ve written before, GPL compliance for these kinds of products is generally poor. The FV-1 is no exception, as far as I know it is impossible to get source for the exact Linux kernel running on the device.

It is possible that distributors outside China, like Kogan here in Australia or “Flexiview NZ”, are able to supply GPL source code – they have more reasons to act ethically and not break the license, and potentially severe consequences if they are distributing a violating product. I don’t have any more information either way.

In the meantime, I bought this device anyhow because Samsung are generally proactive with open source development, and S5PV210 SoC support is part of the mainline Linux kernel. In practice, it was much more work than I anticipated to get a kernel building from source that runs on the device.

This is partially because of differences between the FV-1 and any available reference board. Partially because not all S5PV210 support has made it to the official linux-samsung-soc kernel. Partially because embedded development is always a bit of a pain…

Vendor Kernel on Device

The device comes with a 2.6.32 Android kernel loaded. Here’s a dump of the boot messages and dmesg, plus some interactions from the Android side – /proc entries, mount points, etc.

Among the custom additions in this kernel are:
* The TI vendor WL1271 driver (open source, but different to the Linux kernel one)
* The PowerVR SGX540 3D accelerator drivers
* In-kernel driver (it seems) for the RF remote, via SPI.

Also of note is that Android isn’t using a Framebuffer device for the HDMI output (the framebuffer in that kernel is for the LCD only.) Android must be using an earlier revision of the v4l2-based s5p-tv interface.

3.2 Kernel

As I said, it seems like no source exists for the 2.6.32 “vendorkernel” that ships on the device.

I now have a 3.2rc kernel that boots and can run a normal GNU/Linux, with xorg over framebuffer, available here on github. Not everything works yet, though. Some of the fixes are a bit hacky and need to be cleaned up. Hopefully, soon some of the support can go upstream to the mainline kernel. More on this kernel in a follow-up post.

Other Reference Kernels

After much searching, I found two other helpful S5PV210/S5PC110 kernel sources (not that I ever successfully booted them on the FV-1.)

The Samsung Galaxy GT-I9000 source code, available from opensource.samsung.com, is for very similar hardware.

A Chinese development board called the RealARM Realv210. This looks to be very similar to Samsung’s SMDKV210 development board. I think the FV-1′s reference board was either the Realv210 or the SMDKV210.

RealARM are distributing a number of useful resources, including a Linux 2.6.32 kernel for the Realv210 board. This reference has been very helpful in getting 3.2 up and running.

Mesada mboot

The last vendor surprise is the bootloader. “Mesada mboot” is the strangest embedded bootloader I’ve ever seen – among its features it appears to be able to both read and format EXT3 filesystems! Unfortunately, mboot is also closed source and no documentation is available.

Here’s a dump of mboot performing a full system update for an Android firmware

The good news is I’ve managed to reverse engineer enough of the format to “unpack” and “repack” mesada’s .osk firmware update files. This allows the flashing of a new kernel, or new system partitions, or even a new bootloader. The project is called mboot-tools and is up on github. There are some usage instructions in the README there, and lots of comments in the header file.

It should also be possible to use mboot_unpack & mboot_pack to make “custom Android ROMs” or possibly even as a first step to porting a newer version of Android (after all the hardware is very similar to Galaxy/Nexus S, which can run ICS.)

What’s Next

I’ll put a post up soon explaining how to boot Debian on the FV-1, explaining what currently works and what doesn’t.

1. “thrift store” [↩]

First Steps

I’m a very recent (3 days) user of scratchbox2 for cross-compiling. My initial response was “this is crazy magic” awe, followed shortly by “this is a crazy mountain of hacks” skepticism. However, after some use & success now, it seems to be a really neat tool.

The best introductions to scratchbox2 that I’ve found are this wiki page from the plugcomputing people, and this nice succinct set of presentation slides from Riku Voipi.

One of the big annoyances has been seeking information, Google likes to replace sb2 (the main scratchbox2 command) with db2 and scratchbox2 with scratchbox.

Multiarch

I have found that scratchbox2 (as of 2.3.3) is a bit fiddly when targeting Debian wheezy or sid (testing or unstable.) This is due to the new Debian Multiarch support.

In a nutshell, multiarch means libraries and tools are moving from locations like /usr/lib to arch-specific locations like /usr/lib/[triplet] where triplet identifies the architecture, ie arm-linux-gnueabi for ARM systems.

The symptoms I saw were linking errors (or configuration failures) due to missing libraries, when you know they are installed on the target. The crucial test is whether “sb2 [some-simple-command]” fails while “sb2 -e [same-simple-command]” passes – this implies that the problem is in the host translation, not in the target (otherwise it would fail in the -e qemu’d environment, as well.)

Here’s what worked for me. In the file ~/.scratchbox2/[TARGETNAME]/gcc.config.lua, I sought out and changed the following two config items as follows, to add linker search paths:

extra_cross_compiler_args="   -L@SBOX_TARGET_ROOT@/usr/lib -L@SBOX_TARGET_ROOT@/usr/lib/arm-linux-gnueabi -L@SBOX_TARGET_ROOT@/lib  -L@SBOX_TARGET_ROOT@/lib/arm-linux-gnueabi",

extra_cross_ld_args="-rpath-link @SBOX_TARGET_ROOT@/usr/lib/arm-linux-gnueabi:@SBOX_TARGET_ROOT@/usr/lib:@SBOX_TARGET_ROOT@/lib:@SBOX_TARGET_ROOT@/lib/arm-linux-gnueabi",

I also ran the command

sb2-config setenv PKG_CONFIG_PATH /usr/lib/pkgconfig/:/usr/lib/arm-linux-gnueabi/pkgconfig/

(In all the above, replace arm-linux-gnueabi with your target architecture’s “triplet” of choice.)

As always, the solutions are simple and easy to follow once you know what they are. :) Please bear in mind also that this may not be the best solution, I’m still a scratchbox2 newbie.

Distro Versions

The other major gotcha, hinted at in the presentation I linked to, is that the host and the target distros must match exactly. If you have different library versions on each then you are headed for problems.

This can be tricky even when the distros match. At time of writing debian wheezy uses libc6-dev 2.13 on amd64 but emdebian wheezy uses libc6-dev-armel-cross 2.11 for the cross-compiler. The header files are different enough to cause builds to fail. To get matching headers I had to change to emdebian sid, which currently has libc6-dev-armel-cross 2.13.

An alternative, also hinted at in the presentation, is to set up a “tools” distro. This is a directory with a complete host-arch distribution, matching perfectly the target’s distro except for the architecture. It seems the idea there is to create a controlled single-purpose environment, instead of just sharing the host’s tools. Maybe that’s a cleaner path, especially if it lets you sandbox a stable distro release with predictable versions.

(Extended Rant, Feel Free to Ignore)

The header-mismatch problem seems to be caused because programs compiled under sb2 can search for headers in both the host directory /usr/include/, and also in the cross-compiler directory (ie /usr/arm-linux-gnueabi/include/), -and- in the target rootfs directory.

Exactly which header file gets chosen for which purpose seems to be somewhat haphazard – in the example I saw, a #include <fcntl.h> was pulling in /usr/include/fcntl.h which was then pulling /usr/arm-linux-gnueabi/include/bits/stat.h.

I haven’t dug deep enough into sb2 to see what’s really going on here with gcc include paths, but it seems like it should be possible to workaround this and ignore the host’s headers entirely – in favour of the cross-compiler headers & those installed in the target rootfs.

However, passing these paths explicitly is exactly the kind of drudgery that sb2 tries to avoid with its “magic”, so at this stage I’m leaving it – my program compiles & links, so that’s good enough for now. If I end up having to explicitly set everything then I may as well create a conventional cross-compiler environment.

Today I Learned how to minimise latency when sending data to a computer from an Arduino (or any other FTDI-based device.) I learned it specifically for Windows, Linux and OS X.

Well, actually I learned this a few weeks ago while developing the Hairless MIDI<->Serial Bridge. But the blog post had to wait until today.

The Problems

• By default, serial latency with FTDI chips (including Arduino Duemilanove/Mega) on Windows & Linux can be quite high (>16ms) and unpredictable.
• In audio applications (like sending MIDI data), this can add enough latency to create audible artifacts.
• In Java-based applications that use it, librxtx introduces an additional 20ms of latency. I wasn’t using Java or librxtx, but you’ll want to read that if you are.

The good news is that you can reduce FTDI latency substantially with a simple tweak.

What’s Latency?

In this case, latency is the amount of time between when some data gets sent from one side (the Arduino), and received on the other side (the computer.)

In lots of cases latency doesn’t matter, or you accept higher latency in exchange for higher throughput. However, for real-time applications like MIDI controllers, you don’t want a noticeable delay between pressing a button and hearing the sound that it makes.

The consensus seems to be that for acceptable MIDI audio responses, you need to keep MIDI message latency under about 20ms.

FTDI Latency Timer

The problem stems from the Arduino’s “Serial to USB converter” chip, the FTDI FT232R. The FTDI can’t send a USB packet to the computer for every byte that comes from the Arduino’s microcontroller. Instead, it stores the serial data in an internal buffer and only sends a USB packet when the buffer is full, or after a period of time has elapsed. This period of time is determined by the FTDI Latency Timer, which is the reason why FTDI chips can give bad latency characteristics.

On Linux & Windows, the default latency timer setting is 16ms. For example, say you send a 3 byte MIDI message from your Arduino at 115200bps. As serial data, it takes 0.3ms for the MIDI message to go from the Arduino’s microcontroller to the FTDI chip. However, the FTDI holds the message in its buffer for a further 15.8ms (16ms after the first byte arrived), before the latency timer expires and it sends a USB packet to the computer.

Thankfully, the latency timer can be tweaked. The tweaking method varies between operating systems.

Linux

In proper Linux style, the kernel’s FTDI driver exposes a nice sysfs interface that lets you get and set the latency timer. For example, if your serial port is ttyUSB0:

# cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
16
# echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
# cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
1

… that will lower the timer from 16ms to 1ms (the minimum), to reduce latency.

In my experience, the timer value won’t change immediately on an open serial port. If an application is using it then you’ll need to close and reopen it before the new value takes effect.

If you’re writing code, there is also a Linux-specific serial flag ASYNC_LOW_LATENCY that programmatically sets the latency timer down to 1ms. This is how Hairless MIDI<->Serial Bridge does it. You can see a succinct C code example in this patch I submitted to the ttyMIDI project.

In testing, I found that ASYNC_LOW_LATENCY also only works if you subsequently close the serial port and then reopen it (annoying, because setting the flag requires you have open()ed it already.)

Windows

FTDI’s own driver for Windows has a combo box in the Port Settings dialog that lets you choose the latency timer value. This Instructable has some screen shots showing how to find the setting in the Windows Device Manager control panel.

Programmatically, setting the timer is a bit hackier on Windows but not impossible. The FTDI driver saves the current latency setting for each device in the registry, so you can use Microsoft’s Registry API to write a new value, then reopen the serial port. The registry key is

SYSTEM\CurrentControlSet\Enum\FTDIBUS\-device id-\0000\Device Parameters

There is a code example for this hack in the Hairless MIDI<->Serial source code.

OS X

OS X does things differently. The driver bundle contains a file, /System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist. This XML plist file describes different profiles for the serial port, including different LatencyTimer values, depending on how the FTDI identifies itself on the USB bus. FTDI’s own Technical Note on the subject [PDF] explains how to edit that value to change the latency.

The good news is that on OS X the latency timer defaults to 2ms for any FTDI FT232 that uses the default vendor & device USB IDs (0403:6001). This includes Arduino & clone FTDIs, so there is no real need to change anything.

How Fast?

I ran a test of the tweaked latency timers. The test sketch sends a MIDI note (3 bytes), then waits to see that same note echoed back. It does this many times and calculates the average delay.

With the latency timer set to 1-2ms, the entire round trip averages 18-19ms. This includes at least 1ms spent in the MIDI framework on the computer. So, based on those results, I estimate the one-way latency to be under 10ms. Excellent!

With a 16ms latency timer, the one-way latency would have been 25ms or more.

I don’t know how much of the 10ms latency is now coming from FTDI/USB layer, or from higher layers in the host operating system. It’s good enough for MIDI use, so I stopped investigating!

Which Arduinos?

Arduinos with FTDI chips include the Arduino Duemilanove & Mega, and some clones like the Seeeduino.

The newer Arduino Uno & Mega 2560 have a different AtMegaU8 chip, programmed to behave as a USB/Serial converter. According to tests I’ve seen, these have good latency characteristics.

I just started working on a simple cross-platform desktop application. I’m developing from Linux and hoping to build binaries for Linux, Windows and OS X.

This quick blog post are some notes I took about:

* Developing & building a Qt app for Windows, on Linux with wine.

* Building static Qt libraries for Windows, on Linux with wine, using mingw32.

* Building a standalone static linked Qt executable for Windows, using mingw32.

This information is mostly out there somewhere on the web, but spread among lots of sources (many out of date.) I thought it would help to rewrite my experiences start-to-finish here.

Building Qt apps under wine

This is almost insanely easy. In my case I downloaded Qt Creator 2.21 for Windows & Qt 4.7.3 for mingw32, both directly from nokia. Ran the installers with


wine qt-creator-win-opensource-2.2.1.exe
wine qt-win-opensource-4.7.3-mingw.exe


The Qt installer needs to be pointed at a mingw32 installation. One comes bundled with Qt Creator, so if you’ve used the default install path it will be C:\Qt\qtcreator-2.2.1\mingw\bin\

Kudos to both the Wine team and the Qt developers.

Developing with Qt Creator

If you’re using Qt Creator as an IDE, and happy with dynamic linking (ie distributing DLLs with your application), then you’re pretty much finished. I found I was able to keep the same project open in both Linux & Wine versions of Creator simultaneously (one would prompt to reload when I’d made changes in the other.)

Mostly everything just worked!

EDIT: OK, not quite. Autocomplete seems to lock up Creator in wine for ~20 seconds each time, so it’s not so good for on-the-fly coding.

Only one oddity, on the Wine side I seem to need to “Rebuild” more often that I probably should. Don’t know if that’s a Windows thing, a Qt thing, or a Wine thing.

Command Line Building

The Qt installer for Windows installs a “Qt Command Prompt” program shortcut for Qt command line stuff. This doesn’t work under Wine. All you need to do, however, is to set some environment variables.

Wine inherits environment variables from its parent shell, so in theory you can just set variables (except for PATH) in your Linux shell and it’ll all work just fine. However, you then run the risk of confusing your Linux build environment.

My preferred approach is to use wine’s regedit to set the variables in the registry:

cat > /tmp/qttemp.reg << EOF
[HKEY_CURRENT_USER\Environment]
"PATH"="%PATH%;c:\\windows\\system32;c:\\qt\\qtcreator-2.2.1\\mingw\\bin;C:\\Qt\\4.7.3\\bin"
"QTDIR"="C:\\Qt\\4.7.3"
"QMAKESPEC"="win32-g++"
EOF
regedit /tmp/qttemp.reg
rm /tmp/qttemp.reg

Now commands like "wine qmake myproject.pro" and "wine mingw32-make" should work.

Static Linking

You may want to static link your Windows Qt app for deployment. This, essentially, means you no longer have to distribute ~12Mb of release DLLs (QtCore4.dll, QtGui4.dll, libgcc) with your application (~6Mb if zipped.)

Instead, if static linked, a 600kb application will grow out to around 11Mb itself (4.5Mb zipped), but will run standalone. However, you'd be able to use an Executable Packer like UPX if you wanted to, to get it down under 4Mb.

Think hard if this is all really worth the effort compared to shipping DLLs. The Qt documentation has a good discussion of the pros & cons of static linking, and explains the basic steps to rebuild Qt on Windows to allow static linking.

Note that if static linking the open source edition of Qt, you'll have to make sure you can comply with the terms of the license - either LGPL 2 or GPL 3.

Here are the steps I took under wine, they are a variation of the steps outlined for Windows in the Qt docs.

Environment

First I needed to set the command line build environment variables, as described above.

Separate Tree

I copied my existing Qt Windows tree to a new directory, so I could have side-by-side dynamic & static options (AFAIK this is the only way to have them side-by-side.)

cd ~/.wine/drive_c/Qt
cp -al 4.7.3 4.7.3-static
cd 4.7.3-static


After this, run 'wine regedit' and change the paths to Qt which are set under HKEY_CURRENT_USER\Environment.

If using Qt Creator, you may also need to update the Qt installation listed under Tools -> Options -> Qt4 (if it isn't autodetected from PATH.)

Newer mingw32 version

When built with older versions of mingw32, applications would depend on mingw32.dll. This is a ~10k DLL that contains some functions for thread exception support. It has to be a DLL, cannot be built statically. To deploy your application you would have had these choices:

• Bundle mingw32.dll (a public domain DLL so no licensing issues.)
• Don't use exceptions, and configure/compile everything with -no-exceptions.
• Don't use threads, ie no -mthreads.

However, in the most recent version of mingw32 (gcc 4.5.2) this restriction has been lifted. QT Creator is bundled with the older mingw32, using gcc 4.4.0. So, if you want a fourth option, you can:

1. Download the latest mingw32 installer and run it under wine.
2. Select "C++ compiler" and "MSYS Basic System" when prompted by the installer.
3. Run 'wine regedit' and edit PATH under HKEY_CURRENT_USER\Environment to point to the new mingw\bin directory.
4. If using QT Creator, go to Tools->Options->Toolchains and add a new MinGW entry for that compiler. Then go to Projects -> Build Settings in your project and switch to the new compiler entry.

(NB: for reasons I don't actually comprehend, you may still need mingw32.dll for debug builds. Although this may just be a sign I need to rebuilt my entire Qt oncem ore.)

Configuring Qt for static libraries

Configure as per the documentation. You'll be prompted for license choice, etc.

wine configure.exe -static


Make in parallel

Building Qt with mingw32 is excruciatingly slow. To make things faster, you can force make to use multiple parallel jobs:

MAKE="mingw32-make -j4" wine mingw32-make sub-src


Replace "4" with the number of parallel compilations you'd like to see.

The full build with -j4 on my quad core i5 2.7Ghz machine takes about 75 minutes, including restarting after the errors (see below.)

Cope with errors

Unfortunately, building Qt 4.7.3 in parallel will lead to false errors towards the end - some codec-related plugins do not have their dependencies set quite right. The easiest thing to do is to just restart from here without -j set, the build only has about 10 minutes to run at this point anyhow.

Also, YMMV but one time I had Qt fail to link libbootstrap - claiming missing functions from QLocale. I don't know what this was caused by, seemingly nothing to do with parallel make, but I deleted tools/bootstrap/tmp/obj/release_static/qlocale.o , ran mingw32-make again, and it was fine.

Add static options to project

Finally, once you're done building Qt, you still need to add

QMAKE_LFLAGS += -static -static-libgcc

to your .pro file(s), in order to statically link in libgcc & libstdc++.

Yay Static!

... and Static linking is set up for Windows! Hope it was worth it. ;)

Disadvantages To using Qt with Mingw32 under Wine

Compilation is slow

Apparently this is mostly mingw32's slowness, although building under wine can't be helping. Regardless, it is many times slower than native building on Linux.

Parallel building makes a massive improvement though, with modern multicore CPUs. If you're running with Qt Creator, you can force your whole project to build in parallel by going to Projects -> Build Settings -> expanding the 'Make:' build step and setting Make arguments to -j3 MAKE="mingw32-make -j3" (where 3 is your number of parallel steps.) YMMV on that, though. You may need to better specify dependencies, as described here.

Real Machine

Even with this setup, you still need a "real" Windows machine (or VM) to do final testing. Although this way you can avoid contact with as many Windows subsystems as theoretically possible, and just copy across your built app to test. :)

Possible Alternatives

It looks like it may be possible to install the Microsoft Platform SDK tools under wine and use Qt with the Visual Studio platform, but I haven't tried.

Or, apparently it is possible to install mingw32 as a cross-compilation toolchain. This way the the compiler runs directly on Linux instead of under Wine. I haven't tried this, not sure how it would compare. You certainly wouldn't be able to use that toolchain with QT Creator, I don't think.

Finally, you could use a VM or a real Windows box. I prefer working with wine, though (ideally I'll touch the bare minimum amount of Windows internals that are necessary. ;))

Next up

Cross-compiling Qt apps for OS X (Ref A, ref B.) Just kidding, not that masochistic. I think I'll go and find a real Mac to borrow. ;)

This letter is my plea and suggestion to Wondermedia, although the theme applies to similar tech companies as well.

(If any fluent speaker can translate this into Chinese for me, I’d very much appreciate it!)

Dear Wondermedia Technologies,

Congratulations on your WM8505 system-on-a-chip. In 2005, a “$100 laptop” was a visionary idea, a dream. Now, thanks to your technology, I can buy a netbook for $85, including shipping to my house in Australia. If I was in Shenzhen, who knows how cheap it would be?

That netbook has more power than the $3000 desktop computer that I owned 12 years ago.

However, it’s not all good. Ars Technica recently labelled the $99 Maylong M-150 tablet the “worst gadget ever”. That tablet is built around your WM8505. Noone who reads that review will buy the product. No importer will read that review and decide to wholesale order any WM8505 product. No hardware engineer would choose WM8505 on the basis of that review, either.

It doesn’t have to be that way. Vendors can ship better tablets and netbooks, that get better reviews, at no cost to you. You can sell more units, at no cost to you.

Take a look at the custom firmware on Slatedroid.com. Every one of those people has modded the same proprietary WM8505 build of Android 1.6 to try and make it better. It runs faster and smoother and has more features. They have spent hours of their time trying to make your products better.

Take a look at the rough port I did of Android 2.2 this week. It’s very poor quality, but it doesn’t have to be. It can be better, at no cost to you.

Look at the months of hard work by the talented Alexey Charkov to make a WM8505 Linux kernel that is good enough to be in the official kernel tree. Big players like TI, Marvell, NVidia all pay talented developers to make Linux code that is good enough for inclusion in the official kernel. Alexey is doing the same for you, for free. His work is coming along slowly, but it could be coming faster. You can help him to help you, at no cost.

What resources are the community using, at this moment? At the beginning, barely anything at all, just incomplete leaked data sheets. Then you were kind enough to release most of your Linux kernel source, which has helped greatly.

I’m writing this letter to suggest you release more, for your own benefit. Many big companies provide datasheets, BSPs, SDKs, source code for free. You should do the same with what you already have. With more information and more source code, it would be possible for the community to build many things. If we had the Android 1.6 source code, WMT SDK source code, or current/complete documentation (even in Chinese) then the community would be able to develop Android firmwares with more features and better hardware support, maybe even a 2.2 port that runs well. There is nothing stopping vendors from shipping devices with a community Android build, if it is better. More WM8505 sales, at no cost to you.

More datasheets and documentation will also make Linux kernel development faster and better. How much of your own developers’ time do you save if the mainline Linux kernel has Wondermedia hardware support in it, instead of having to keep patching it in-house? Better quality kernel, less maintenance costs, no cost to you.

The community is indirectly trying to give you a competitive advantage, for free. All you need to do is open up.

Why not open up? One reason, I think, is that you probably charge for this information. Charging for BSPs & SDKs is a revenue stream. I ask you this: How big is that revenue stream? How many more units do you need to sell before it does not matter any more?

Maybe you think that you can’t afford the support costs, or the maintenance overhead. If this is a concern, rest assured that the community does not need much. Even if you just “leak” a torrent file or send the files for someone else to host, the Internet will make sure that they never go away. The community already provides support for each other.

I realise this is not the same as most small hardware companies’ culture. However, there’s no reason why you can’t behave like the big companies on this. This will differentiate you in the marketplace and give you an advantage. The community is standing by, waiting to help make your products great.

These words apply to all similar companies, not just Wondermedia. If someone becomes the first truly open manufacturer of small, affordable, embedded ARM systems then I predict that the developer community will beat a path to their door.

Telstra have issued a PR statement about their GPL compliance. The statement is a promising sign, but I’m afraid it is somewhat misguided.

Update 9/11: Today Netgem have posted a new version of their GPL source, labelled “T-Box”. I’ve also been contacted personally today by a Telstra representative about the T-Hub product. Both things are excellent to see, Telstra do appear to be taking this very seriously. Will post any more developments as they occur.

However, now I know. If you want an answer from a massive multi-billion dollar company like Telstra, you don’t waste your time with customer service. You carefully research and publish a blog post shaming them, then hope that the tech media will pick it up and bring it to their attention.

I’m so glad that’s clarified.

Actually, the follow-up to yesterday’s “Telstra violating GPL in their T-Hub product” post has been awesome. Big thanks to Renai LeMay for noticing and reporting on it via his news site Delimiter this morning, from where it seems to have spread.

The follow up was so awesome that this afternoon Telstra released a PR statement. To my knowledge they haven’t released it publicly, and they didn’t send it to me (*sadface*), so I can only quote from Delimiter:

“We’re currently talking with our T-Hub vendor to work out whether software used in the product is subject to [the] General Public License (GPL),” said the company. “Should we find a lack of compliance, we promise to work with our supplier to correct it.”

This is excellent. I think it’s commendable that Telstra have reacted to this, and I eagerly await news of further progress.

Clearly, I would have rather that they (a) checked well before they launched the product back in April, and (b) had an effective customer service system so I could have gotten this answer when I first tried to contact them privately about it. However, nonetheless, it’s excellent news.

T-Box

Telstra also weighed in on their T-Box, a set-top box & IPTV product which is manufactured by Netgem but branded and sold by Telstra:

“T-Box owners can find licensing information about the open source software incorporated into their device by visiting the settings menu,” Telstra said. “The source code for the open source material is available from our vendor’s website and we believe all GPL code is identified and is available to customers.”

To verify this, I detoured home from work via my local Telstra Shop and took a look at the demo model. Sure enough, you can select Menu -> Settings -> Information -> Licensing & Copyright.

Apologies for my crummy photos:

Here are the two sections that appear relevant to GPL (my transcription):

FFMPEG License LGPL: Detailed licensing information is available at http://www.gnu.org/licenses/gpl.html.

GPL License: libstdc++ (GPL with run-time exception), dhcpd, iptables, pppoe, madwifi, wpa-supplicant, iwtools, busybox, dosfs tools, e2fs tools, insmod, drivers i2c (partially), USB Sigma.
Detailed licensing information is available at

http://www.gnu.org/licenses/gpl.html

I’m not a lawyer, but this doesn’t look like GPL compliance to me.

In order for this section to constitute GPL compliance, I think it would need at least three things:

• Actual source code included with the product, or alternatively
  

  “a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code”

• The full text of the License, as per GPL Sections 1 & 2, rather than a plain URL.
• To be accompanied by “an appropriate copyright notice”. The only copyright notice in this document is “©Netgem”, which conveniently ignores the fact that large parts of the product are, in fact, not copyright by Netgem.

In fact, all three of these errors are listed as common mistakes in GPL-Violations’ excellent Vendor FAQ, which I linked to yesterday.

“available from our vendor’s website”

OK, so nothing indicates yet that the T-Box is technically compliant. Maybe Telstra & Netgem have still made an effort at compliance. Let’s check out the assertion that “source code for the open source material is available from our vendor’s website”.

Update 9/11: Today Netgem have posted a new version of their GPL source, labelled “T-Box”. This is excellent to see.

Netgem does have a GPL download page. Unfortunately, it doesn’t actually mention T-Box anywhere. The product on that page is a “Netgem HD”. Are they the same?

I searched Netgem’s site for T-Box, but all I could find were press releases. I searched Telstra’s web site for Netgem, and all I found was a comment written by a customer suggesting a T-Box is a “Netgem 8000″. Not sure how that relates to the “Netgem HD” source, or even if it is true that the two products are 100% identical.

Adding insult to injury, the latest firmware download on Netgem’s site is v5.1.08 (January 2009), and users are reporting T-Box versions like 5.1.96.9 (03-Aug-2010). As my favourite Vendor FAQ reminds us, “The source code has to be 1:1 corresponding to the executable (object) code actually shipped.”

User Guide

I also looked in the T-Box User Guide, which is available via download from Telstra.

The user guide contains no reference to the “License & Copyright” section that is available in the user interface. It does, however, contain a “Legal Notification” section. This section has completely different text, and no open source mentions. Ironically, it does contain the following passage:

In using your T-Box, you must not violate any intellectual property rights concerning a brand, design, photo, licence, software program, audiovisual work or any other form of intellectual property.
Any violation of these intellectual property rights and, in particular, any act of piracy, will be subject to the penalty applicable within the legislation put in place.

Hmm, yes. OK then.

Conclusions on T-Box

Without physical access to a T-Box it is not possible to say conclusively if it violates GPL. However, I think I can safely say that Telstra’s PR statement is completely misguided if it means to imply that this meager offering constitutes GPL compliance.

From what I have seen, I believe that Telstra and/or Netgem should immediately take the following steps:

• Amend the “License & Copyright” section of the product so it contains GPL compliant text. For examples of how to do this, look at any Android mobile phone and also read the wonderful Vendor FAQ.
• Amend the User Guide “Legal Notice” so it contains the same text as the “License & Copyright” section, removing ambiguity.
• Provide source code under the name “T-Box”, rather than under an obscure OEM name not associated with the product in any way.
• Provide source code that is up to date with the currently released firmware version.

By the way, if anyone from Telstra would like to talk to me about this, my email address is gus at this domain name. Although you already have my name, phone numbers (twice), email address (twice) and home address somewhere in your databases – courtesy of my attempts to contact you via customer service channels.

I’ve been investigating Telstra’s T-Hub “home phone of the future”. The T-Hub is built with open source software, but Telstra do not seem to be honouring any of their legal copyright or licensing obligations.

Update 9 Feb: Telstra have posted information about how to request T-Hub source code. I will post more details when my disc gets here.

Update: A response to Telstra’s PR statement about T-Hub & T-Box.

(For the non-Aussies: Telstra is Australia’s largest telecommunications company, and is part government owned.)

Short Version

I investigated the T-Hub and found it is built on a variety of open source software, including GPL licensed software like Linux and busybox. However, Telstra are not mentioning this anywhere and are not distributing source code, or notices to obtain source code.

By doing this, Telstra are violating the licenses and also robbing the authors of their rightful attribution. They appear to be regarding open source as a free-for-all that they can exploit without giving back even the small amount required legally by the various license terms.

However, I believe that Telstra can easily take steps to comply with these licenses.

Telstra have a range of other Linux-based products, including the T-Box and a soon-to-be-released “T-Tab” Android tablet. To the best of my knowledge the T-Box is not GPL compliant either, which gives me little hope for the upcoming T-Tab.

What is a T-Hub?

T-Hub is Telstra’s “home phone of the future”. It’s essentially a tablet-like device (think Chumby with less functionality) loosely integrated with a cordless land-line telephone. The OEM product is from Sagem, although as far as I know Telstra is the only vendor world-wide.

GPL Software

The GNU General Public License is an open source “copyleft” license. Vendors are encouraged to freely distribute products built with GPL software, provided that they acknowledge the license and also provide access to the source code (modified or not) for the GPL licensed or derived portions.

A while ago I learned that the T-Hub runs Linux, which is subject to GPL.

Attempting to make contact

For over two weeks I’ve been attempting to find someone at Telstra to talk to about this. Despite best efforts (phone calls, emails), I have been unable to contact anyone with the slightest idea what I am talking about, or with the ability (it would seem) to actually find someone who knows what I am talking about.

Best quote so far, when I was transferred to tech support: “Look mate, noone calls up Microsoft and asks for their source code…” Um, sure.

Finding out myself

Frustrated, I bought an “as-new” T-Hub on ebay. First, I scoured the documentation for any mention of the software license(s):

• Manual (downloaded online.) No.
• Quick Start guide (in box.) No.
• Box itself. No.
• Inside device itself, when it first boots. No.

Next, I found the URL where the device downloads its firmware. The current firmware can be downloaded directly here. The file is a JFFS2 filesystem image, which can be mounted via mtdram as described here (EDIT: you can skip the jffs2dump step if you’re on a little-endian machine like a PC.)

By browsing the filesystem of the device, I can see a range of GPL or LGPL licensed software contained within. Here is a (possibly incomplete) list. The following components are GPLv2 licensed:

• Linux kernel v2.6.19.2
• Busybox v1.1.3
• GNU Fdisk v2.12

The device appears to be built around a Freescale i.MX31 SoC, which means that it probably also contains a GPL licensed bootloader (u-boot or RedBoot.) I haven’t taken any steps to verify the bootloader, though.

There are also LGPL licensed libraries:

• GNU C Library
• gstreamer v0.10
• Pango
• Libusb v0.1.4

The following included open source software is not GPL licensed but has a license that requires acknowledgement that it is included in the product. These notices do not appear to be included, either.

• libcurl
• OpenSSL (libcrypto)
• Dropbear
• ImageMagick v6.5.3-7

What should Telstra do?

GPL compliance is not that hard. GPL-Violations provides an excellent (and simple) vendor FAQ explaining a vendor’s obligations under GPL.

Telstra should review their use of open source in all their products, and amend their ways so they are legally compliant.

For the T-Hub, this includes adding GPL and other license and copyright notices to the product documentation, adding offers for source (or actual source code) for the GPL licensed components, and also making sure that “the tools required to compile and install the GPL licensed components” are made available.

Aside from the time this will take, I don’t see how GPL compliance could negatively impact the T-Hub product in any way. In fact, it may even provide a new market by allowing intrepid users to load different software onto the T-Hub. Of course, this is beside the point – the license terms are clear, and by choosing to use these software products Telstra must commit to honouring their license agreements.

Frequent Responses

There are a few kneejerk responses that always seem to appear in these cases, so I’m going to address them in advance:

“The source code wasn’t modified, so there was no need to comply…”

This is a misconception about GPL. The source code doesn’t need to be modified as a prerequisite for compliance.

However, the vendor doesn’t always need to distribute the source themselves. Under GPLv2 clause 3(c), they can simply redistribute an “offer to distribute corresponding source code” that they themselves received from a third party along with the binary code, provided that the vendor did not modify the source themselves.

EDIT 8/11: Glen points out in the comments that clause 3c only applies to non-commercial distribution, so it seems Telstra can’t copy someone else’s notice – they’d need to provide their own offer for source (3b) or put the source code in the box somehow (3a).

“Sagem made the device, not Telstra. They are responsible for compliance.”

It is true that Sagem made the device. However, Telstra are the legal entity who are distributing (ie selling) it. The customer’s relationship is with Telstra, not Sagem. Whatever private arrangement exists between Telstra & Sagem is not our business.

Of course, in practice, it is Sagem who will probably be responsible for providing source code and documentation in order to allow Telstra to comply. At the moment I think there are two possibilities: one is that Sagem provided enough information to ensure their compliance, and Telstra ignored that information. The second is that Sagem did not provide enough information, and are themselves in violation of the license. However, as I said before, this is Telstra’s business with Sagem, not my business or the business of any of Telstra’s customers.

“This is why I don’t trust GPL… blah blah… open source zealots… blah blah…”

This one always baffles me. Via GPL/LGPL a company can get access to a complete world-class operating system with libraries for almost any conceivable use. They get this at no monetary cost, without needing to negotiate any license agreements or pay a cent to anyone. Better yet, all of the software comes under a single license so the legal department only needs to read and understand one or two documents. The company is then welcome, even encouraged, to build end-user software on top of this OS & libraries, bundle it all into their products and sell it at a profit.

The only thing a company is asked to do is acknowledge the open source components, and make source available. That’s the sole cost to a vendor like Telstra, for an entire software ecosystem. I believe the GPL can make no claim on any of Telstra’s original contributions to the T-Hub, such as the custom HTML UI, which are not derivative works of any open source software. None of that source needs to be released, unless Telstra wants to release it. There’s no risk that Telstra will somehow lose any competitive advantage they have in this product, via open source.

Yet it seems to be all too hard. Why is that?

Alternatives to T-Hub

If you want to buy something like a T-Hub (“kitchenputer”), but want a product that respects copyright law, then I recommend checking out Chumby for starters. Chumby Industries are a terrific company when it comes to open source. Internode sell chumbys in Australia (no Chumby One yet, though. :(.)

What am I doing next?

I’m going to notify as many rights-holders as I can find for the software mentioned above, and encourage them to formally contact Telstra.

I’m not sure what I’m going to do personally with my ebay T-Hub. I’m not a Telstra customer, so it’s more or less useless in its current form. So far I haven’t found any way to load custom firmware, without spoofing Telstra’s update web server (although I haven’t taken mine apart to look for a serial console.)

I thought it might make a good Android tablet, but it has a resistive touch screen and it also probably doesn’t have enough physical buttons for a good Android user experience. Plus for the same money I could buy a OMAP3-based Android tablet with a Cortex A8 in it (newer than the ARM11 CPU in the T-Hub.)

So… it’s probably going back on ebay. Unless anyone wants to buy a nearly-new T-Hub? I can’t guarantee the sale will comply with any licenses, though. :D.

These are some quick notes from installing Linux, specifically Ubuntu Netbook Remix 10.10, on the Asus 900AX.

The 900AX is a throwback to the original eee pc 701. Side by side, they look nearly identical – the 900 just has a 9″ screen, different keyboard labels and 2 USB ports (not 3.) There are a few other budget concessions, for example the RAM is apparently soldered directly on the board instead of on a removable DIMM.

This is offset by the fact I picked it up for just $198AU on sale. It boggles my mind that you can walk into a store and buy a fully functioning brand name laptop computer, new with a warranty, for $200.

Installation

First build your USB stick. You can either do it the easy way as described by Ubuntu, or mess around with dd if you’re keen (I went for the easy way.) Once the USB stick is inserted, boot up and press F2 to get to the BIOS menu. With the USB stick inserted, there will be a “Hard Disk Drives” menu (under Boot) which will let you choose the USB stick as your boot device of choice.

For some reason the trackpad didn’t work the first time I booted the installer (it worked on subsequent boots.) Apart from that, the Ubuntu Netbook Remix 10.10 installation went smoothly. Until the system froze when restarting after installation.

The freezing problem persisted, with freezing/lockups on shutdown, restart, suspend or hibernate. The RT3090 wireless was the problem. To fix it, you can install the DKMS kernel module package containing ralink’s proprietary source drivers. I just downloaded the prebuilt DKMS package on that page, I didn’t build it myself (lazy!) Then I blacklisted the OSS ralink modules:

Appending to /etc/modprobe.d/blacklist.conf

# blacklist other Ralink modules in favour of 3090 DKMS mod
blacklist rt2860sta
blacklist rt2870sta
blacklist rt2800pci
blacklist rt2800usb
blacklist rt2x00lib
blacklist rt2x00pci
blacklist rt2x00usb


… fixed! Other than that I’ve only noticed two problems:

• The brightness hotkeys erratically switch between two brightness settings only, bright & dim. I remember this working properly under Windows in the store, so I’m guessing a driver issue.
• The battery gets hot when charging, and the plug pack tip gets extremely hot – I almost burned myself on it after an hour of charging & using! Not sure if that’s a common fault or just mine. EDIT: This seems like it was me not properly inserting the plug. Has been fine since.
• EDIT 2: At one point recently the trackpad totally stopped responding to me. After lots of messing around and wasted effort, I fixed it by shutting down, disconnecting power, removing the battery, and waiting for 30 seconds before powering back up.

Everything else seems to work out of the box so far. Nothing at all like the “bad old days” of Linux hardware support.

If I find anything else useful, I’ll append it here.

There’s been a lot of fragmented discussion about developing kernels for these SoCs, including a big thread of comments on my previous blog post.

So I’ve decided to create a Google Group to act as a mailing list for people interested in Linux kernel development on these devices: http://groups.google.com/group/vt8500-wm8505-linux-kernel.

This is intended for people interested in hacking on the kernel. If you’re interested in just running Linux on VT/WM netbooks, there is bento-linux and their forums. For tablets, there is slatedroid.com. Both are great communities.