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
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
Up to 1920x1080 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 (1280x720), but you can edit that file to get 1080p (1920x1080) or 480p (720x480.)
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.
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.)
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.
The system won't reboot, you have to shutdown and then cycle the power by plugging/unplugging the cord!
I hope this is of some use. Patches are very welcome if anyone works any of the issues out. :)