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.

Android TV front

Continue reading

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.

Android TV front
Android TV back
Android TV remote

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.

Continue reading

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

Update 25/11: Now supports M003 as well, and it appears the M002 may be able to boot from the M001 build.

Update 27/11: New build posted, now with better functioning Wifi!

Android 2.2 on dirt cheap WM8505 tablets. I said it may not be possible. Since then, I’ve spent hours and hours trying to reverse-engineer the custom calls that the WM8505 Android port uses to set up the correct graphics modes. I still can’t replicate their process successfully.

However, on Sunday I had what my friend Adam has called “an a-ha moment1. Android’s own porting guide says the graphics mode has to be RGB565 with double-buffering (aka page-flipping), but apparently this is not strictly true.

Within a couple of hours, I had a Froyo home screen up on my M001:

Now, a few busy evenings later, I can offer a hacky alpha for people to check out, and hopefully build upon. However, this is not the same as “the Eken M001 now supports Android 2.2“.

Get to the Android already!

OK, here it is. This build is configured to boot entirely from the SD card, to minimise the chances of bricking a tablet and to make it easy for people to check it out. You should be able to run this without any impact on the OS installed in the tablet.

This image is a dodgy hack, pre-release quality, and totally unsupported, btw. Do not expect very much.

Installing from Linux/OS X

If you have a 2Gb+ SD card, you can download the image (M001 or M003) and use ‘dd’ to copy it over the top of your SD card:

zcat image-m001.gz | dd of=/dev/sdX

(where sdX is your SD card device. You’ll need to unmount the SD card, first.)

Installing from Windows

If you’re unfortunate enough to be stuck on Windows, you can download a zip file with the image (M001 or M003). First, unzip the image. Then, the Slatedroid forums have instructions on how to flash the Debian SD card image from Windows. If that doesn’t work, you can try these instructions. The Debian image is the same format as the Froyo image, so the same steps should apply.

Installing the SD Card manually

If you have a smaller SD card, or you just want to make your own, then I also uploaded tarballs containing the FAT and ext2 partitions for each tablet. You can unpack these onto any SD card, with the following partition & formatting scheme:

  1. FAT16 (for script/ directory)
  2. linux-swap (optional)
  3. ext2 (for root filesystem)

(NB: The partitioning scheme has changed since the first set of posted images.)

First boot

The first boot from the SD card will take a few minutes longer than usual, because the Dalvik VM is generating its cache. I think mine takes around 5 minutes the first time.

Status

The following things work:

  • Basic Android UI
  • Touchscreen
  • Blanking the screen when idle
  • Swap partition on SD card

The following things should work, please test:

  • Wifi
  • SetCPU & other CPU scaling (will need to “root” first)

The following things are untested and probably don’t work:

  • Audio
  • Video playback (probably will be choppy)
  • Battery level tracking
  • Automatic screen rotation (I hope you like landscape)

However I expect all those things should be fairly easy to implement, except for smooth video playback.

The following things definitely don’t work:

  • Graphics acceleration, there isn’t even page flipping/double buffering at the moment, let alone OpenGL ES (which there will never be.) It isn’t as painfully slow as I thought it might be, but it definitely isn’t fast. There are also a few artifacts, like lock screen redraw when turning back on. Also, some apps may not work as expected due to the odd graphics mode.
  • Touchscreen calibration. The device ships with my Eken M001 calibration on it. If mine is no good then you can copy your /data/wmt/touchcal to /etc/touchcal on the SD card to bring it across. But there’s no WM8505 calibration app installed, so someone either needs to port Wondermedia’s or write a new one from scratch.
  • Suspend/Resume (was broken in 1.6, still broken in 2.2 as it’s a kernel deficiency.)

Installing to the flash in the tablet

At the moment, this only supports booting from SD card. However, there’s no reason why someone clever couldn’t build an alternate version that installs to the tablet’s internal flash – all the required pieces exist AFAIK.

Building On This

All the scripts & patches I used are available on github. There should be enough there for a savvy person to fairly easily build this again from an AOSP release.

The kernel used is “my” copy of Wondermedia’s kernel source release. Hopefully as Alexey’s from-scratch kernel adds more features, it will eventually be able to run Android as well.

If you do build anything using this, please please please share source/instructions for what you improve. Every “secret” someone hoards away is a step away from making these devices properly usable.

This Froyo build comes unsupported (sorry), and I’m not likely to do a whole lot more on it. However, one thing I do intend to do is get it running on my Eken M003 (my M001 has serious hardware problems so I can’t really use it as a tablet any more.)

However, I really hope that others will jump in, build on it, and make something good. Enjoy!



  1. I called it a doh! moment []

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

Asus at MHV

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

I seem to be getting at least two unsolicited questions a day from people who have inadvertently bricked their Eken M001/M002/M003 or Flytouch/noname tablets . So here’s a quick post with what I know about unbricking.

You should also try slatedroid, and hassle whoever is making custom firmwares to remove the unnecessary bootloader reflash steps. These dangerous reflashes are what is causing so many tablets to brick in the first place.

Also, always plug your tablet in to the charger when flashing. Never unplug it or turn it off while it’s flashing, even if you’re accidentally flashing it twice. Seriously, people.

Bootloaders

WM8505 tablets have a pre-bootloader called W-Load, then a bootloader called u-boot, then the main OS boots.

U-boot will read a custom boot script from a file “script/scriptcmd” on an SD card, if it is present. This is how upgrades and reflashes work. U-boot is also capable of interacting with the user via the built-in 3.3v serial port, if you solder some wires to it.

Stuck on the ‘Android Logo’ boot screen

This is the first screen, which also says “Kernel Version X.Y.Z” and “SDK Version X.Y.Z.”. This screen is put up by u-boot.

If you’re stuck on this screen then u-boot is loading, which is a good sign. If putting in an SD card with an upgrade script does not work, then it may be broken in some other way. You may be able to connect a serial cable and interact directly with u-boot to issue commands.

Before you bother with the serial cable, make very sure you have formatted your SD card correctly (FAT32) . Try reformatting and re-copying all the files to the SD card, and then try using a different SD card. Various people have reported that only SD cards 2Gb or smaller work reliably.

Stuck on the ‘Android’ “shimmer” boot screen

If you’re stuck on the next boot screen (the text ‘Android’ that shimmers back and forth) then Android has started loading but is crashing. Reflash via the SD card.

Blank screen

If you have a totally blank screen then this is a much worse sign. In my experience, I’ve seen three possible things:

If the red power light blinks on when you press Power but then immediately goes out

Then you have a fault in your power circuit on the board. In my Eken, I can still make it boot if I take the back off and heat up the board with a heat gun (hair dryer would also work.)

If the red power light stays on and eventually you hear the ‘ding’ startup sound

(Instead of the ‘ding’, another sign is if you can connect it to your computer via USB.)

Then your Eken is working but your LCD panel is not. It might be broken, or it might be a bad connection. I’ve had luck pressing (lightly) around the edges of the screen.

If the red power light stays on but you don’t eventually hear any ‘ding’ startup sound

Then your Eken is probably stuck either loading W-load or u-boot. There are some anecdotal reports that these boards will still take a normal SD card based update, so try some different firmwares via SD card as a first step.

If that doesn’t work then you probably have a brick. The only way from here would be to reflash directly or via JTAG, and noone has found a JTAG pinout on these boards. You can connect the serial port to be 100% sure, but I wouldn’t hold my breath.

EDIT: Ziann123 has posted a comment about unbricking via JTAG. Apparently he has a newer revision board, where the JTAG pinout is broken out and clearly labelled.

I have none of the above

If you have different symptoms, feel free to post in the comments. You’ll probably get better responses by posting on slatedroid, though.

Have started tidying up a Linux kernel for Eken M001 & similar devices (tablets and netbooks), based on the source release that came from VIA last week.

Very, very, early days yet. http://github.com/projectgus/kernel_wm8505.

Not all of the WM8505 functionality is available in source form yet, in particular VIA have chosen not to give us the video source for some reason. So there’s still quite a lot of work before this will be suitable for an Android 2.1/2.2 port. But it’s a very solid start.

EDIT: Source for all drivers is now available except for the SD/MMC driver. I suggest joining the Google Group if you’re interested in this stuff.

(One more Eken post and I’m going to have to rename this blog to Project M001!)

EDIT: Everything here is somewhat out of date now. Jacob Stoner has released a Debian build with X11 & touchscreen support. The links are all posted on the slatedroid forum.

Debian Boots! I wish I had a keyboard!

Debian on the WM8505 netbooks has been around for a while, thanks to the efforts of #easypc’s abrasive. I needed to tweak a couple of things before his release worked on the Eken M001 tablet.

Before you begin

You probably want to start by plugging in either a USB keyboard or a serial cable. Otherwise, all Debian has to offer you is a blank login console.

Howto

Follow abrasive’s directions in the README here to set up the partitions on your SD card.

Before you boot the SD card, make the following 4 changes:

  1. In the FAT partition you made, replace script/scriptcmd with this scriptcmd file.
  2. Download the Eken official Android 1.6 upgrade from here, unzip it and copy the script/uzImage.bin file (kernel image) over script/uzImage.bin on the FAT partition you made.
  3. In the ext2 partition, edit etc/inittab and replace this line:
    #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
    with this one:
    T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100
  4. Also in the ext2 partition, run sudo mknod (mount-point-of-ext2-part)/dev/ttyS0 c 4 64(or equivalent)

(The last two steps are only strictly necessary if you want to use the serial console, but the first two are necessary all of the time.)

Then pop the card in and you should boot into Debian! The instructions on the bento-linux Wiki for X11 work as well, although I found I needed a window manager (like xfce4) installed before X11 would stay launched.

Default XFCE4 on my M001 tablet

EDIT: If you’re having trouble booting from SD, I just had an experience where uboot was refusing to load ‘scriptcmd’ even though it was correct. I had to reformat the FAT partition and re-copy the files. Not sure what that was about, but might be worth trying if your Debian suddenly refuses to boot.

Notes

The new scriptcmd adds the kernel command line arg “console=ttyS0,115200n8” to the command line. Seems unnecessary, but I couldn’t get it to boot successfully at all without this addition.

If you don’t replace the netbook kernel with the one from Eken, you won’t get any graphics display. Although debian will still run fine through the serial port. I’m guessing the netbook kernel has the LCD buffer at a different address.

Eken boots android with mem=109M on the command line whereas abrasive has used mem=112M. I don’t know if the Android version is allocating extra space for framebuffer double buffering, or something else. I haven’t noticed any differences yet so I’m running with mem=109M.

I haven’t tried the optional scriptcmd.install to install Debian to the internal flash, yet. I’m guessing you may need to repartition the mtd to get full use, as the Android partitioning scheme uses two partitions.

Pro tip: to see the insides of a scriptcmd file run ‘tail -c +73 scriptcmd’

Disk access when running from the SD card is sloooow (at least for slow SD cards like mine.) Don’t know if running from internal flash is any better.

I’m guessing that the framebuffer works normally in the Debian install because it isn’t using double-buffering, which is necessary for Android to work. I don’t know if ‘abrasive’ had to do anything special to get the ‘fbcon’ console module to work, I’m going to try and find out though!

EDIT: Jacob Stoner has come up with a small program to init the touchscreen, and a more recent version of evtouch that works for input. info here, init program & recent evtouch. He says he’s going to come out with an installable package (no serial/keyboard required) shortly.

I had a quick try at copying across the wm9715-api.ko & wm9715-ts_800_480.ko touchscreen modules from the Eken firmware, and using them with the package xserver-xorg-input-evtouch to provide a touchscreen mouse. No luck, though. The ‘evtest’ utility shows screen presses coming in, but no X/Y coordinates. A better approach might be to compile the the Wolfson OSS drivers against the 2.6.29 kernel headers.

Finally,

Want a quick laugh?


~# modinfo wm9715-api.ko
filename: wm9715-api.ko
author: VIA ShenZhen MCE SW Team
license: GPL
description: WM9715 api for the driver of touchscreen and battery

GPL, huh? This is kind of “GPL” where noone releases any source code. Ho ho ho! Thanks VIA, Wondermedia & Eken.