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. EDIT June 2012: Tony points out in the comments that there’s a thin film covering the piano finish, and he’s absolutely right. Here’s a quick photo, the top-left corner is a reflection.

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?

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 USBSerial cable that I got for $2 at an op shop1.

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.

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.

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

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.

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.

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.

Eric – I hope to post a Debian build and a video in a week or so. Just trying to get the wifi+bluetooth chip to play nice, then I think everything will be supported except 3d acceleration hardware and the remote control. So usable as a “normal” desktop computer, but no good for XBMC without hardware 3d.

For your little OMAP board, it shouldn’t be too hard (famous last words.) There is already support for some OMAP3430 boards under arch/arm/mach-omap2 (ie board-3430sdp.c). Look at the kernel config that came with your board, and see what board is selected there – you may need to port the “board file” from your 2.6 tree to the 3.2 tree, and then clean up anything else so it builds & runs… Can be pretty fiddly but it shouldn’t be too hard given you already have working source.

This is pretty awesome. I bought one of these myself months back with the same intentions but gave up on it, but your project has me excited again. I downloaded the kernel and tried to build with “make ARCH=arm CC=arm-none-linux-gnueabi-
” like I use for other ARM systems but no luck. What compiler are you using? This is my first 3.x build, my other embedded work is locked into 2.6.30.

You looking for any help on the wifi driver? I looks for info on the chip mentioned and TI had some info. They seem to have two different drivers for it that work on the OMAP. I think one is an SDIO driver and one is MMC.

Thanks for getting in touch! You should be fine with any toolchain that works on 2.6.30, FWIW I’m using emdebian. I do “make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-” but I’m guessing that might be just a typo.

I’ve uploaded the Debian config I’m currently using to http://projectgus.com/files/fv1/config-flexiview-nfs if that’s of any use. It’s configured for NFS rootfs, so you’ll need to edit the default kernel command line if you want to boot from MMC or USB. And also probably remove the DHCP client option from the kernel.

Hopefully I’ll get proper Debian images and a howto up soon, have been consistently stuck on the wireless option for weeks now – going around in circles. Using the wl27xx driver in the kernel tree, I get random fatal sdio errors at random times – even with the mmc host rate turned all the way down. I don’t know if it’s the wl27xx driver, or something in Samsung’s mainline mmc host drivers.

I’m going to try the alternative wl27xx driver, the “TIWLAN” one provided by TI. That’s what the stock Android firmware is using. I haven’t gotten it to build yet, though. Will keep you posted.

Ok, that built successfully. Yeah I just remembered the compile string wrong. I thought I would try to build those wl1271 drivers into the kernel rather than modules and the compile failed, I might just need a make clean…
“Inconsistent kallsyms data
This is a bug – please report about it
Try make KALLSYMS_EXTRA_PASS=1 as a workaround”
in case thats helpful to you, I’ve never had one build as a modules but not into the kernel, maybe its important?

I tried to get the emdebian package and it switched it to ‘multistrap’ automatically, how helpful. The help page I found implied thats the ‘new way’ but reading through the howtos it seems like they are different. So you are building with emdebian? I think I’ll just manually install the package if so because this multistrap seems like a step down for cross compiling.

Good to hear you’re making progress! For the KALLSYMS_EXTRA_PASS thing, have you tried ‘make clean’? That’ll often solve it, either that or it’s some bug with the dependencies for the wl12xx modules I think.

I’m a bit confused about your second post. ‘multistrap’ is a tool for building root filesystem images, you shouldn’t need it for a kernel… I’ve had mixed luck with ‘multistrap’ rootfses, this time I ended up switching back to ‘debootstrap –foreign’ for the wheezy rootfs I’m using with the FV-1. However, I’ve used multistrap successfully to make a build environment for scratchbox2 (see a previous blog post.)

The extra pass thing fixed the build, I’m not sure if built in vs modules will make any difference but I figure once its working that would be the ideal built since the hardware doesn’t change.

Yeah, I wasn’t sure how to get a good rootfs. I looked at the debian arm stuff but it all seemed focused on a USB drive install. I thought that was what you meant you were using emdebian for, to build a rootfs but I checked out debootstrap and I get it now. I went and built a buildroot rootfs for Cortex A8 since I know how to do that, but I’ll try debootstrap as I’d much rather have debian then get stuck with uclibc.