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” [↩]

“Derek” posted up a comment yesterday:

I have a EKEN M001, which will not unlock the screen by pressing MENU.

I have tried reseting the EKEN M001 by pressing the Reset button on the back ofthe MID, but te screen stays unlocked.

The top of the screen says: “Demo Version” when the GUI appears, does this need a Operating System update. If so, hpw can this be done.

Short Answer

I think your tablet has failed its internal licensing check. Try to return it to the retailer that you bought it from. If you now connect it to the internet, it will “phone home” to a company in Shenzhen, China.

EDIT: Before you give up try connecting to the internet for a while and leave it connected. It seems like sometimes “phoning home” will verify that it’s a legit install and then the message will go away.

Long Answer

This is a coincidence, because just yesterday I was looking at the decompiled Eken libraries posted to slatedroid by ‘bushing’. Hidden in there is licensing code that verifies the Eken is running on genuine hardware. I think it works like this:

• The Eken has a serial number loaded into its CPU (a WMT system parameter in the SoC.)
• The serial number maps to the hardware (MAC) address of the onboard wireless adapter.
• At startup, the Eken loads the serial number and compares it with the serial number it calculates from the wireless adapter.
• If they do not match, it locks and throws up “Demo Purpose Only” (possibly “Demo version has expired” on the latest firmware.) It will also continually try to “phone home” with some details about the device (see below.)

I think all of this is to prevent someone putting their firmware into another device, unlicensed. The code is obfuscated (intentionally hidden in the source) in the hope that a casual shanzhai observer will miss it.

From looking around the internet, it looks like quite a few devices are turning up brand new with “Demo Purpose Only”. The only easy thing to do is to return it to the retailer that you bought it from.

It is possible some retailers are selling fake or refurbished units (maybe they swapped the WiFi unit or the CPU daughterboard out.) In other cases like this, it looks like units may be shipping from Eken with invalid serial numbers (poor quality control?) Finally, in cases like this it seems that temporary problems with the WiFi may trigger this behaviour for a while, then it fixes itself.

Eken Phone Home

I found it quite surprising that the unit tries to phone home if it thinks its license is invalid. It phones home with 3 details:

• A username & password which is decoded from the file /data/wmtpref/custkey (in the firmware itself.)
• The MAC address of the wireless adapter

… the very odd thing is that the unit does not phone home to Eken. It phones home to a company called Aiteer, who are also based in Shenzhen but do not seem to have any published relationship with Eken. Aiteer’s web site doesn’t say anything about software development, but I can only guess that they did the firmware development for Eken and possibly related MID/tablet devices using the WM8505 chipset.

Other Thoughts

It’s odd that the firmware locks the user out and tries to phone home, because if the user is locked out then it’s unlikely that they’re going to be able to connect to the internet. Maybe I missed a detail in my reverse-engineering, and the lockout only kicks in every few minutes or something.

Although “phoning home” is pretty common, software phoning home without the knowledge or consent of the user is less common and is often regarded as unethical. I’m glad that in this case no personal information is being sent back, but clearly we’re at the mercy of the manufacturers in this regard. Unlike mainstream manufacturers, companies like Eken have no corporate presence outside of their factory in China – in other countries, the laws that protect consumers are effectively powerless. If you hypothetically did find out that an unscrupulous shanzhai was stealing your personal details, there is no real recourse you could take.

The license check code was obfuscated in the library (libui.so in this case) so that a casual observer would not see it. For example, nothing unusual showed up when I ran ‘strings’ the other day. However, a tiny bit more reverse-engineering shows up a helper method calling base64_decode to decode each of the string constants related to the license check.

The code used to decode the username & password from the customer key, as well as the code used to calculate the serial number, are both trivially simple and anyone with some C programming knowledge can decipher them from the decompiled dump in an hour or two. For this reason, I think that the manufacturers only put in this protection to avoid casual copying of their firmware into another product – anyone serious about ripping them off could spend a couple of hours and generate their own serial numbers, and disable the “phone home” feature, without needing to modify the binary code at all.

Because the serial number is tied to the MAC, I don’t think anyone will be able to replace the WiFi module at all – even though you own the product.

It bothers me a lot that Eken are going to lengths to protect the tiny amount of proprietary code in their product, while not doing anything to fulfill either the legal obligations or the spirit of the substantial open source parts of the product. It bothers me doubly so now that they’ve locked out the root serial console in the latest (1.7.4) firmware release. How do they think that this helps their product?